The Now platform consists of a range of business rules, Script Includes, and internal codes. 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.

(function executeRule(current, previous /*null when async*/) {
// Add your code here
gs.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:

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%20Debug
  
• Also 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.