What Is ServiceNow Notifications and Email Handling? A Plain-Language Guide

ServiceNow notifications are platform messages that tell users when a record changes, such as an incident being assigned or a change being approved. A notification rule matches an event, queues the message, and a background job sends it by email, text or in-app alert. Users can act from the email, which updates the record, and choose their preferred channel.

What Notifications Do

ServiceNow keeps users informed through notifications: when an incident is assigned to you, you get an email. When a change you requested is approved, you get a notification. When a service request you submitted is fulfilled, you get an update. Without notifications, users would have to log into ServiceNow constantly to check status—a poor experience and unsustainable for large user populations.

Notifications and email handling are platform features of ServiceNow rather than a separate module: they deliver these messages by email, by text message to a registered device, and as alerts inside the application.

How Notifications Work

A trigger fires: an incident is assigned, a change is approved, a service request status changes. An event is recorded (for example, the record “incident 12345” was updated with assignment). The notification system checks: are there any notification rules that match this event (a rule might say: when an incident is assigned, send email to the assignee). If yes, a notification is generated and queued for delivery. A background job processes the queue and sends the notification via email, SMS, or posts it in-app.

The user receives the notification and can act on it: click a link in the email to view the incident, or click “respond” to add a comment. Actions triggered from the email update the record in ServiceNow.

Who Uses Notifications

Notifications serve multiple audiences. End users (customers requesting services) want to be notified when their request is being worked on and when it is complete. Agents (IT support staff) want to be notified immediately when an incident is assigned to them so they can start investigation without waiting to log in. Managers want escalation notifications when critical incidents are escalating or SLAs are at risk.

Some users prefer email notifications, others prefer SMS (texts), others want alerts in-app only (no external notifications). Notifications should be configurable so users get information in their preferred channel.

How Notifications Relate to Other Modules

Notifications depend on email configuration (a hosted instance sends mail through ServiceNow’s own mail service by default, and can instead be configured to send through your own mail server). They interact with workflows (a workflow can trigger a notification as part of process automation). They connect to user preferences (each user can configure which notifications they want to receive and in what channel).

Notifications also integrate with communication platforms: you can configure ServiceNow to send Teams messages or Slack notifications instead of (or in addition to) email. This is useful for teams that live in those platforms.

When to Implement Notifications

Notifications are so fundamental that they should be implemented early, not as an afterthought. When you set up an incident management workflow, configure who gets notified when incidents are assigned, escalated, or resolved. When you set up a service request process, configure notifications for status changes and approvals.

A common mistake: implementing a workflow but forgetting to configure notifications. Users don’t know their work is ready, requests sit in queues without anyone knowing, and users log in sporadically to check status. This creates a poor experience and reduces productivity.

Notification Design Best Practices

Notifications should be targeted (the person getting notified is actually responsible for an action) and timely (sent immediately or within minutes, not hours). A notification that arrives long after an incident is assigned is too late.

Notification overload is a risk. If users receive too many notifications in a day, they stop reading them and miss the important ones. Limit notifications to actions that require someone’s attention. Status updates that are purely informational (a change progressing through approval stages) might only notify the final approver, not everyone involved.

Notification content should be clear and actionable. An email should say what happened (incident assigned) and what action is expected (investigate and resolve). Include a link to the record so the user can open it with one click, not multiple clicks through menus.

Common Notification Problems

Notifications not being delivered (email goes to spam folder, SMS quota is exceeded, email provider is throttling). Troubleshooting requires checking: is email configuration correct (are credentials working), are notification rules firing (enable debug logging to verify), is the notification in the queue (check the notification log table), and did delivery fail (check email provider logs).

Notifications going to the wrong person (you get notifications meant for your colleague because a notification rule has the wrong assignment group). Fix this by reviewing and testing notification rules against test data.

Notification spam (users get too many notifications and stop reading them). Tune notification rules: increase thresholds (only notify for high-priority incidents, not low-priority), add filters (only notify if SLA is at risk), or make notifications conditional (notify only if the record has been waiting for approval for longer than a period you set).

Notification Channels and User Preferences

Configure multiple notification channels: email (default), SMS (for urgent notifications), and in-app (for low-urgency, informational updates). Let users choose which notifications go to which channel. A user might say: send me email for incidents assigned to me, but SMS only if the incident is critical and has been open for a while.

Respect user notification preferences. If a user has disabled notifications for a certain type of event, honor that; don’t override it with a “everyone must get notified” rule.

Be aware of time zones. A notification sent at midnight in one time zone might arrive at a reasonable hour in another. When scheduling digest notifications (a summary of all incidents resolved today), consider time zones and send during business hours in the user’s local time if possible.

Deciding which events deserve an email at all

Many notification problems start with a rule that was added because someone asked for “updates” and nobody asked which update, for whom, and what they were expected to do with it. Before you create or change a notification, decide whether the event needs a message at all. A message is only worth sending when a named person can act on it within a reasonable time, or when waiting would cause a visible problem. Everything else belongs on the record, where people see it when they look.

Treat the table as a draft for the discussion with your service owner rather than a settled policy. The notification governance article covers how that conversation can be structured. The useful question is which row each of your current notifications falls into. If you cannot place a notification in one of these rows, it probably should not exist.

Following one notification from the event to the inbox

When you troubleshoot, it helps to think of a notification as a chain of four separate steps. Each step can fail without any error appearing on screen. The platform records an event when a field changes. It then checks whether any notification rule applies to that event, including the rule’s conditions and whether the event happened on the right table. For each rule that matches, it resolves the recipients. Recipients can come from a field on the record, from a group, from the watch list, or from a value passed in the event. Finally, it creates an outbound email record and hands it to the mail server. A missing message can mean the rule never matched, the recipient resolved to nobody, the email was created but never sent, or it was sent and then filtered by the recipient’s mail system.

