CSA Guide

Notifications and Email in ServiceNow

Introduction

Notifications are how ServiceNow communicates with users—alerting assignees when a ticket lands in their queue, informing callers when their incident is resolved, and escalating critical issues to managers. A well-tuned notification strategy reduces manual follow-up and keeps stakeholders informed without overwhelming inboxes.

This guide covers the full notification stack: triggers, templates, recipients, and debugging.

How Notifications Work

Database event (insert/update/delete)
    ↓
Notification condition evaluated
    ↓
Recipient list assembled
    ↓
Email template rendered
    ↓
Email queued → sent via SMTP

Notifications sit in sys_notification. Every notification record defines what triggers it, who receives it, and what the message looks like.

Notification Anatomy

When to Send

Table: Which table the record lives on (e.g., incident)
When: Insert, Update, or both
Conditions: The filter that must be true for the notification to fire (e.g., Priority is 1 - Critical)
Send when: Event is fired (event-driven) or Record inserted or updated (direct)

Weight

When multiple notifications could fire for the same event, weight determines precedence. Only the notification with the highest weight fires (unless multiple notifications are explicitly allowed via the "Send to event creator" and duplicate settings).

Email Templates

Templates (sys_email_template) define the subject and body, with variable substitution using ${field_name} syntax:

Subject: [${number}] Your incident has been updated

Body:
Dear ${caller_id.first_name},

Your incident ${number} — "${short_description}" — has been updated.

Current State: ${state}
Assigned To: ${assigned_to.name}

You can view your incident here:
${URI_REF}

Thank you,
IT Service Desk

Useful Variable Tokens

Token	Output
`${number}`	Record's number field
`${assigned_to.name}`	Dot-walk to reference display value
`${URI_REF}`	Direct link to the record
`${mail_script:my_script}`	Runs a Mail Script for dynamic content

Mail Scripts: Dynamic Content

For complex logic inside email bodies, use Mail Scripts (sys_script_email):

// Mail Script: include_workaround
try {
    var problem = new GlideRecord('problem');
    if (problem.get(current.problem_id)) {
        var workaround = problem.getValue('workaround');
        if (workaround) {
            template.print('<b>Available Workaround:</b><br>' + 
                workaround + '<br><br>');
        }
    }
} catch(e) {
    gs.error('Mail script error: ' + e.message);
}

Reference in a template body: ${mail_script:include_workaround}

Recipient Configuration

Who receives the notification is controlled by the Who will receive tab:

Recipient Type	Example
User field on record	`Caller`, `Assigned to`
Group field on record	`Assignment group`
Role	All users with `itil_admin`
Specific user	Individual users by name
Event parameter	Passed in from the triggering event

Subscription Model

Users can opt out of non-mandatory notifications via Notification Preferences in their profile. Mark notifications as Mandatory to prevent opt-out for critical alerts.

Event-Driven Notifications

For fine-grained control, trigger notifications via events:

Firing an event (in a Business Rule):

gs.eventQueue(
    'incident.priority.critical',  // Event name
    current,                        // GlideRecord context
    current.getValue('assigned_to'), // Parameter 1
    current.getValue('number')       // Parameter 2
);

Notification configured:

Send when: Event is fired
Event name: incident.priority.critical

This pattern decouples when the event occurs from when notifications fire, enabling reuse of the same event across multiple notifications.

Inbound Email Actions

ServiceNow can also receive and process email. Inbound Email Actions (sys_email_action) match incoming emails and take action:

Inbound email arrives
    ↓
Match rules evaluated (From address, Subject regex)
    ↓
Matching action executes script
    ↓
Record created or updated

Example script — create incident from email:

if (current.state == 'new') {
    var inc = new GlideRecord('incident');
    inc.initialize();
    inc.setValue('short_description', email.subject);
    inc.setValue('description', email.body_text);
    inc.setValue('contact_type', 'email');
    inc.insert();
}

Troubleshooting Notifications

Check the Email Log

System Mailboxes > Outbox
System Logs > Email Log

Every outbound email is logged here with delivery status, recipient, and full body.

Notification Diagnostic

On any notification record, use Preview Notification to test rendering against a specific record without sending.

Common Issues

Issue	Likely Cause	Fix
No email sent	Condition not met	Check notification conditions and record values
Duplicate emails	Multiple notifications firing	Review weight settings
Variable shows as blank	Field null or wrong dot-walk path	Test the field path on the record directly
User not receiving	Opted out	Check user's Notification Preferences or mark Mandatory
Email in outbox but not delivered	SMTP configuration	Check System Email Settings

Best Practices

Use templates for all notifications — avoid embedding HTML directly in the notification body
Keep subject lines short and include the record number for easy filtering
Test notifications in sub-prod before deploying to production
Mark critical operational notifications as Mandatory
Use event-driven notifications for complex trigger logic
Audit notification volume periodically — over-notification leads to users ignoring emails
Set a reply-to address that routes back into ServiceNow via Inbound Email Actions

Conclusion

Notifications are your instance's voice to the outside world. When designed well, they keep every stakeholder informed at the right moment with the right context. Over-engineer them and you create noise; under-build them and teams miss critical updates. The event-driven model and Mail Scripts give you the flexibility to handle any complexity while keeping notification records clean and maintainable.