Email notifications replace manual updates and status emails by automatically sending messages when records change or meet specific conditions. You'll build one that knows who to notify, when to fire, and what to say.
What email notifications replace
Before notifications, someone on your team was manually emailing status updates — "your incident is assigned," "approval needed," "request fulfilled." That person had to remember to send them, users never knew what was happening with their requests, and stakeholders stayed out of the loop unless they logged into ServiceNow. The people who benefit are end users (who get proactive updates), fulfillment teams (who don't field "what's the status" calls), and admins (who automate away a repetitive task that always got forgotten during busy periods).
Building your first notification
A notification has three parts: Who (recipients), When (conditions that trigger it), and What (subject and message content). The When is critical — event-based notifications fire when specific events happen (like 'incident.inserted'), while condition-based notifications evaluate field values and can fire on insert, update, or both. Most people start with a simple "notify the assigned user when priority changes" and then layer on dynamic recipient lists, rich HTML formatting, and complex conditional logic as requirements grow.
Taking notifications further
A basic notification works, but production-quality ones handle edge cases: they check that email addresses exist before sending, use notification preferences to respect user communication settings, and include unsubscribe links for non-critical updates. You'll also want to group related notifications to avoid email flooding, use email templates for consistent branding, and set up notification digests for high-volume scenarios where individual emails would overwhelm recipients.
Before you start
- •notifications_admin or admin role
- •Email properties configured in System Properties > Email
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Email Notifications
Go to System Notification > Email > Notifications. Click New to create a notification record. The table field auto-populates — change it to the table you want to monitor (like Incident or Change Request). This determines what record data you can reference in conditions and email content.
Set the trigger method
Choose between Event based or Condition based in the Type field. Event based fires when specific database events occur (insert, update, delete). Condition based evaluates field values and gives you more control over exactly when it fires. For your first notification, use Condition based — it's more predictable.
Configure when it fires
Set Send when to control the database operation that triggers evaluation — Insert, Update, or Insert and Update. Then build your condition using the condition builder. Start simple: "Priority is 1 - Critical" or "State changes to Resolved". The condition must be true for the notification to send.
Use "changes to" operators instead of "is" when you only want to notify on status transitions, not every update while in that state.
Define who receives it
In the Who will receive tab, add recipients. Use Event parm 1 for simple field references like "${assigned_to}" to notify the assigned user. For multiple recipients, add rows and reference different fields or groups. You can mix individual users, groups, and dynamic field references in the same notification.
Write the email content
In the What will it contain tab, set the Subject and Message fields. Reference record fields using ${field_name} syntax like "Your incident ${number} has been updated". The message can be plain text or HTML. Test your field references carefully — invalid field names show as empty strings in emails.
Use ${URI_REF} to include a clickable link back to the record in ServiceNow.
Test the notification
Check the Active checkbox and save the record. Create or update a record that matches your conditions to trigger a test email. Check the Email Logs (System Logs > Email > Sent) to verify it fired and debug any issues. Look for "Notification not sent" entries if emails aren't going out.
Refine the conditions
After testing, tighten your conditions to prevent notification spam. Add field change detection ("Priority changes") instead of broad conditions ("Priority is Critical"). Review the notification after a week of live usage to catch edge cases where it fires more often than intended.
Best practices
Always use "changes to" conditions instead of "is" conditions when you only want to notify on transitions — "State changes to Resolved" not "State is Resolved".
Reference the ${URI_REF} field in every notification message so recipients can click directly back to the record.
Check notification logs regularly after deployment — notifications that fail silently are worse than no notifications.
Set up a test user account with a different email domain to catch notifications that work internally but fail for external recipients.
Use groups instead of individual users in recipient lists whenever possible — it's easier to maintain group membership than notification records.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue