Skip to page contentSkip to chat
ServiceNow support
    • Community
      Ask questions, give advice, and connect with fellow ServiceNow professionals.
      Developer
      Build, test, and deploy applications
      Documentation
      Find detailed information about ServiceNow products, apps, features, and releases.
      Impact
      Accelerate ROI and amplify your expertise.
      Learning
      Build skills with instructor-led and online training.
      Partner
      Grow your business with promotions, news, and marketing tools
      ServiceNow
      Learn about ServiceNow products & solutions.
      Store
      Download certified apps and integrations that complement ServiceNow.
      Support
      Manage your instances, access self-help, and get technical support.
Troubleshooting tip - Debug business rule to print StackTrace - Support and Troubleshooting
  • >
  • Knowledge Base
  • >
  • Support and Troubleshooting (Knowledge Base)
  • >
  • Troubleshooting tip - Debug business rule to print StackTrace
KB0683765

Troubleshooting tip - Debug business rule to print StackTrace


41889 Views Last updated : May 21, 2025 public Copy Permalink English (Original)
  • English (Original)
  • Japanese
KB Summary by Now Assist

Issue

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 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:

operationinsert, update, delete
sessionIDuseful when searching transaction log, node log
timetime of when the BR was invoked
sys_iduseful when searching the BR output in the system log
stack 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%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.

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 here
gs.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);

 

 

 

Release

Not specific to a release


The world works with ServiceNow.

Sign in for more! There's more content available only to authenticated users Sign in for more!
Did this KB article help you?
Did this KB article help you?

How would you rate your Now Support digital experience?

*

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

Very unsatisfied

Unsatisfied

Neutral

Satisfied

Very satisfied

What can we improve? Please select all that apply.

What are we doing well? Please select all that apply.

Tell us more

*

Do you expect a response from this feedback?

  • Terms and conditions
  • Privacy statement
  • GDPR
  • Cookie policy
  • © 2025 ServiceNow. All rights reserved.