In my past experience, I have been through the analysis of the results of a ServiceNow ACE audit. I would like 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:
Now, let’s change the incident priority to 1 – Critical and see the result:
So 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:
You want to check the behaviour of this BR so you add “toto” in the short description, save the record and see what happens:
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.
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:
When we remove “toto” from the short description, change priority to 1-Critical, the problem is created as expected:
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
