Email notifications need conditions — otherwise they fire on every update, flooding inboxes and hurting performance. This guide shows you how to add precise conditions so notifications only send when they should.
Why notifications need conditions
Out-of-the-box notifications fire on every insert or update to a table, which creates noise fast. Users get emails for trivial changes like comments or assignments they don't care about. Operations teams get alert fatigue when every field change triggers a message. Platform admins inherit notification records that generate hundreds of emails daily because no one added conditions when the business rules were simple. The people maintaining these systems — you — have to debug why notifications aren't firing when they should or why they're firing when they shouldn't.
How notification conditions work
ServiceNow evaluates conditions in two places: the 'Send when' field controls insert/update timing, and the 'Condition' field controls whether the notification actually fires. Start with 'Send when' set to specific field changes rather than 'Record updated' — this prevents the notification from running when irrelevant fields change. The Condition field offers a visual builder for simple logic or advanced scripting for complex scenarios. Advanced scripts get access to 'current' (the record after changes) and 'previous' (before changes), which lets you build conditions like 'priority changed from 4 to 1' that the visual builder can't handle.
Building production-quality conditions
Once basic conditions work, the improvements that matter are: adding multiple field-change triggers instead of broad 'updated' triggers, using advanced scripts to compare previous and current values for complex business logic, and testing conditions thoroughly because notification bugs are hard to catch until users complain. Production-quality notifications combine tight 'Send when' settings with specific 'Condition' logic that accounts for workflow states, user roles, and business rules that might affect the same records.
Before you start
- •admin or notification_admin role
- •existing notification record to modify
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 notification record
Navigate to System Notification > Email > Notifications and open the notification you want to condition. If you're starting from scratch, create the notification first with the target table and basic message content. You'll see the 'Send when' and 'Condition' fields in the When to send tab.
Clone an existing notification rather than building from scratch — it saves time setting up the message content.
Set the Send when trigger
In the 'Send when' field, choose the specific trigger that makes sense for your use case. 'Record inserted' fires once when created. 'Record updated' fires on every field change — avoid this. 'Record inserted or updated' combines both — also avoid unless you specifically need both. Instead, pick individual fields from the dropdown to fire only when those fields change.
Choose your condition approach
Decide between the visual Condition builder and Advanced condition script. Use the visual builder for straightforward field comparisons like 'State is Resolved' or 'Priority is 1 - Critical'. Use advanced scripts when you need to compare previous and current values, check related records, or implement complex business logic that requires multiple conditions.
Build visual conditions
Click the condition builder icon next to the Condition field to open the visual interface. Add conditions by selecting field names, operators, and values. Chain multiple conditions with AND/OR logic. Common patterns: state equals specific values, priority changed to high/critical, assigned to specific groups. The visual builder is limited but covers 80% of use cases.
Test each condition individually before combining them with AND/OR logic.
Write advanced condition scripts
For complex logic, clear the Condition field and check 'Advanced' to enable scripting. Your script must return true or false. Use 'current.field_name' for the record's current state and 'previous.field_name' for the value before changes. Common patterns: current.state != previous.state (state changed), current.priority < previous.priority (priority increased), or gs.hasRole('itil') (user-based conditions).
Test the notification conditions
Save the notification and test by making changes to target records that should and shouldn't trigger emails. Create test records that match your conditions and verify emails send. Then make changes that shouldn't trigger notifications and confirm they don't. Check the Email Logs (System Logs > Email) to see if notifications fired but failed to send.
Monitor and refine conditions
After deployment, monitor the Email Logs for unexpected behavior. Look for notifications firing too often (conditions too broad) or not firing when expected (conditions too restrictive). Users will report both problems, but over-firing is usually caught faster than under-firing.
Best practices
Always set Send when to specific field changes rather than 'Record updated' — broad triggers hurt performance and create noise.
Test both positive and negative cases — verify notifications fire when they should AND don't fire when they shouldn't.
Use advanced scripts when you need to compare previous and current values — the visual builder can't handle 'changed from X to Y' logic.
Combine tight Send when settings with specific Condition logic — both layers working together prevents most notification problems.
Document complex condition scripts with comments — notification debugging six months later is painful without context.
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