Understanding Async Business Rules
All ServiceNow Admins need to understand when to use an async business rule, and when not to.
An async business rule is similar to an after business rule, in that it runs after a database operation occurs on the server. But ServiceNow creates a scheduled job on the ‘sys_trigger’ table for the operation to run, which allows the client session to not hang and gives the user control immediately – all while the scheduled job is running in the background.
The downside of running an async business rule is that it is not executed immediately.
If you can allow between 3-10 seconds for the operation to be completed and you do not need to return a message to the user, then you should consider using an async business rule. These are best used for concepts like performance analytics, updating SLA’s or generating events, like gs.eventQueue().
While the scheduled job is immediately created, you need to allow one of the workers to “pick up” the job and complete it before the desired action is completed.
It is strongly suggested that you do not use ‘current’ in an async business rule. There is also no concept of ‘previous’ in an async business rule.
Further, you should really only be using ‘current’, when updating a record in a ‘before’ business rule. Reference Knowledge Base Article KB06878340 for more information.
Creating an async business rule allows the user session to not be temporarily halted by the running of the script – which is a better user experience. But the operation still needs to be processed in the scheduled job that is created – so this is the hand off. You’re giving the user a better experience at the risk of putting more stress on the database and server.
Always make sure that you run and sufficiently test your async business rules in a sub production instance before moving to production. An incorrectly scripting async business rule can cause havoc in a production system and can have massive performance degredation on your instance if not written properly.
Your application nodes on your instance may need to be restarted if the async business rule causes your workers to be stuck and run continuously.
If you know that it is acceptable to allow a small amount of time for the operation to complete and they won’t be run frequently by many users – then consider using an async business rule. This will give the user session a better experience as the operation is being completed in the background.
How To Create An Async Business Rule
To learn when and how to use an async business rule, it’s sometimes best to see what is out of box in ServiceNow.
To create an async business rule, simply go to your business rule and then make sure that the “When” dropdown has the value “async” selected.
Here is an out of box async business rule:
Title: Delete Live Profile
Script:
(function executeRule(current, previous /*null when async*/) {
new LiveFeedUtil().deleteProfileUserID(new GlideappLiveProfile().getID(current.getUniqueValue()));
})(current, previous);
The script above essentially runs whenever a user record [sys_user] is deleted.
Since the operation doesn’t need to be run immediately, and there is no need to return any message to the end user that is running the session – then this is a completely fine scenario.
Let’s test the business rule above and see what happens when the async business rule is triggered. To do so, we will need to delete a random user record, and then watch for the client session to not hang and have the platform create the sys_trigger record in the background.
To get to the sys_trigger table, type the following into the application navigator and hit enter:
sys_trigger.list
Once you’re on the Schedule table, you’ll be able to see all jobs that have been created via async business rules, as well as many other “Run Scripts” that are auto generated by the system that most ServiceNow Admin’s don’t even realize are occurring.
When you want to find the scheduled jobs that are being created via your async business rules, just find the Schedule records that have the name field start with “ASYNC: {Name Of Business Rule}.
In the Job Context field, you’ll see the name of the business rule and it’s sys_id being referenced to be called when the job is picked up.
As soon as the job is picked up, the operation is completed and your async business rule is officially done.
Check the system logs if your async business rule isn’t running properly, or if you’re not seeing it in the sys_trigger table.
At this point, we think we’ve covered async business rules enough for you to get started with them.
They can be tricky to use, but they are very under utilized in ServiceNow and should be used more frequently. Most ServiceNow Admin’s skip over them and are much more comfortable with before/after business rules.
What are some scenarios where your company uses async business rules vs. after business rules?
Let us know below.
