# Notifications and Escalations

> Chapter 11 of the Courseiva SERVICENOW-CSA curriculum — https://courseiva.com/learn/servicenow-csa/notifications-and-escalations

**Official objective:** 3.2 — Configure email notifications, subscription rules, and escalation rules.

## Introduction

Notifications and escalations are the nervous system of a ServiceNow instance, ensuring the right people hear about the right events at the right time. Without them, a critical outage could go unnoticed, or a ticket could sit untouched for weeks. For the SNOW-CSA exam, you must understand how to configure email notifications based on events, how subscription rules let users control their own alerts, and how escalation rules automatically increase the urgency of overdue tasks.

## The Lost Package at a Apartment Building Analogy

The lobby of a busy apartment building, with a security desk and a bank of mailboxes. A parcel arrives for a resident who is not home. The security guard, Alex, sorts the mail. He sees a package for Apartment 3B. His job includes two related tasks: first, he must let the resident know the package is here, and second, if the resident doesn't collect it, he must decide what to do next.


Alex's first task is the notification. He slides a note under the door of Apartment 3B saying, "Your package is at the front desk." If the resident doesn't respond in 24 hours, Alex's process escalates. He sends a second, more urgent note: "Please collect your package by tomorrow, or it will be returned." If still ignored, Alex escalates again, this time notifying the building manager that the package is abandoned. To avoid annoying everyone, residents can set a preference: "I want a text, not a note" or "Don't tell me about packages under 1kg." This is a rule, or a subscription, that controls how and when the notification is sent. The package itself is the record in ServiceNow, the resident is the user, and Alex's escalating urgency is the escalation rule. The system ensures no package is forgotten and that the right person gets the right message at the right time.

## Core explanation

Notifications and escalations are the two main mechanisms ServiceNow uses to keep work moving and people informed. A notification is an automatic message — typically an email — sent when a specific event happens in the system. An event is any significant occurrence, such as a new incident being created, a record being updated, or a task reaching a certain state. The notification system watches for these events and, when it sees one, checks if any notification rules are configured to react. It then sends the message to the appropriate recipients.


Escalation rules are different. They automatically change the priority or assignment of a record when a time limit is breached. For example, if a high-priority incident has not been resolved within two hours, an escalation rule might automatically reassign it to a senior team or increase its priority. This prevents work from stagnating.


Let's break down the key parts of a notification. A notification rule has a name, a table (like Incident or Change Request), a condition (when to send), a who (who receives it), and a what (the email template). The condition is written as a condition builder statement, such as "State changes to In Progress" or "Priority equals 1 - Critical." The who can be a dynamic user (the assigned user, the caller, the manager of the assignee, a group) or a specific user or group defined in the rule. The what uses a mail script or a template to draft the email body and subject. You can also use content blocks to reuse common parts of emails, like a standard header or footer.


Subscription rules add a layer of user control. A user does not want to receive every email about every record in the system. Instead, they can subscribe to a specific record (like an incident they care about) or to a category (like all incidents in a particular group). Subscription rules allow users to decide which notifications they receive. In the exam, you need to know that a subscription rule exists on a table and defines conditions under which a user automatically receives notifications for records matching that condition. Users can also manually subscribe to individual records via the Subscribe button on a form.


Notification templates are stored in the sys_template table. You create a template with a subject and body, and you can embed field values from the record using placeholders like ${number}, ${short_description}, or ${assigned_to}. This personalises the email. Mail scripts are more advanced. They are Server Side JavaScript scripts that build the email body programmatically. This allows for complex logic, such as including different information for different states.


There are several types of notification recipients:

- User: sends directly to a specific user's email.
- Group: sends to all members of a group.
- Roles: sends to all users with a specific role, like itil or catalog_admin.
- Watchers: sends to users who are watching the record.
- Dynamic: uses a script to determine who receives the notification, based on the record data.


Escalation rules live in the Escalation Rules module. They are defined per table and have a sequence number. The system checks escalations based on a schedule (every hour by default). An escalation rule checks if the time since the record was created or last updated has exceeded a threshold, and if so, it changes a field on the record—for example, setting Escalation to 1, 2, or 3—and optionally sends a notification. It can also reassign the record to a different user or group. A common use-case is to update the incident's escalation field when its SLA (Service Level Agreement) is about to breach.


