Business Rules that fire on every record update create unnecessary database load and slow down forms. This guide shows you how to trigger rules only when specific fields change, using ServiceNow's built-in change detection methods.
Why most Business Rules fire too often
Most Business Rules use basic conditions like checking field values, which means they execute on every update even when irrelevant fields change. A rule that sends notifications when priority changes will fire when someone updates the description, assignment group, or any other field — wasting cycles and potentially sending duplicate notifications. Platform admins see this pattern everywhere: rules written quickly that work functionally but create performance problems at scale.
How ServiceNow tracks field changes
ServiceNow maintains change tracking for every field on every record during the update transaction. You access this through three methods: changes() returns true if a field changed at all, changesFrom() checks if it changed from a specific value, and changesTo() checks if it changed to a specific value. The key insight is using these in your condition logic rather than just checking current field values. You can put simple change checks directly in the Condition field, or use Script Condition for complex logic combining multiple change checks.
Building robust change detection
Start with single field change detection using changes(), then layer in value-specific logic with changesFrom() and changesTo() when you need it. Advanced implementations combine multiple field changes with AND/OR logic, check for specific state transitions, and use Script Includes to centralize complex change detection logic. The performance difference becomes dramatic on high-volume tables — a rule that fires 100 times per day instead of 1000 times makes your instance noticeably faster.
Before you start
- •admin role or business_rule write access
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
Open your Business Rule record
Navigate to System Definition > Business Rules and open the rule you want to modify, or create a new one. Set the Table to your target table and When to 'before' or 'after' depending on your logic. The timing matters for change detection — 'before' rules see the changes before database commit, 'after' rules see them after.
Choose condition approach
Decide between using the Condition field or Script Condition. For single field changes, use the Condition field — it's more performant. For complex logic combining multiple field changes or value-specific checks, use Script Condition and check the Advanced checkbox.
Set simple field change condition
If using the Condition field, enter: current.field_name.changes(). Replace 'field_name' with your actual field name like 'state' or 'priority'. This creates a condition that only evaluates true when that specific field changes during the update.
Add value-specific change logic
For Script Condition, use current.field_name.changesFrom('old_value') to trigger when changing from a specific value, or current.field_name.changesTo('new_value') for changes to a specific value. Combine multiple conditions with && (AND) or || (OR). Example: current.state.changesFrom('2') && current.priority.changes() triggers when state changes from In Progress and priority also changes.
Use the actual stored values, not display values — '2' instead of 'In Progress' for choice fields.
Handle reference field changes
Reference fields store sys_ids, so use current.assignment_group.changesFrom('sys_id_value') or just current.assignment_group.changes() for any assignment change. Don't try to use display names in change detection — ServiceNow compares the underlying sys_id values.
Test the change detection
Save the Business Rule and test by updating records. Change the field you're monitoring — the rule should fire. Then update other fields — the rule should not fire. Check the System Log for any errors and verify the rule only appears in logs when your target field changes.
Add logging for debugging
In your rule script, add gs.info('Rule fired: ' + current.field_name + ' changed from ' + current.field_name.getDisplayValue() + ' to ' + current.field_name.changesTo()) for debugging. This logs exactly what triggered the rule and helps troubleshoot complex change conditions.
Remove debug logging before going to production — excessive logging hurts performance.
Best practices
Use the Condition field instead of Script Condition for single field changes — the database can optimize these conditions better.
Never check changes() inside a loop over related records — it evaluates the same result every iteration and wastes cycles.
Combine field change detection with null checks when dealing with fields that might be empty: current.assignment_group.changes() && !gs.nil(current.assignment_group).
Test change detection with both manual form updates and scripted updates — some automated processes behave differently than user interactions.
Don't use changes() in display Business Rules — they run on form load when no changes have occurred, so the condition will always be false.
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