Why Before Business Rules should not update() or insert() records on other tables

Our team has recently been through the analysis of the results of a ServiceNow ACE audit. We wanted to take this opportunity to share with you one of the findings which may not be obvious for everyone:

“Before Business Rules should not update() or insert() records on other tables”.

So why’s that?
Explanation from the audit:

“If the current transaction were to fail in a later business rule, this business rule has already inserted or updated a record on another table potentially causing a data integrity issue.”

Recommendation

“To ensure data integrity, change this business rule to run “after”.”

Let’s analyze some user requirements to understand what all that means.

User requirement 1
Let’s say you need to implement this: “A problem must be created when the incident priority becomes critical”. In order to do this, you may create a before business rule (BR), order 100, like below:

before_br_create_problem_whenafter_br_create_problem_script

Now, let’s change the incident priority to 1 – Critical and see the result:

incident_form_result_1So far, all went well. The problem has been created as expected.

User requirement 2
Now, your customer informs you that there is already a BR to block the incident’s update when the short description contains “toto”.

After a quick search, you found the BR, which is set up with order 200:

before_br_cancel_transaction_when

before_br_cancel_transaction_actions

You want to check the behaviour of this BR so you add “toto” in the short description, save the record and see what happens:

incident_form_result_2

Since the short description contains “toto”, the incident has not been saved as expected.

BUT… , a orphan problem has been created, due to the business rule of user requirement 1.

Do you see now why “Before Business Rules should not update() or insert() records on other tables”?

Since the incident was not saved, thus does not have priority equals to 1-Critical, the problem should not have been created. This example explains exactly the reason of the ACE finding:

“If the current transaction were to fail in a later business rule, this business rule has already inserted or updated a record on another table potentially causing a data integrity issue.”

How to resolve this?
Let’s follow the recommendation of the ServiceNow team: Change the initial BR to run it after instead of before.

after_br_create_problem_when

after_br_create_problem_script

Now, when we change the priority to 1-Critical and add “toto” to the short description, the incident won’t be saved AND the problem won’t be created:

incident_form_result_3

When we remove “toto” from the short description, change priority to 1-Critical, the problem is created as expected:

incident_form_result_4

This example shows that in order to ensure data integrity, an after BR is the most appropriate solution.

Documentation
Know When to Run Business Rules

 

mm
Ximizu Huynh is a Senior Consultant at Fruition Partners Europe (ex-Aspediens) in Paris. With 12+ experience in IT, he enjoys sharing ServiceNow tips and tricks that make our lives easier.
Recent Posts

Leave a Comment

Start typing and press Enter to search