Why does this matter? In a world without these tools, IT staff would spend hours manually checking for old tickets and sending reminder emails. Notifications and escalations automate that boring but critical work. They ensure accountability and responsiveness. The SNOW-CSA exam expects you to know how to create and test a notification, how to set up a subscription rule, and how escalation rules function. You do not need to write JavaScript, but you must understand the logic of the condition builder and the purpose of each field.

## Real-world context

Consider a real IT support team at a mid-sized company handling 200 tickets a day. The team uses ServiceNow for Incident Management. Without notifications and escalations, a technician might forget about a critical server-down ticket. The business would lose revenue, and the technician would receive a complaint from management. Here is what the system actually does.


The ServiceNow administrator, Priya, sets up an email notification for the Incident table. The condition is: when Priority equals 1 - Critical and State equals New. The event is "insert" — meaning the notification fires when a new record is created. The recipients are the Assignment group (the support team) and the Incident Manager. The email template includes the number, short description, and caller. Every time a critical incident comes in, the entire team gets an alert within seconds.


Next, Priya configures an escalation rule. She knows that high-priority incidents must be acknowledged within 30 minutes. She creates an escalation rule on the Incident table with sequence 10. The condition checks that Priority is Critical and the record has been in New state for more than 30 minutes. When this condition is true, the rule does two things:

- Updates the Escalation field to 1 (first level escalation)
- Changes the Assignment group to the Level 2 support group


Now, if the original team does not act within 30 minutes, the record automatically moves to a more senior team. Priya also adds a second escalation rule (sequence 20) that fires after 60 minutes, changing the assignment to the senior manager and sending a notification.


Subscription rules are configured so that users can choose to follow a record even if they are not directly assigned. For example, a database administrator can subscribe to all incidents with a category of "Database" to stay informed, without being the main contact. The administrator configures a subscription rule on the Incident table where the condition is Category equals Database and Role equals dba. Any user with the dba role who matches that rule automatically receives notifications for those records.


In practice, Priya also creates a notification template with a professional look, adding a standard footer with support hours. She uses a mail script to include a link to the record so users can click directly into the incident. She then tests the notification by creating a critical incident record and verifying the email arrives. She checks the email logs in ServiceNow under System Logs > E-mail > Sent E-mails to confirm the email was sent and to identify any errors.


Escalation rules are tested by setting a record's creation time to 45 minutes earlier and then running the escalation job manually via Scheduled Jobs. Priya ensures the escalation does not fire unnecessarily by double-checking the condition logic. The result is a self-managing system where tickets are never forgotten, and the right people are always in the loop.

## Exam focus

The SNOW-CSA exam devotes a significant portion of the Notifications and Escalations objective to three main areas: Email Notifications, Subscription Rules, and Escalation Rules. You will see multiple-choice questions that test your ability to identify the correct configuration steps and the purpose of each component.


Key exam topics:

- The concept of an 'event' in ServiceNow: what triggers notifications? Understand that 'event' can be things like record insert, update, delete, or state change. They love to ask: 'Which of the following events triggers a notification?'
- The condition builder: know how to define 'when to send' the notification. Exam questions often present a scenario and ask you to choose the correct condition.
- Recipient types: Users, Groups, Roles, and dynamic scripts. You must know the difference between sending to the assigned user versus the caller versus the manager.
- Notification templates and mail scripts: what is the difference? A template is static, a mail script is code. They may ask, 'When would you use a mail script instead of a template?'
- Subscription rules: they ask about the difference between a user manually subscribing to a record versus an automatic subscription rule. Key: subscription rules automatically create follow records based on conditions.
- Escalation rules: know that they are table-specific, have a sequence, and can update fields or change assignments. They might ask, 'What field is typically updated by an escalation rule?' Answer: Escalation field (0, 1, 2).


Common traps and patterns:

- 'A notification is sent to the entire company when a new incident is created.' Trap: notifications are restricted by conditions and recipients. The correct answer often involves the condition builder restricting to 'Priority = Critical' or similar.
- 'Escalation rules send an email.' Trap: escalation rules can optionally send a notification, but their primary action is to update a field or reassign. Some questions test that the primary purpose is to change the record, not just to send a message.
- 'Subscription rules must be enabled by the system administrator.' Trap: users can control their own subscriptions via the self-service portal. Subscription rules define automatic subscriptions, but users can also manually subscribe.
- 'All notifications use the same template.' Trap: each notification rule can use a different template. Also, you can create multiple templates for different purposes.


