ServiceNow Notification Explained

What Is a Notification?

A notification in ServiceNow is an automated message sent to a user when a defined event occurs or a condition is met: an incident is assigned to you, a change you requested is approved, a request is ready for collection. Notifications can go out by email, as in-app messages shown when you log in, by SMS or through other channels your platform is configured for. They are how the platform keeps people informed about the things that affect them without anyone having to keep checking the system.

Notifications are records in the Notification table. Each notification has a name, a trigger condition (what event causes it to fire), a message body, and delivery configuration. Notifications are event-driven: when the trigger condition matches, ServiceNow creates a notification record and sends it to the specified recipients.

Common Notification Triggers

Assignment notifications trigger when a record is assigned to a user. You might have a notification that fires when an incident is assigned to the service desk, alerting the assignee. State-change notifications trigger when a record transitions to a specific state. For example, when a change moves to “approved” state, the requester receives a notification. Assignment expiration notifications trigger when an assigned record reaches an SLA threshold without being updated. Escalation notifications trigger when a record violates its SLA.

Custom notifications use conditions you define. You might create a notification that fires when an incident severity is critical, or when an incident’s caller is an executive, or when a problem has three or more linked incidents. The trigger condition is a query or filter that determines whether the notification fires.

Notification Recipients and Personalization

You specify who receives a notification using recipient rules. A notification might go to the record’s assignee, the requester, a specific role, or a mailing list. You can personalise the notification body using variable substitution: ${incident.number} gets replaced with the actual incident number, ${incident.short_description} with the actual description. This lets you create one notification template that generates customised messages for each recipient.

Notifications can be conditional on the recipient. You might create a notification that goes to the incident’s assignment group only if the incident is critical. Or a notification that goes to the user’s manager only if the user is in a specific department. These conditional rules allow sophisticated routing without creating separate notifications for every combination.

Delivery Channels

Email is the most common notification delivery channel. When a notification fires, ServiceNow sends an email to the recipient. In-app notifications appear when the user logs into ServiceNow—a banner or toast message that persists until the user acknowledges it. SMS notifications send text messages to users’ registered phone numbers. Some organisations integrate with Teams or Slack to send notifications to those channels. The delivery channel depends on your ServiceNow configuration and licenses.

Notification Behavior and Best Practices

Notifications can cause alert fatigue if you send too many or use them for things that are not urgent. A user receiving fifty notifications per day will ignore them. Be selective about what warrants a notification. Reserve notifications for events that require action or immediate awareness: assignments, escalations, approvals, critical state changes. Do not use notifications for informational updates that users can check on demand.

Notifications should be timely and valuable. When a user receives a notification, they should immediately understand why they received it and what action to take. A notification saying “incident is assigned to you” is clear. A notification saying “something changed in a record you are interested in” is vague and less useful.

Notification Scheduling and Preferences

Users should be able to control when they receive notifications. A support agent might want assignment notifications only during working hours, not at 3 a.m. Escalation notifications should probably always go through, even outside working hours. ServiceNow notification preferences let users customize what they receive and when. However, not all notifications should be deferrable—critical security alerts should reach people immediately regardless of preference.

Notification Challenges

Notification delivery can be unreliable if your email system is overloaded or if user email addresses are incorrect. Notifications queued for delivery but not actually sent create confusion. Use dashboard reports to monitor notification delivery: track how many notifications fired, how many were actually sent, and how many users marked them as unread.

Another challenge is notification fatigue: users receive so many notifications they stop reading them. If your trigger conditions are too broad or your notifications are not clearly prioritised, users will tune them out. Regularly audit notification effectiveness and disable notifications that generate low engagement.

Start with the message that should never be sent

Notification design is easier when you first list the messages the business does not want. A person who receives the same assignment email three times in an afternoon will start filtering all mail from the platform, and the important escalation goes unread along with the noise. A common cause is a business rule that updates the record each time it runs, where the update itself fires another notification. Write down the three or four messages that would embarrass the team if they arrived by accident, such as a closure notice to a customer who has not been informed of the fix, or an approval request sent to the wrong approver after a reassignment. Those negative cases shape the design more than the wanted list.

Recipient logic that survives a reassignment

Recipients are the part of a notification that goes stale fastest. The assignee changes, the requester leaves the company, a mailing list is renamed and the old list keeps receiving messages for months. A notification that names a person directly is brittle. A notification that resolves its recipient from the record at send time, through the assignee, the caller or a group, is more resilient, provided the group membership is maintained. Review each notification’s recipient rule against three events: a reassignment, a user deactivation and a group rename. If the rule behaves badly in any of them, change the rule before anyone else is asked to rely on it.

Message type	Recipient rule that holds up	Failure to watch for
Assignment to an individual	The assigned person at the moment the record changes	Duplicate messages when a record is reassigned several times in quick succession
Approval request	The current approver resolved at send time, with the approval record as the link	A stale approver who has left the company still receives the request
Status update to a requester	The caller or requester, filtered to changes they are allowed to see	Internal work notes leaking into the customer-facing text
Escalation to a group	The group, with a condition on priority or breach state	Every member of a large group receives the message, which tends to remove any sense of ownership

How to test a notification without emailing real people

The safer pattern is to run each notification as a designated test user, or to point its recipients at a small test group, then check three things: the message fires only once for each event, the body reads correctly with the variables populated, and the recipient is the one the rule intended. Run the same checks again whenever the trigger condition changes, because a condition that looks tighter can still match on a field update the team did not expect. Keep a short written list of the scenarios you tested, so the next person to change the notification can rerun the same checks.

Ordered steps for a notification clean-up

1. Export the list of active notifications, with their triggers, recipients and the table each one watches.
2. Mark each notification as needed, merge-candidate or retire, based on whether a person has said they act on it.
3. For each notification to keep, check the recipient rule against reassignment, deactivation and group rename, and record the result.
4. Find any business rule that writes to a record a notification watches, and decide whether the write is needed or can be removed.
5. Test the retained notifications in sub-production, then retire the ones marked for removal in a single change with a rollback note.

Notifications are not the answer to every question

A notification pushes a message to someone. A dashboard waits to be opened, and a task sits in a queue with an owner. When the message only asks people to look at a number, a dashboard view or a daily digest is usually more honest about its purpose. When the message needs a response within a defined window, a task with a due date and an owner tends to work better than an email that can be buried. Use a notification when the person must be told something at the moment it happens, and use the other tools for information that can wait.

Frequently asked questions about notifications

Why did a user receive a notification for a record they do not own?

A common cause is a recipient rule that includes a group, a watch list or a related record’s owner. Trace the rule that matched, then check the user’s group membership on the day the message fired, because membership changes are often the trigger.

Can a notification be sent to customers as well as internal staff?

Yes, but keep customer-facing and internal text separate. Build a separate template for each audience, and check that fields holding internal notes cannot reach the customer template through a variable.

Why do some messages arrive late?

Delivery can queue behind the mail system, and the platform’s own processing can add delay under load. Check the platform’s email logs before assuming the rule is at fault, because a rule that fired on time with a slow mail relay looks identical to a rule that never fired.

Who should approve a new notification?

The owner of the process it serves. The platform team can confirm that a rule fires correctly, but judging whether the message is needed and who should receive it is the process owner’s call.

Next step

If staff have started ignoring platform email, clean up the notification set before adding any new channel.

Related guides: ServiceNow Communication Preferences: Govern the Right Channel.