Debugging business rules
Summarize
Summary of Debugging Business Rules
This guide outlines effective methods and tools within ServiceNow to debug business rules. It helps ServiceNow customers identify issues with business rule logic, verify data queries, and understand table relationships to ensure their automation behaves as expected.
Show less
Debugging Tools
- System Dictionary: Access via System Definition > Dictionary to view all tables in your instance, aiding in locating relevant data.
- System Log: Use System Logs > System Log to add alert statements in business rules that write diagnostic info to logs.
- Debug Business Rule (Details): Available under System Diagnostics > Session Debug, this tool shows business rule execution results, condition checks, and variable values.
- Alert Messages: Utilize scripting functions to output messages on pages, fields, or logs for real-time feedback.
- Business Rule Examples: Reference existing scripts for common error messages or query patterns, including OR queries.
- GlideRecord Information: Use GlideRecord syntax to query and aggregate data from tables, crucial for debugging data retrieval.
Verifying Variables and Queries
To understand business rule behavior, verify that your GlideRecord queries return expected records. Use gs.addInfoMessage to display query results on the UI, confirming whether records are found. For example, check the boolean result of rec.next() to know if your query is successful.
If queries fail to return results, break down your script into smaller parts to isolate issues, test each independently, and then integrate them step by step.
Understanding Table Relationships
Since ServiceNow tables can extend other tables, debugging may require querying both extended and parent tables. For instance, the sctask table extends task. To retrieve fields like worknotes, first query the extended table for relevant records, then query the parent table using the matching sysid.
This approach ensures you access the correct records and fields across related tables, which is essential when business rules interact with extended tables.
Debugging business rules can be achieved with resources available in the ServiceNow product.
1. Tools
The first step in the process is to identify tools which will help you figure out what's wrong.
| Debugging tool | Description |
|---|---|
| System Dictionary | Navigate to . The dictionary provides a list of all tables within your instance and can be invaluable when trying to locate information. |
| System Log | Navigate to . You can place alert statements in your business rule which can write information to the log. |
| Debug Business Rule (Details) | Navigate to . This debugging module displays the results business rules. Use this module to see if conditions are being met and values are being set as expected. |
| Alert Messages | There are several system functions that allow you to print messages to the page, the field or the log file. See Scripting alert, info, and error messages. |
| Business Rule Examples | Sometimes you can find what you're looking for in scripts others have written, including business rule error messages, or by building an OR query. |
| GlideRecord Information | This is the basic syntax used to query the database for information. See Querying tables in script. GlideRecord also includes aggregation support. |
2. Variables
The next step is to gain some insight into the behavior of your business rule. For every action except an insert, you will more than likely use a query to get your record(s).
var rec = new GlideRecord('incident');
rec.addQuery('active',true);
rec.query();
while (rec.next()) {
gs.print(rec.number + ' exists');
}
To verify whether your query is actually returning records you can use gs.addInfoMessage to display information at the top of the screen.
var rec = new GlideRecord('incident');
rec.addQuery('active',true);
rec.query();
gs.addInfoMessage("This is rec.next: " + rec.next());
while (rec.next()) {
gs.print(rec.number + ' exists');
}
If your query returns no records you see the following:
This is rec.next: false
Use this technique to verify every variable within your business rule contains expected values.
3. Locating information
The last step is to make sure you know where to find the information your rule is looking for.
In the ServiceNow application, one table can extend another table. This means when searching for information, you might need to query the parent table for the extended table's sys_id to find what you seek.
A good example is the sc_task table, which extends the task table. The script below queries the extended table (sc_task) for the current sys_id and then query the parent table (task) for records with the matching sys_id, and then prints out the work notes field.
var kids = new GlideRecord('sc_task');
kids.query();
gs.addInfoMessage("This is requested item number: " + current.number);
gs.print("This is the requested item number: " + current.number);
while (kids.next()) {
var parents = new GlideRecord('task');
parents.addQuery('sys_id', '=', kids.sys_id);
parents.query();
while(parents.next()) {
gs.addInfoMessage("This is task number: " + parents.number);
gs.print("This is task number: " + parents.number);
gs.addInfoMessage("These are the work notes: " + parents.work_notes);
gs.print("These are the work notes: " + parents.work_notes);
}
}