ServiceNow Notifications: The Complete Setup and Troubleshooting Guide

// 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'}

Notification triggers and when they fire

ServiceNow notifications are triggered by record events — insert, update, or both. Understanding when the notification trigger fires and what data is available at that point is essential for building reliable notifications.

• Insert — fires when a new record is created. Good for "new request received" notifications. The record fields are populated with the inserted values.
• Update — fires when a record is updated. Good for "state changed" or "assigned to you" notifications. Use the ${previous_value} field reference syntax to include the value before the update.
• Insert or Update — fires on either event. Good for notifications where the trigger condition handles the distinction — a notification that fires whenever state=Resolved, whether it was just inserted as Resolved or updated to Resolved.

The Condition on the notification filters which records and which updates trigger it. The condition runs after the event fires — if the record was updated but the condition evaluates to false, the notification does not send. Use conditions to ensure notifications fire only when meaningful — "Assigned to changed AND assigned_to is not empty" for assignment notifications, "State changed to Resolved" for resolution notifications.

Who receives the notification — the recipient model

The Recipients section of a Notification record defines who receives it. ServiceNow provides several recipient types:

• User field on record — the user in a specific reference field (assigned_to, caller_id, opened_by). The most common recipient type.
• Group field on record — all members of the group in a reference field (assignment_group, watch_list). Members must have email notifications enabled.
• Role — all users with a specific role. Use carefully — role-based notifications can send to large audiences unintentionally.
• User or group — a specific hardcoded user or group. Useful for escalation and emergency notifications.
• Script — a server-side script that returns a list of users. Maximum flexibility for complex routing — if the standard recipient types cannot express your routing logic, use a script recipient.

Message templates and variable references

// Example notification message template variables
Subject: [INCIDENT] ${number} - ${short_description}

Body:
A new incident has been assigned to you.

Incident: ${number}
Priority: ${priority}
Description: ${short_description}

Assigned by: ${sys_updated_by}
Time: ${sys_updated_on}

State: ${state}
Category: ${category} / ${subcategory}

View incident: ${URI_REF}

// Reference related records with dot-walk:
Caller: ${caller_id.name}
Caller email: ${caller_id.email}
Department: ${caller_id.department.name}

// Previous values (for Update notifications):
Previous state: ${previous_state}
Previous assignment: ${previous_assignment_group.name}

Email digests and notification scheduling

For notifications that should not interrupt the recipient in real time — weekly summaries, daily metric reports, periodic reminders — use the Digest feature on the Notification record. A digest collects notification instances over a configured period (hourly, daily, weekly) and sends them as a single bundled email rather than individual messages. This significantly reduces email noise for notifications that trigger frequently but are not individually time-sensitive.

Related: Business Rules for notification triggers · Flow Designer triggers · SLA breach notifications · Scheduled Jobs for digest-style reports

Notification troubleshooting — the systematic approach

When a notification is not sending, diagnose in order: First, check the System Email Log (System Mailboxes > Outbound > Sent) — if the email appears there, it sent from ServiceNow but may have been filtered by the recipient's mail server. Second, check the Notification record's Condition — use the Condition Builder to test the condition against the record that should have triggered it. Third, check who should receive the notification under the Recipients tab — if the recipient list evaluates to empty, no email is sent without error. Fourth, check the Event Log (System Log > Events) if the notification uses an event trigger — confirm the event was fired. Fifth, check whether the notification is being suppressed by a user's notification preferences or by the record's Watch List configuration. This five-step sequence resolves 95% of notification issues without needing ServiceNow support.

Related: Business Rules for event-firing triggers · Flow Designer for flow-triggered notifications · SLA notifications · Scheduled Jobs for digest-style reports

Notification Conditions and Business Rules

Every notification has two condition layers: the notification condition (when to send) and the notification recipient conditions (who to send to). The notification condition evaluates against the triggering record — it is the same filter syntax used in GlideRecord encoded queries. The recipient conditions determine which users or groups receive the notification based on the record's field values and the user's relationship to the record. Understanding both layers prevents the common mistake of creating a notification that fires correctly but reaches the wrong recipients — or one that has correct recipients but fires on every update instead of just the triggering condition. Test both layers explicitly by simulating the triggering condition and verifying the recipient list before activating a notification in production.

Notification Templates and Dynamic Content

Notification templates use a variable syntax to include record field values in the subject and body. Standard variables follow the pattern ${field_name} for the triggering record's fields. For related records, the dot-walk syntax works: ${caller_id.name} inserts the caller's display name. The template engine also supports scripted variables defined in the Notification Script field — these are evaluated at send time and can perform GlideRecord lookups or complex string formatting that goes beyond simple field substitution. For HTML-formatted email notifications, test the template in multiple email clients since HTML rendering varies significantly between Outlook, Gmail, and mobile clients. Keep the plain-text version accurate for users who receive plain-text email.

Notification Digest and Frequency Controls

ServiceNow's notification digest feature batches multiple notifications into a single email for users who would otherwise receive high volumes of individual messages. This is particularly important for Scheduled Job-triggered notifications that might send hundreds of emails during a batch processing run. The digest configuration specifies a time window (e.g., "bundle all notifications of this type in a 15-minute window") and controls how the bundled message is formatted. For ITSM notifications in high-volume environments, implementing digest for update notifications while keeping create and escalation notifications immediate provides a balance between keeping users informed without overwhelming their inboxes. Users can typically control their own digest preferences through their profile notification preferences.

Notification Delivery Troubleshooting

When notifications are not being received, the investigation path follows a clear sequence. First, check the Outbound Email Log (sys_email table, filtered to type = send) to see whether the notification was created and attempted. A record with state = sent means ServiceNow successfully handed the email to the mail relay — the problem is downstream (spam filters, recipient address issues). A record with state = error means the notification was generated but delivery failed — check the error field for SMTP authentication or connection errors. If there is no email record at all, the notification either did not trigger or the recipient evaluation excluded all recipients — use the Notification Activity view to see the evaluation trace for recent notification triggers. The debugging guide covers the general log analysis patterns applicable here.