After business rules run once a record is committed to the database, making them perfect for updating related records or triggering external integrations. This guide shows you how to build one properly and avoid the performance traps that catch most developers.
Why after business rules exist
Before after rules, developers had to update related records using before rules or synchronous scripts, which meant the database transaction wasn't complete and referential integrity could break. Platform teams inherited cascading failures when parent records got rolled back but child record updates had already fired. The people maintaining these systems — admins and developers — spent hours debugging phantom records and incomplete transactions that happened because the timing was wrong.
How after business rules work
After business rules fire once the record is safely committed to the database, which means you can't cancel the original save operation anymore. This is the right choice when you need to create or update related records, send notifications, or call external systems. The rule receives the fully committed record with its final sys_id and all field values locked in. Start with a simple field update or record creation, then add condition logic to control when it fires.
Taking after rules to production
Production-quality after rules have tight conditions to avoid unnecessary executions, use GlideRecord.get() instead of queries when updating single records, and batch related record operations instead of processing them one by one. Add proper error handling since you can't roll back the original transaction, and consider using events or async rules for operations that don't need to complete immediately. The difference between a basic rule and a reliable one is usually in the condition specificity and database query efficiency.
Before you start
- •admin role or elevated developer access
- •target table configured and accessible
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. The form opens with basic configuration fields at the top.
Configure basic rule settings
Set the Name to something descriptive like 'Update related tasks when incident resolves'. Choose your target Table from the dropdown. Check the Active checkbox and leave the Application field as Global unless you're working in a scoped app.
Include the trigger condition in the name — it makes debugging much easier six months later.
Set the timing to after
In the When section, check only the 'after' checkbox under When to run. Uncheck any other timing options. Choose your database operation — typically 'insert' for new records, 'update' for changes, or both if the logic applies to either case.
Add condition logic
In the Condition field, write JavaScript that returns true only when your rule should execute. Use current.field_name syntax to check specific field values, like 'current.state == 6 && current.active == false'. Keep this focused — broad conditions kill performance.
Use current.field_name.changes() to detect when specific fields change, not just their current value.
Write the script logic
In the Script field, write your JavaScript using the 'current' object to reference the record that triggered the rule. Create or update related records using GlideRecord. Remember that current is already committed to the database, so you're working with the final values.
Test execution order
Set the Order field to a value like 100 to control when this rule runs relative to other after rules on the same table. Lower numbers run first. Leave room between order values so you can insert rules later without renumbering everything.
Save and validate
Click Submit to save the business rule. Test it by creating or modifying a record that meets your condition. Check the system logs under System Logs > System Log > All if the rule doesn't fire as expected.
Best practices
Never update the current record in an after rule — the database transaction is complete and you'll trigger infinite loops or miss the update entirely.
Use current.field_name.changes() in conditions instead of firing on every update — it reduces unnecessary executions by 80% in most cases.
Avoid GlideRecord queries inside loops when updating multiple related records — build arrays and use batch operations instead.
Include error handling with try/catch blocks since after rules can't roll back the original transaction if something fails.
Log meaningful error messages with gs.error() that include the current record's sys_id — after rule failures are hard to trace otherwise.
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