Key definitions to memorise:

- Event: a trigger that initiates a notification.
- Notification rule: the configuration that defines when, how, and to whom a notification is sent.
- Subscription rule: a rule that automatically subscribes users to records based on conditions.
- Escalation rule: a rule that automatically changes a record's fields or assignment after a time threshold.
- Template: a reusable HTML email content definition.
- Mail script: a server-side script that generates email content programmatically.


Exam tips:
- Read the question carefully for the word 'automatically' versus 'manually'. Automated processes use rules; manual ones use buttons.
- Pay attention to whether the question asks about 'notifications' (which send email) or 'escalations' (which change the record).
- Know the menu path: Notifications are under System Notification > Email > Notifications. Escalation rules are under System Policy > Escalation Rules. Subscription rules are under System Policy > Subscription Rules.
- Practise identifying the correct condition operators (like 'changes to' or 'equals') in the condition builder.

## Step by step

1. **Identify the Trigger Event** — Determine what occurrence in ServiceNow should cause a notification or escalation. For a notification, this is an event like a record being inserted, updated, or deleted. For an escalation, it is the passage of time since the record was created or last updated. This step is crucial because it defines the starting point for the rule's condition.
2. **Define the Condition** — Create the condition statement that must be true for the rule to execute. For notifications, use the condition builder to specify, for example, 'Priority = Critical AND State = New'. For escalations, the condition typically includes a time threshold, such as 'Created on less than 2 hours ago'. The condition ensures the rule only fires for relevant records.
3. **Configure the Action** — Decide what happens when the condition is met. For notifications, you configure the email template, mail script, and recipients. For escalations, you set which fields to update (like the 'Escalation' field) and optionally whether to send a notification. This step determines the outcome of the rule.
4. **Test the Configuration** — Create a test record that matches the condition and verify that the notification is sent or the escalation fires. Use the Email Logs module to check if emails were sent without errors. For escalations, manually run the escalation scheduler job to check the result. Testing is essential to avoid unintended alerts or missed escalations in production.
5. **Monitor and Adjust** — Once the rule is live, monitor its behaviour through reports and logs. If users are receiving too many emails, adjust the condition or enable subscription rules. If escalations are not firing on time, change the schedule interval. Continuous improvement ensures the system remains helpful rather than noisy.

## Comparisons

### Notification Rule vs Escalation Rule

**Notification Rule:**
- Triggers on an event like insert or update
- Sends an email to defined recipients
- Does not change the record's data

**Escalation Rule:**
- Triggers on a time threshold passing
- Updates fields (like Escalation) on the record
- Optionally sends a notification, but its primary action is to modify the record

### Manual Subscription vs Automatic Subscription Rule

**Manual Subscription:**
- User clicks Subscribe button on a record
- User decides which records to follow
- Applies only to that individual record

**Automatic Subscription Rule:**
- Configured by an administrator
- Automatically subscribes users based on conditions
- Applies to multiple records that match the condition

### Notification Template vs Mail Script

**Notification Template:**
- Static HTML content with placeholders
- No JavaScript required
- Easier to maintain for simple emails

**Mail Script:**
- Dynamic content built with JavaScript
- Allows conditional logic and loops
- Suitable for complex or data-driven email content

### Email Notification vs In-App Notification

**Email Notification:**
- Sent via the email system
- Appears in the recipient's email inbox
- Can include attachments and links

**In-App Notification:**
- Appears in the ServiceNow user interface (banner/bell)
- Only visible when the user is logged into ServiceNow
- No external email infrastructure needed

## Diagram

_Flow of an event through notification and escalation rules, showing how conditions determine whether a message is sent or a record is escalated._

```mermaid
flowchart TD
    E[Event: Ticket Created] --> C{Condition Met?}
    C -->|Yes| N[Notification Rule]
    N --> RC[Recipients: User/Group/Role]
    N --> TP[Template/Mail Script]
    C -->|No| D[No Action]
    E --> TC[Time Check Timer]
    TC -->|Threshold Exceeded| ER[Escalation Rule]
    ER --> UF[Update Escalation Field]
    ER --> RA[Reassign Record]
    ER --> ON[Optional Notification]
    UF --> L[Record Escalated]
    RA --> L
```

## Common misconceptions