That last point matters for expectations. A correct setup can still look broken to the person who expected the message, because their mail filter, their mailbox rules, or the sender address may be the cause. Check the platform side first, because it is the part you control.

A checklist for a notification that did not arrive

Work through these steps in order. Stop at the first step that explains the gap. If the steps below do not settle it, the longer troubleshooting guide for this module walks through further checks.

1. Confirm the event happened. Find the record and the field change in its history, and note the exact time.
2. Confirm the rule’s conditions match that change, including the table and any filter on priority or group.
3. Confirm the recipient resolves to a real user with a valid email address, and that the user is active.
4. Find the outbound email record for that recipient and check its status. A record that was created but not sent points to mail configuration, not to the rule.
5. Check whether the recipient’s own user preferences or mail filters are the cause, using a test address you control.

What a healthy setup looks like next to a failing one

A healthy notification setup shows a short, stable gap between the event and the sent message, and recipients who reply with the work done rather than asking whether they missed something. The warning signs are different: the same person receives several copies of one event, recipients ask colleagues to forward messages, or the sent volume climbs after a rule change without any matching rise in actual work. Any of these is a reason to review rule scope before adding more rules. The common mistakes with notifications and email handling page lists patterns that can produce these symptoms.

When not to add a notification

Do not add an email to compensate for a process that is unclear. If nobody knows who should pick up a task, a notification to a group mailbox will only spread the uncertainty. Fix ownership first, then notify the owner. The roles and RACI guide for notifications is the place to settle who owns each message type. The same applies to digest-style summaries, which often hide a missing assignment rule rather than solve it. Whether a rule change needs review before it goes live is a governance question, and the governance model sets that out.

Why did one person receive two copies of the same notification?

Duplicates often come from two rules that match the same event, or from a recipient who is included both as the assignee and through a group or watch list. Compare the matching rules for that event and remove the overlap rather than suppressing mail at the mailbox.

Can an approver be notified without being the person who must act?

Yes, but it should be a deliberate choice. A copy to an observer is useful for audit or oversight. A copy that asks for action should go only to the person who can act, otherwise approvals stall while each recipient assumes another person has handled it.

Should replies to notification emails update the record?

Only if your team has agreed what a reply means. Inbound email handling can add work notes or change state, and a casual reply can then change a record that a manager is tracking. Decide the allowed actions and test them with a sample record before you switch them on.

What is the first thing to check when messages are delayed?

Look at whether the delay sits before or after the outbound email record is created. A delay before creation points to the rule or the event queue. A delay after creation points to the mail server or to a sending limit.

Notification complaints often trace back to a handful of rules.

ServiceNow notification tables, fields and values to check

A ServiceNow notification is a record in the sysevent_email_action table, built from three main tabs: when it sends, who receives it, and what the message says. Many delivery problems trace to one of those tabs.

The names below are common out-of-the-box values. Check each one on your own instance and release, because labels, defaults and menu paths can change between releases.

On the When to send tab, a rule typically runs when a record is inserted or updated, or when a named event is fired. The rule’s condition works like an encoded query filter on the record.

Example (hypothetical): an approver says no email arrived. Start in the event log and find the event for the record. If it is there, open the sys_email table and look for a row addressed to the approver. A row with a send-ignored or send-failed type tells you the platform did not hand the message off, so read that row for the cause. No row at all points back at the rule’s conditions, its recipients, or whether the event was processed. The common notification mistakes guide lists the patterns behind these symptoms.

Where do you find notification rules in ServiceNow?

Open the Notifications module, typically under System Notification and then Email, or list the sysevent_email_action table directly. Each rule has tabs for when it sends, who receives it and what it contains. Menu labels can differ by release, so confirm the path on your instance.

How do you check whether ServiceNow actually sent an email?

Look in the sys_email table for a row addressed to the person, then read its Type. A sent value means the platform passed the message to the outbound mail setup. A send-failed or send-ignored value means it was not handed off, so read the row for the cause before blaming the recipient’s mailbox.

Can a user turn off a notification in ServiceNow?

Often yes. Each user manages their own delivery preferences, and a rule may be set up to ignore them, depending on the release and configuration. Check both the rule and the user’s preferences. The notifications and email handling hub collects the related guides.

Sending ServiceNow notifications by SMS: what has to be true before a text arrives

A ServiceNow SMS notification reaches a user only when three conditions hold at the same time: the user’s profile holds a mobile number that the platform can use, the user’s notification preferences allow text for that kind of event, and the instance has a working text delivery path. If any one of the three is missing, the rule can match and the record can update with no text arriving, and nothing on screen tells the sender. Check the three in that order before you touch the rule itself.

The number is usually the first gap. Numbers typed with spaces, brackets or a missing country code often fail, and so does a number stored on a different field from the one your rule uses for its recipient. Standardize the format on the user record first, and test with your own phone before rolling out to a group.

Preferences come next. A user who turned off text for assignment events will not receive them, even when the rule is correct. This is the right behaviour, so do not override it with a second rule. Instead, decide which events justify a text at all. In most teams that is a small set: a critical incident being assigned, or an approval that is about to breach its deadline. Everything else stays in email or in the app.

Keep a short test list: one user with a correct number and text on, one with text off, and one with a malformed number. The results show which check is failing, so you do not have to guess. Remove test users with real phone numbers afterwards, because those phones will keep receiving messages.

Text messages usually carry a per-message cost, so a rule that texts a group on every update will spend budget. Limit SMS to the single event that justifies the interruption. Before you add a text rule, check the common notification mistakes that send messages to the wrong people, and the incident management guide for the events worth texting.