Notification issues are among the most common support tickets in any ServiceNow instance. Users complain they are getting too many emails, or not getting the ones they need, or getting them at the wrong time. Understanding how the notification engine works makes these problems fast to diagnose and fix.
How Notifications Fire
A notification fires when:
- A triggering event occurs (record inserted, updated, or a specific condition is met)
- The notification's conditions evaluate to true against the triggering record
- There are recipients who should receive it (based on users, groups, or dynamic recipient fields)
- The notification is not suppressed by a maintenance window or user preference
All four conditions must be true. A notification that is firing but no one is receiving it usually means condition 3 or 4 is failing.
Notification Log — Your First Stop for Debugging
Navigate to System Mailboxes > Outbound > Sent to see all outbound notifications. This shows what was sent, to whom, and when.
Navigate to System Mailboxes > Outbound > Skipped to see notifications that were evaluated but not sent. The Skip Reason column tells you exactly why — invalid recipient, user opted out, maintenance window active, etc.
For real-time debugging, navigate to System Diagnostics > Session Debug > Debug Notifications and then trigger the event. The debug output shows the full evaluation trace.
Recipient Evaluation
Notifications can send to:
- Users — specific user records
- Groups — all members of a group
- Dynamic fields — values from the triggering record (assigned_to, caller_id, etc.)
- Event parameters — passed when the notification is triggered via gs.eventQueue()
Email Digests
Email digests batch multiple notifications into a single email, sent on a schedule. Users can configure digest preferences in their notification preferences. Digests reduce email volume but introduce latency — a user on hourly digest won't see a notification for up to an hour.
For time-sensitive notifications (P1 incidents, critical alerts), explicitly exclude them from digest by setting the notification's weight to High. High-weight notifications are always sent immediately regardless of user digest settings.
Common Notification Problems
Notification not sending — but no error
Check the Skipped mailbox first. The most common reasons:
- User has opted out of this notification category
- User's email address is blank or invalid
- Notification is in a maintenance window
- Duplicate notification suppression (same notification fired twice within the suppression window)
Users getting too many notifications
Audit the notification subscriptions on the user's record. Check for group memberships that are adding them to notification lists they don't need. Also check if they are on both the assigned_to field and in the assignment group — they may be receiving both the individual and group notification.
Notification template showing raw variables
Variables like ${caller_id} appear as literal text when the field is null or when the template variable references a field that doesn't exist on the table. Check the template variables against the actual table fields.
Notification Template Best Practices
// Always use dot-walking carefully in templates
// This works:
${caller_id.name}
// This throws an error if caller_id is null:
${caller_id.manager.email}
// Safe version:
${caller_id.manager != null ? caller_id.manager.email : 'No manager'}Testing Notifications Without Spamming Users
Before enabling a notification in production, use the Preview feature on the notification record to see exactly what the email will look like with real record data. You can specify a test record sys_id and the notification shows a rendered preview without actually sending anything.
For end-to-end testing, use a dedicated test email address rather than your personal email — this keeps test notifications separate from real ones and makes it easier to confirm delivery without confusion.