Business rule timing
Quick answer
Pick the right timing so logic runs once, in the right place, without slowing the save.
Key takeaways
- Before rules must not call current.update()
- After rules handle related records, async keeps the user out of the wait
- Display rules feed g_scratchpad
- Conditions on the rule are cheaper than an if inside the script
The four timings
Before rules run in the same transaction before the write, so setting current fields needs no update call. After rules run once the record is written and are the place to touch related records. Async rules run in a scheduled job just after the transaction, keeping the user waiting for nothing. Display rules run before the form renders and are the only place to fill g_scratchpad.
Choosing
Ask what the rule changes.
- Changing fields on this record: before
- Creating or updating other records: after, or async when the user does not need the result immediately
- Integrations and notifications to external systems: async
- Data the client script needs: display, passed through g_scratchpad
Keeping them safe
Every rule adds cost to a save. Set a tight condition, avoid current.update() in a before rule because it causes recursion, and use setWorkflow(false) with care when you deliberately need to skip other rules.
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which timing can populate g_scratchpad?
- A. Before
- B. After
- C. Async
- D. Display
Show answer
D. Display
Display rules run before the form is rendered.
Where should an outbound REST call normally go?
- A. Before rule
- B. Async rule
- C. Display rule
- D. Client script
Show answer
B. Async rule
Async keeps the user transaction fast and isolates external latency.