Business Rules let you run server-side JavaScript automatically when records change. This guide walks you through creating one that fires at the right time and does what you need without slowing down your instance.
Why Business Rules exist
Most Business Rules get created reactively — something needs to happen when a record updates, someone writes a quick script, and it works. The problem is that approach accumulates technical debt fast. Business Rules that fire on every update, query the database inside loops, or trigger cascading rules are one of the top causes of slow ServiceNow instances. The people who maintain these systems — platform admins and developers — inherit whatever was written, and poorly designed rules are notoriously hard to debug months later.
How Business Rules execute
A Business Rule is server-side JavaScript that ServiceNow runs automatically when a record is inserted, updated, deleted, or queried. The 'when' matters: before rules run before the record hits the database (use these for validation and setting values), after rules run once it's committed (use these for related record updates), async rules run in the background (use these for anything that doesn't need to block the user), and display rules run when the form loads (rarely used). Most developers reach for 'after' by default — that's usually wrong. If you're setting a value on the record being saved, use 'before'.
Building production-quality rules
Once you have a working rule, the improvements worth making are: narrowing the condition so it fires less often, adding field-level change detection instead of running on every update, and extracting reusable logic into Script Includes so other rules can share it. A well-built Business Rule has a tight condition, does one thing, and doesn't query the database more than once.
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 rule. The form that opens controls when your rule runs and what it does — get the timing wrong here and you'll either miss the data you need or create performance problems.
Use the filter navigator and type 'business rules' — it's faster than drilling through the menus.
Name and target the rule
Fill in the Name field with something descriptive that includes the action and table — like 'Set priority on incident creation'. Set Table to the table this rule should monitor. Leave Active checked unless you're building something you'll enable later.
The name shows up in logs and error messages, so make it specific enough to identify the rule's purpose.
Configure when the rule fires
Check the appropriate boxes under When: Before for validation or setting values on the current record, After for updates to other records, Async for background processing that doesn't block users. Then check Insert, Update, Delete, or Query based on what database operations should trigger the rule. Most rules use Before + Insert/Update or After + Insert/Update.
Don't check Update unless you actually need the rule to run on every field change — use conditions to be more selective.
Set the condition
In the Condition field, build a filter that limits when the rule runs. Click the condition builder icon and create conditions like 'State is New' or 'Priority changes'. If you leave this blank, the rule fires for every operation you checked in step 3. Set Order to 100 unless you need this rule to run before or after other rules on the same table.
Use 'changes' conditions instead of firing on every update — 'priority.changes()' is much more efficient than checking priority values in your script.
Choose your implementation approach
You'll see two tabs: Advanced and Simple Actions. Use Simple Actions for basic field updates — it generates optimized code and doesn't require JavaScript knowledge. Use Advanced for custom logic that needs scripting. Most rules that do anything interesting need the Advanced tab.
Simple Actions are genuinely faster and less error-prone for straightforward field updates — don't write JavaScript just because you can.
Write the rule logic
If using Advanced, click that tab and write your JavaScript in the Script field. The current record is available as 'current', and you can access fields like current.priority or current.state. For Before rules, changes to current get saved automatically. For After rules, you need to call current.update() if you modify the triggering record. Click Submit to save and activate the rule.
Use gs.log() to write debug output while testing — your messages appear in System Logs > System Log > All.
Best practices
Always use specific conditions instead of firing on every insert or update — unconditioned Business Rules are performance killers.
Set values on the current record in Before rules, not After rules — Before rules don't require an additional database update.
Never query the same table your Business Rule is running on from within the rule — it can trigger infinite loops.
Use current.changes() or current.fieldname.changes() to detect if specific fields changed rather than running logic on every update.
Keep async Business Rules truly asynchronous — don't use gs.sleep() or wait for external systems that might be slow.
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