Troubleshooting Conflicting Business Rules for ServiceNow Integration

Business Rules are server-side scripts that execute during record display, insertion, deletion, or table queries. They are typically used to automate field updates based on specific conditions.

When integrating ServiceNow via Getint, Business Rules can occasionally revert or block changes before they reach the integration point. This guide provides troubleshooting methods to identify triggered Business Rules and implement effective workarounds.

Assessing Getint logs for Sync Failure

• If the Business Rule completely blocks activity from inbound API requests, our logs will display it right away with an error message that also points out which specific Business Rule is conflicting with the integration.

We can see that there is a Business Rule in place, called Testing business rule that is blocking the creation of incidents via Getint.

• As the Sync Details screen explicitly displays which Business Rule is blocking the creation of Incidents, you can pretty much review how this Business Rule is operating on your ServiceNow instance, and work on it so it doesn’t disrupt your integration.

Filtering the Business Rules by the affected table (Incidents) and by the name gathered from the Getint logs, we found the business rule affecting the integration and can now work on it.

Investigating Triggered Business Rules

When Getint updates ServiceNow via REST, the transaction is non-interactive, meaning that the changes applied to your work items/tables won’t display entries in the Script Tracer or the Debug Business Rules (Details). This is because those ServiceNow tools only register web browser transactions, so the UI debugging tools don’t capture anything.

With the above in mind, there are a few steps that you can perform to investigate which Business Rule was triggered, so you can identify it and act accordingly (update the business rule, disable it, delete it, etc).

1. Verify the Active Business Rules for that Table

• In your application navigator, paste sys_script.list and hit enter.

• A list of all business rules of your workspace will be displayed.

• Filter them by table name, so you can see all business rules that may have conflicted with the work item type/table in question.

• You can also configure the list layout by adding more columns to help you narrow the investigation down quicker. Adding the Script column, for example, will display the specific script running on that Business Rule, which may come in handy.

2. Identify Suspicious Rules

• Look specifically for rules that touch assignment fields, such as assigned to, assignment group, caller, etc.

• Verify the timing (WHEN) of any suspicious business rules (If your integration sends: u_assigned_to = User A, a "Before Update” rule can silently change it to: User B).

3. Confirming the Conflicting Business Rule

• Adding the Set field value column might also help you narrow down the search. It will display the field update logic, so if a Business Rule is updating a field to a specific value, you will be able to see it.

• We can then see if the listed Business Rule updates any field values of the records from that table, and if they do, what the value would be.

• Upon verifying that the Business Rule in specific, we could see that it should trigger Before an Incident is updated (based on a request to update the record). The criteria for the Business Rule to trigger is: If State is In Progress, then the Short Description field should be updated to a specific String text.

• Additionally, check for the Advanced tab (in case it's enabled) to ensure no other scripts are running along with this Business Rule.

• You can then patch your Business Rule, so it stops conflicting with REST API updates coming from Getint.

If you need any further help or if you are experiencing issues with your installation, feel free to open a support ticket at our Support Portal.

Start your integration journey. Schedule a free consultation with our Getint Integration Expert today!