Troubleshooting tip - Debug business rule to print StackTraceIssue The ServiceNow platform consists of a range of Business Rules, Script Includes, and internal code. Occasionally, you need to know how certain values are being inserted, updated, or deleted to be able to understand how these happen and to narrow down the troubleshooting. This article describes a debugging business rule that will print out the StackTrace when the condition is met. Prerequisite and Assumptions In order for the troubleshooting business rule to be effective, you need to have a hypothesis of what you want to capture. Printing out everything slows things down and produces too many useless logs. A good debug business rule therefore depends on a good restrictive set of conditions. Examples: If you have a lot of new records on the u_test table by user Abel Tuter, you might want to create a debug business rule for "insert" on table u_test and "created by" as Abel Tuter and nothing else. If you have a lot of updates on the u_test table by David Loo, you might want to create a debug business rule for "update" on table u_test and "updated by" as David Loo and nothing else. If you have a lot of records being created for the table u_test with the name ABCDE, you might want to have a debug business rule on "insert" on table u_test and "name" as ABCDE and nothing else. Script of the Debug Business Rule The following example shows a sample script for the debug business rule. You can customize the details according to your own situation but note this will only work in the Global scope as it stands: (function executeRule(current, previous /*null when async*/) {// Add your code heregs.log('***** DEBUG - op:'+ current.operation() + ", sess:" + gs.getSessionID() + ", time:" + new Date().getTime() + ', sys_id:' + current.sys_id + ' - \n' + GlideLog.getStackTrace(new Packages.java.lang.Throwable()), 'Stacktrace Debug');})(current, previous); Info being logged: operationinsert, update, deletesessionIDuseful when searching transaction log, node logtimetime of when the BR was invokedsys_iduseful when searching the BR output in the system logstack trace logThe stack trace of when the BR was invoked Logs You can check the logs for the debug business rule on the syslog table where "source" is "Stacktrace Debug" (the second parameter of the gs.log).For example: https://<instance-name>.service-now.com/syslog_list.do?sysparm_query=source%3DStacktrace%20DebugAlso since the stack trace ran against a record, you can also search the logs where message contains the sys_id of the record. However, if you're trying to find the stack trace for records that were deleted you will need to save the sys id before the removal of the record.Searching by sys id in the system logs is also helpful when multiple stack traces are logged and you're trying to find a specific one. Outputting a Stack Trace In a Scoped Application The above business rule will not work in a scoped application as Packages calls, which should really be avoided if possible, can not be used within a scoped application. To work around this a global script include is needed to get the stack trace, and this is called from the scoped business rule. The script include "StackTrace" must have the "Accessible From" option set to "From all scopes": var StackTrace = Class.create();StackTrace.get = function() { return GlideLog.getStackTrace(new Packages.java.lang.Throwable());}; The business rule is then modified as follows, note the change to use gs.info, which can be used from all scopes, from gs.log which is also global only: (function executeRule(current, previous /*null when async*/) {// Add your code heregs.info('***** DEBUG - op:'+ current.operation() + ", sess:" + gs.getSessionID() + ", time:" + new Date().getTime() + ', sys_id:' + current.sys_id + ' - \n' + global.StackTrace.get(), 'Stacktrace Debug');})(current, previous);