ServiceNow Notifications and Emails

ServiceNow sends automated email notifications to users when specific events happen — an incident is created, a request is approved, an SLA is about to breach, or a task is assigned. Notifications keep everyone informed without manual communication. Administrators configure exactly who receives each notification, when it sends, and what the email contains.

How Notifications Work

Event occurs in ServiceNow (e.g., Incident created)
        │
        ▼
ServiceNow checks all active Notifications
        │
        ▼
Finds matching notification:
  Table = incident, When = Created, Condition = Priority = 1
        │
        ▼
Builds email using the notification's template
        │
        ▼
Identifies recipients (caller, assignment group, etc.)
        │
        ▼
Sends email via ServiceNow's mail server
        │
        ▼
Recipient receives email with ticket details and link

Creating a Notification

Navigate to System Notification > Email > Notifications and click New. The notification form has four main sections:

When to Send

Define the event that triggers the notification:

• Table: Which table (incident, change_request, sc_task, etc.)
• When: Record inserted, updated, or deleted
• Filter Conditions: Additional conditions that must be true (e.g., Priority = 1, State changes to Resolved)

Who Will Receive It

The notification targets specific recipients. ServiceNow supports multiple recipient types simultaneously:

• Users: A specific named user always receives the notification.
• Groups: All members of a selected group receive it.
• Event fields: Dynamic recipients based on the record — the Caller, the Assigned To user, the Assignment Group members, or the record's approvers.

Notification: "Incident Assigned to You"
Recipients:
  ✓ Event: Assigned to User (the person the ticket was just assigned to)
  ✓ Event: Opened by (the person who submitted the ticket)
  ✗ Do NOT include: Assignment Group (too many emails to the whole team)

What It Will Contain

The notification's subject and body use a combination of plain text and variable substitutions. Variable substitutions pull field values from the record dynamically at send time.

Subject Template:
[${number}] Incident Assigned: ${short_description}

→ Sends as:
[INC0001234] Incident Assigned: Email not working

Body Template:
Hello ${assigned_to.first_name},

Incident ${number} has been assigned to you.

Details:
Priority:    ${priority}
Description: ${short_description}
Link:        ${URI_REF}

Please take action before: ${sla.breach_time}

The Message (HTML and Plain Text)

Notifications include both an HTML version (formatted, styled) and a plain text version. Email clients that support HTML display the formatted version. Older clients or accessibility-focused clients use plain text. Administrators write both versions — or configure the notification to generate plain text automatically from the HTML version.

Email Scripts

For complex notification logic, administrators use Email Scripts — reusable JavaScript functions that return dynamic text for use inside notification templates. An email script might calculate the number of open related incidents, check a condition, and include different text based on the result. Email scripts keep notification templates clean and maintainable.

Inbound Email Actions

ServiceNow also handles incoming emails. When a user replies to a notification email, the reply routes back into ServiceNow through an Inbound Email Action. The inbound action reads the email's subject for the ticket number, locates the matching record, and appends the email body as a work note or additional comment — closing the loop without requiring the user to log into ServiceNow.

User receives notification for INC0001234
  → User replies to the email: "I tried your solution, still broken"
  → ServiceNow receives the reply
  → Inbound Email Action matches the email to INC0001234
  → Adds the user's reply as an Additional Comment on the incident
  → Notifies the assigned agent of the new comment

Notification Preferences

Users control their own notification preferences from their profile menu. They subscribe to or unsubscribe from specific notification types. Administrators can mark certain notifications as mandatory (users cannot unsubscribe). SLA breach warnings and critical incident alerts typically carry the mandatory flag.

Testing Notifications

The notification form includes a "Preview Notification" option. This renders the subject and body using a selected test record — showing exactly what the email will look like before it goes live. Administrators also use the "Send test email" button to fire the notification to themselves immediately, verifying formatting, variable substitutions, and recipient logic before the notification affects real users.