Async Business Rules let you run heavyweight operations without forcing users to wait for their save to complete. You'll have a rule that fires in the background after the transaction commits.
Why synchronous rules cause user pain
Regular Business Rules run inside the user's save transaction, which means every API call, complex calculation, or database operation adds seconds to their form save. Users see spinning wheels while your rule calls external systems or processes hundreds of related records. Platform admins get complaints about slow performance, and developers get pressure to optimize rules that were never designed to be fast. The users doing actual work — creating incidents, updating changes, processing requests — suffer the most because their simple actions trigger complex backend processes.
How async rules work differently
Async Business Rules run after the database transaction completes, in a separate background thread. ServiceNow takes snapshots of current and previous at transaction time and passes those frozen objects to your rule later. This means you can't access live session data like gs.getUser() or rely on current reflecting changes made after the save. The trade-off is speed: users get immediate saves while your heavy lifting happens behind the scenes. Start with basic async processing, then add proper error handling and sequencing as you build more complex workflows.
Building production-quality async rules
Once basic async processing works, focus on execution order using the Order field, especially when multiple async rules need to process the same records in sequence. Add logging so you can track what happened when things run in the background. Consider what happens when your rule fails — async failures don't block the user's save, but they can leave data in inconsistent states. The best async rules are idempotent and include fallback mechanisms for when background processing breaks.
Before you start
- •admin role or business_rule_admin role
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Business Rules
Go to System Definition > Business Rules. Click New to create a new Business Rule record. You'll configure when and how this rule executes.
Set table and timing
Set Name to something descriptive like 'Process incident attachments async'. Choose your Table from the dropdown. Set When to 'async' — this is what makes the rule run in the background after the transaction commits. Leave Active checked.
Configure the execution order
Set Order to a number like 100. Async rules with lower order values run before higher ones when multiple async rules fire from the same record change. Start with 100 so you can insert other rules at 50, 150, etc. later without renumbering everything.
If this rule depends on data created by other async rules, set a higher order value.
Add filter conditions
Set Filter Conditions to define when this rule should fire. Be specific — async rules that fire too often create unnecessary background load. Use Advanced view if you need complex conditions involving multiple fields or OR logic.
Write the async script
In the Script field, write your JavaScript. Remember that current and previous are frozen snapshots from when the transaction committed, not live objects. Don't use gs.getUser(), gs.getUserID(), or other session variables — they're unreliable in async context. Use current.sys_created_by or similar record fields instead.
Test with background processing
Click Submit to save the rule. Test by triggering the conditions on your target table. The rule won't run immediately — check System Logs > System Log > All for any errors, and verify your expected changes happened in the background. Use gs.info() statements in your script to confirm execution.
Best practices
Never rely on gs.getUser() or session variables in async rules — use record fields like current.sys_created_by instead since async rules run outside the original user session.
Add generous logging with gs.info() statements because async failures happen silently in the background and are harder to debug than synchronous rule failures.
Keep async rule conditions tight — rules that fire on every record update create unnecessary background processing load even when they have nothing useful to do.
Use the Order field intentionally when you have multiple async rules on the same table, especially if later rules depend on changes made by earlier ones.
Remember that current and previous are frozen snapshots from transaction time — any changes made to the record after the save won't be visible to your async rule.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue