Understanding System Notifications & Email Configuration

Chapter Topics

ServiceNow instances are known to hold multiple activities requiring proper updates from time to time. Notifications are used to bridge this gap between users and automated workflows in ServiceNow.

Notifications are messages that users receive in different formats, including SMS, push notifications for Applications, and Alerts. In this topic, we will be covering the core notification platform, ie, emails in ServiceNow.

What are System Notifications?

System Notifications are automated messages sent by the ServiceNow platform to users or external systems. The notifications are processed asynchronously by the Notification Engine, and email records are first created in sys_email before being sent.

Emails tend to remain the primary standard for communication within the enterprise. The notifications help reduce the time taken for an action on a record. It pushes data to the user, eliminating the need for users to check records concurrently.

Purpose of Email Notifications

Email notifications can be used anywhere in the enterprise, from Password Reset links to Change Management approval chains. Such email notifications help improve the overall ITIL lifecycle in ServiceNow.

They help increase accountability among employees and offer transparency to the end user regarding their updates. Overall, email notifications make your approval process faster by keeping the admins updated regarding the system health.

Real World Example:

Incident Assigned
Change Approval
Password Reset
HR Welcome Email
Knowledge Article Published.

How to create an email notification in servicenow?

A notification record is the logic engine. It defines the Who, When, and What, and monitors the database or the event queue. Eventually, to generate a record in the sys_email table when the criteria are met.

Backend Table Name: sysevent_email_action
Navigation Path: System Notification → Email → Notifications

The steps in creating an email notification start by defining the basic information, such as:

Field Name	Type	Explanation	Backend Field
1. Name	String	A descriptive name for the notification (e.g., “Incident Assigned to my Group”).	name
2. Table	Table Name	The specific table this notification applies to (e.g., Incident [incident]).	collection
3. Category	Reference	Groups notifications for user subscription settings (e.g., IT Service Management).	category
4. Active	Boolean	Turn the notification on or off.,	active
5. Application	Reference to sys_scope ( Read Only )	Points to your current application ( Global or your scoped application )	sys_scope
6. Mandatory	Boolean	Prevent users from unsubscribing/filtering out this notification	mandatory
7. Allow digest	Boolean	Enable this notification to be in a digest by user	digestable

Email Notification Tabs

Creating an email notification does not end with the above-defined basic information. Every email has 3 core tabs to be filled in to answer the When, Who, and What for an email.

Tab 1: When to send

when to send email notification in servicenow

Field Name	Type	Explanation	Backend Field
1. Send when	Choice	Record inserted or updated: Triggered by database changes. Event is fired: Triggered by gs.eventQueue() in scripts.	event_parm_1 (logic)
2. Inserted	Checkbox	Fires when a new record is created.	action_insert
3. Updated	Checkbox	Fires when an existing record is modified.	action_update
4. Conditions	Condition Builder	Logic gate. E.g., Priority IS 1 – Critical.	condition

Best Practice: Use Event is Fired for production implementations because it decouples business logic from notification logic.

Tab 2: Who will receive

who will receive email notification in ServiceNow

Field Name	Type	Explanation	Backend Field
1. Users	List	Hardcoded specific users (e.g., “System Admin”). Avoid using this.	recipient_users
2. Groups	List	Hardcoded groups (e.g., “Helpdesk”).	recipient_groups
3. Users/Groups in fields	List (Dynamic)	Best Practice. Sends to the person referenced in the record. E.g., Select Assigned_to to email the technician working on the ticket.	recipient_fields
4. Subscribable	True/False	Allow the user to choose this notification when subscribing to their messages	subscribable

Avoid hardcoded Users and Groups, and prefer dynamic fields like:

Assigned To
Opened By
Requested For
Watch List

These dynamic fields make notifications reusable.

Tab 3 – What it will contain

Field Name	Type	Explanation	Backend Field
1. Subject	String	The email subject line. Supports variables (e.g., Incident ${number} has been opened).	subject
2. Message HTML	HTML Script	The body. Supports HTML, CSS, and Mail Scripts ().	message_html
3. Email Template	Reference	Apply a wrapper (Header/Footer) to this email.	template

Some commonly used notification variables that are used in projects are:

${number}
${short_description}
${URI}
${URI_REF}
${mail_script:script_name}

Preview Notification

Before any email is deployed, the platform allows an on-screen preview using the Preview Notification button on the Notification form. The preview option renders the email; it does not send an actual email.

It allows you to select a real record (e.g., INC001002). It then renders the email exactly as it would look for that specific record, resolving variables like assigned_to to “Fred Luddy”.

Email Templates

Email Templates are reusable wrappers or formats provided in the ServiceNow instance. Instead of adding the company logo and legal footer to all 500 notifications, you create one Template and apply it.

The templates enhance efficiency and make your emails consistent for every end user.

Backend Table Name: sysevent_email_template

To create a template, there are new fields to be added:

Field Name	Type	Explanation	Backend Field
1. Name	String	Name of the template (e.g., “Standard IT Footer”).	name
2. Subject	String	(Optional) Can override the notification subject.	subject
3. Message HTML	HTML	The layout. Must include ${notification:body}—this is the placeholder where the specific notification’s text will be inserted.	message_html
4. Table	Reference	A table for which you are making a template by using its fields between the content.	collection

Real-World Admin Tip:

Use templates for “Branding.” Create a template named Unbranded for internal system alerts and Corporate External for customer-facing emails.

Template Inheritance

Template inheritance is a flow of templates to the notification body and finally to the rendered email.

The Base Template: It is a reusable layout for the notifications. It acts as a parent structure with standard content that act as Master template for your emails.
Notification Body: It is the specified content or the laert that you want to send. Here, you need to specify what templates to use for message specific text.
Rendered Email: It is the finalized email that user receive. The inheritance process adds the notification body content in the template and creates a clean HTML file to be sent out.

Send Email Notification to CC

Users and emp0loyees target in the Who will receive tab automatically get added to the TO line of the message. Using Subscribable options or scripting, users can be added to the CC line.

The CC or carbon copy option lets you keep people in the loop without addressing them directly. APart form that, the other components in an Email includes:

BCC
Email Scripts
Recipient Scripts

Omit Watermarks in Email Notifications

A watermark is the code at the bottom of an email (Ref:MSG00001) that allows the system to identify the record when a user replies. It is mainly used in the Notification form. You can update the Omit Watermark option in the What it will contain tab.

These are used for Survey or announcement emails where users’ replies are not needed to update a ticket.

Without a watermark, a reply cannot update the record automatically.

What’s Next?

Apart from the Email notifications, ServiceNow Events is an integral part for sending notifications. In the next topic, we will focus on how notifications are triggered for any event and the process for email subscription.

Next Topic