Email Notifications & Templates

Notification Overview

ServiceNow notifications are automated messages sent to users when specific conditions are met on platform records. They are the primary mechanism for keeping users informed about record state changes, assignments, and important events.

What Triggers Notifications?

Notifications can be triggered by three fundamental mechanisms:

The sys_notification Table

All notification rules are stored in the sys_notification table. You can access and manage them via:

• Navigate to: System Notification > Email > Notifications
• Direct table: type sys_notification.list in the Filter Navigator
• Each record in this table defines one complete notification rule
• Notifications can be active or inactive — only active notifications fire

Three Delivery Types

Notification vs. Event vs. Email Client — Key Distinctions

Notification Rule Anatomy (CRITICAL for Exam)

Understanding every field in a notification rule is essential for the CSA exam. Each field controls a distinct aspect of when, how, and to whom the notification is sent.

Core Fields

When to Send (Trigger Tab)

Weight and Deduplication — Exam Critical

Conditions (Who Qualifies)

The Conditions section uses a filter condition builder to determine which records trigger the notification. Only records matching all conditions will generate the notification.

• Works like any standard record filter in ServiceNow
• Example: Priority is 1 - Critical AND State is not Resolved
• If no conditions are set, the notification fires for all matching inserts/updates
• Conditions are evaluated server-side against the current record state

Who Receives — Recipients Tab

The Recipients tab is one of the most important sections for the exam. It defines exactly who gets the email. Multiple recipient types can be combined.

Send Condition

Advanced Tab: Subject, Message, Devices

• Subject: The email subject line. Supports ${field_name} variable substitution for dynamic content.
• Message (HTML): The body of the email. Full HTML is supported. Can reference an Email Template or contain inline content with variable substitution.
• Message (Text): Plain-text fallback for email clients that do not render HTML.
• Device: The delivery channel — Email, SMS, or Meeting Invitation. Defaults to Email.
• Content type: HTML or plain text message format.

Email Templates

Email Templates allow you to create reusable HTML message bodies and subject lines that multiple notification rules can reference, maintaining consistency across communications and avoiding duplication.

• Stored in the sys_email_template table
• Navigate to: System Notification > Email > Templates
• A template defines reusable Subject and Message content
• Notification rules can reference a template, inheriting its content
• Individual notifications can override template content if needed

Variable Substitution Syntax

Both templates and inline notification messages support dynamic variable insertion using a dollar-sign bracket syntax. Variables are resolved at send time against the triggering record.

Template Example Structure

<!-- Subject line -->
[${number}] Your incident has been updated: ${short_description}

<!-- Message HTML body -->
<p>Dear ${caller_id.first_name},</p>

<p>Your incident <strong>${number}</strong> has been updated.</p>

<table>
  <tr><td><strong>State:</strong></td><td>${state}</td></tr>
  <tr><td><strong>Assigned To:</strong></td><td>${assigned_to.name}</td></tr>
  <tr><td><strong>Priority:</strong></td><td>${priority}</td></tr>
</table>

<p>$[link]</p>

<p>Thank you,<br>IT Service Desk</p>

Shared Templates vs. Notification-Specific Content

Notification Subscriptions

ServiceNow gives users control over which notifications they receive through a Notification Preferences system. Administrators control which notifications can be opted out of and which are mandatory.

How Users Manage Preferences

• Users access preferences via: Profile icon > Notification Preferences (or System Settings > Notifications)
• The preferences UI shows all subscribable notification categories and individual notifications
• Users can opt in or opt out per notification, per category, and per device type (email vs. SMS)
• Admin-set mandatory notifications do not appear in the opt-out list — users cannot disable them

Mandatory vs. Subscribable Notifications

Notification Categories and Devices

• Categories group related notifications together (e.g., all "Incident" notifications in one category). Users can enable/disable an entire category at once.
• Devices represent delivery channels. A single notification can have preferences managed per device — a user may want Incident email alerts but not SMS alerts for the same event.
• Categories are configured on notification records and help users navigate their preferences UI.

sys_notif_subscription Table

User subscription preferences are stored in the sys_notif_subscription table. Each record represents a user's explicit opt-in or opt-out choice for a specific notification.

• Navigate to: sys_notif_subscription.list in the Filter Navigator
• Contains: User, Notification, Device, Subscribed (yes/no)
• Administrators can view and manage subscriptions for users from this table
• If no subscription record exists for a user, the notification's default behavior (send or don't send) applies

Email Digest vs. Immediate Delivery

Events

Events are a core part of the ServiceNow automation architecture. They decouple the action that triggers something from the action that responds to it, enabling clean separation of concerns and reusable event-driven logic.

The Event Pattern

gs.eventQueue() — The Event Firing Method

// Signature:
gs.eventQueue(eventName, record, param1, param2);

// Example: fire an event when an incident is assigned
// Typically called from a Business Rule (After, on update)
gs.eventQueue('incident.assigned', current, current.assigned_to, current.assignment_group);

// eventName  — string matching a registered event in the Event Registry
// record     — the GlideRecord context (current, previous, etc.)
// param1     — optional parameter 1 (max 256 chars), accessible in notification as ${event.parm1}
// param2     — optional parameter 2 (max 256 chars), accessible in notification as ${event.parm2}

Event Registry (sysevent_register)

• The Event Registry (sysevent_register table) contains all defined/registered event names on the instance
• Navigate to: System Policy > Events > Registry
• Before you can fire an event, it should be registered here (though it will still queue even if unregistered)
• Each registration record includes: Event Name, Table, Description, fired by (which system component)
• Best practice: always register custom events before using them in scripts

Event Log (sysevent)

• The Event Log (sysevent table) is the actual queue of fired events
• Navigate to: System Policy > Events > Event Log or sysevent.list
• Each row represents one queued event instance, with columns for: Event Name, Table, Record sys_id, Param1, Param2, State (ready, processed, error), Processing time
• The event processor runs periodically and changes State from "ready" to "processed"
• Invaluable for debugging: if a notification is not firing, check the Event Log to verify the event was actually queued and processed

Business Rule → Event → Notification Pattern (Exam Scenario)

Inbound Email Actions

Inbound Email Actions allow ServiceNow to automatically process incoming emails and take actions on records — creating new records, updating existing ones, or running scripts based on email content.

• Stored in the sys_email_inbound_action table
• Navigate to: System Notification > Inbound Actions
• ServiceNow's mail server receives incoming email, which is then matched against inbound action rules
• Multiple inbound actions can be defined; they are evaluated in order by the Order field
• An inbound action can stop processing further rules once matched (like a catch-all)

Inbound Action Anatomy

Reply Separators

When a user replies to a notification email, ServiceNow must extract the new content from the reply and ignore the quoted original message. Reply separators define the delimiter between new and quoted content.

• Navigate to: System Notification > Inbound Actions > Reply Separators
• Default separator patterns match common email client quotation markers (e.g., --- Reply above this line ---)
• Only the text above the separator is processed as new content and added to the record
• Custom separators can be added to handle non-standard email clients or formats

Email-to-Record Correlation

Common Inbound Action Use Cases

Key Exam Facts & Common Traps

This section consolidates the highest-frequency exam points on notifications and templates. Review these carefully before exam day.

Quick Reference — All Key Tables