- **Misconception:** Notifications can only be sent when a record is created. **Reality:** Notifications can be triggered on any event, including updates, deletions, state changes, or even custom events defined by scripts. (Beginners see the default example of a new incident notification and assume that is the only trigger.)
- **Misconception:** Escalation rules and notifications are the same thing because both send emails. **Reality:** Escalation rules primarily change field values on a record (like the escalation level), and they may optionally send a notification, but their core function is to update the record, not to communicate. (Many beginners see that escalations 'notify' a new group and conflate the two concepts.)
- **Misconception:** If I set up a subscription rule, all users in the system will automatically get notifications for those records. **Reality:** Subscription rules apply only to users who meet the condition defined in the rule (e.g., users with a certain role or in a specific group). (The word 'subscription' sounds like an opt-in for everyone, but it is actually a targeted automatic subscription for specific users.)
- **Misconception:** You can only send notifications to individual users, not to groups. **Reality:** Notifications can be sent to groups, roles, users, watchers, or even dynamically determined recipients via script. (Beginners often only see the 'User' option in examples and miss the other recipient types.)
- **Misconception:** Escalation rules work instantly the moment a record is created. **Reality:** Escalation rules are evaluated on a schedule, typically every hour, so they do not fire instantly. They check if the time since creation or last update has exceeded the threshold. (People imagine real-time behaviour, but the system uses a batch job for performance reasons.)

## Key takeaways

- A notification is an automated email triggered by a specific event in ServiceNow, such as a record being created or updated.
- Escalation rules automatically update a record's fields (like raising its priority) when a time limit passes, helping to prevent work from being ignored.
- Subscription rules automatically subscribe users to follow records based on defined conditions, so they receive notifications without manual action.
- Notifications can be sent to users, groups, roles, or dynamically determined recipients using scripts.
- The condition builder in a notification rule uses operators like 'changes to' and 'equals' to decide exactly when a notification should fire.
- Escalation rules are evaluated on a schedule, not in real time, so there is a delay between a record ageing and the rule executing.
- A notification template defines the subject and body of an email, and can include placeholders like ${number} to pull in record data.
- Mail scripts allow you to write JavaScript to customise the email content beyond what a template alone can do.

## FAQ

**How do I create a notification in ServiceNow?**

Navigate to System Notification > Email > Notifications, click New, and configure the table, condition, recipients, and email template. Then activate the notification to start sending.

**What is the difference between a notification template and a mail script?**

A notification template is a static HTML email with placeholders for record fields, while a mail script is a piece of JavaScript that dynamically generates the email content, allowing for complex logic.

**Can a user stop receiving notifications without the administrator changing anything?**

Yes, users can unsubscribe from individual record notifications using the Subscribe button, or they can manage their preferences in the user profile if subscription rules are in place.

**How do escalation rules work with SLAs?**

Escalation rules can be tied to SLA definitions. An SLA defines a time limit for a task, and when that SLA is about to breach, an escalation rule can automatically reassign the record or raise its priority.

**What is the purpose of the 'Escalation' field on a record?**

The Escalation field (values 0, 1, 2) indicates the current escalation level. An escalation rule can update this field to 1 or 2 to show that the record has been escalated to a higher level of support.

**How do I test an escalation rule without waiting for the time threshold?**

You can manually run the escalation job by navigating to Scheduled Jobs, selecting the appropriate escalation job, and clicking Execute Now. Change the record's creation time temporarily to simulate an older record.

## Check your understanding

1. **When creating a notification on the Incident table, where do you define that the email should only be sent when the incident's priority is 'Critical'?**

   Answer: In the condition builder field of the notification rule, you add a condition such as 'Priority equals Critical' under the 'When to send' tab.

2. **What is the primary difference between a notification rule and an escalation rule?**

   Answer: A notification rule sends an email, while an escalation rule modifies fields on the record (like the Escalation field) and may also change the assignment.

3. **How can a user choose to follow a specific incident record without being the assignee?**

   Answer: The user can click the Subscribe button on the incident form to receive notifications for that record.

4. **What is the purpose of a subscription rule in ServiceNow?**

   Answer: A subscription rule automatically subscribes users to notifications for records that match a defined condition, without requiring manual action from the user.

5. **How do escalation rules determine when to fire?**

   Answer: Escalation rules use a scheduled job that checks if the time since the record was created or last updated exceeds a configured threshold.

---

Interactive version with quiz and diagrams: https://courseiva.com/learn/servicenow-csa/notifications-and-escalations