Business rule timing
Pick the right timing so logic runs once, in the right place, without slowing the save.
Pick the right timing so logic runs once, in the right place, without slowing the save.
- 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.