ServiceNow Certification Mock Exams
Click To View Now
Email notifications are a feature in ServiceNow that are frequently used across the platform. An email notification is a way to notify a ServiceNow user via email that something has happened that requires their awareness or action. As a developer, you will likely be asked to configure email notifications for many different scenarios. You could send a notification when a task is assigned, when an approval is required, or when a comment is made on a ticket. Typically, the goal when configuring email notifications is to have enough notifications to keep the user informed but not too many where users are overwhelmed to the point where they create a rule that sends them all to the trash. It is also a good idea to keep the format of email notifications consistent across the organization. This article will explain the basics of how to create and configure email notifications in ServiceNow.
To view all email notifications, navigate to System Notification -> Email -> Notifications. This list shows all the current notifications configured on the instance. To create a new email notification, click the “New button” at the top right. You will be redirected to the following form.
This form is where the configuration for an email notification is done in ServiceNow. The notification form has a top section along with three tabs: When to send, Who will receive, and What it will contain. There are a ton of fields available on the notification form.
We will be highlighting the ones we feel are most important to get you started with creating your own notifications. Let’s dive into each of these sections and discuss the various configuration options and what they are used for.
The top section of the notification form contains the basic fields that should be configured for a notification and will be visible no matter which tab is selected. Here is a closer look at this section.
For the Name field, give the notification a meaningful name that will indicate what the purpose of the notification is. In this case, the name tells us that the notification is sent when an incident is resolved.
The Table field specifies which table this notification will trigger on. You can create notifications for pretty much any table in ServiceNow.
Category is related to a user’s notification preferences. In ServiceNow, each user has the option in their profile to select which types of notifications they want to receive. The category will define which section in the user’s notification preferences this particular notification will fall under.
Description is a free text field to provide more information about the notification.
The following is a screenshot of the When to send tab. It is important to note that moving forward we will be using the Advanced view of the notification form, as it provides several additional fields for configuration. If you are not seeing the same options, click on the hamburger menu at the top left of the screen and change the view to “Advanced”.
The When to send tab contains the fields that determine when the notification will be sent.
The Send when field has three options to choose from: Record inserted or updated, Event is fired, and Triggered.
Record inserted or updated is used in the example above. If this option is chosen, you will then be able to select the Inserted and/or Updated checkboxes to define what database actions trigger the notification. In our example, this notification will be sent when a record is updated on the incident table.
Event is fired allows you to use events in ServiceNow to define when a notification is sent. If this option is chosen, a new field Event name becomes visible which allows you to select an event from the registry to fire the notification. This approach could be used to send a notification from a business rule. The process to accomplish this is to create a new event in the event registry, use the eventQueue() method in the business rule script to insert an event into the queue, and configure your notification to be sent when that event is fired.
Triggered should be selected if you wish to use this notification in Flow Designer. Once the notification is configured with this option, it will be available for use in a notification action step in Flow Designer. If this option is chosen, all other fields on When to send will be hidden as they are no longer relevant.
The Weight field is used to define a notification’s priority when several notifications for the same table and recipients are triggered simultaneously. Say you are getting complaints from end users that they are receiving back-to-back emails when their incident is assigned and then resolved. Weight could be used to reduce the number of emails the user receives. Since the highest weight that is not zero gets priority, the “resolved” email could be given a higher weight than the “assigned” email, and the user will only receive the “resolved” if they are triggered around the same time. The default value for Weight is zero which means that the notification will always be sent.
Condition and Advanced condition provide developers with a way to add more granular filters to determine when the notification will be sent. Condition allows for a simple way to add multiple filter conditions and Advanced condition can be used to add more complex conditions using JavaScript. If using Advanced condition, the script must return “answer = true” in order to fire. The above example notification has a Condition to trigger when an incident is resolved.
Next let’s look at the Who will receive tab and the various fields available for configuration. The following is a screenshot of the tab.
As the name implies, the Who will receive tab determines the recipients for the notification.
Both the Users and Groups fields allow you to define specific people or user groups who will receive the notification. In the User field you can even add email addresses that are not assigned to users within ServiceNow. This is convenient if you want to add an external email address to a specific notification for visibility.
Users/Groups in fields provides a way to add users or groups to notifications dynamically. This is extremely useful in that you are able to select from any fields that exist on the record that triggered the notification such as Opened by or Assigned to. In our example, the notification will be sent to the Caller for the specific incident that triggers the notification.
The Send to event creator field will define if the notification is sent to the person who performed the action that caused the notification to be sent. In some cases, it may not be necessary to send a notification to a user about something which they did themselves. For example, if a user adds a comment, they probably don’t need to be notified about it also. You could then uncheck the Send to event creator box so that users are not receiving unnecessary notifications.
Two fields not shown in the above screenshot that are important to discuss are Event parm 1 contains recipient and Event parm 2 contains recipient. These only become visible when configuring an Event is fired notification. For the earlier example of triggering a notification from a business rule, a user or group’s sys_id could be passed as a parameter for the eventQueue() method and used that to define who the notification is sent to. You would just have to add that parameter into the business rule code and check the appropriate field (Event parm 1 or 2) on the notification. This is another way to dynamically define the recipients, although it would be done in code that lives somewhere else.
Next let’s discuss the What it will contain tab. The below screenshot shows the fields available for configuration using the Advanced view.
This tab defines the content of an email notification. Content Type contains three options: HTML and plain text, HTML only, and Plain text only.
HTML only is the default and typically the most common as it provides more freedom to customize the look and feel of the notification. The Omit Watermark field can be used to remove watermarks from specific emails. A watermark is a random string added to each ServiceNow email by default which is used as a unique identifier. When an email is sent from ServiceNow and a user replies, the watermark is used to match a record and usually take some sort of action, such as approve a request or update and incident. The From and Reply to fields allow you to change the email address used for a specific notification. These are useful if you have a situation where you don’t want the email to look like it’s coming from “InstanceName@service-now.com”, which is usually your default email address for ServiceNow.
The Email template provides a way to apply a template to the notification. This can be helpful if you would like to reuse the same content in many different notifications. Templates also keep your notifications consistent. Email templates are configured elsewhere and are associated to a notification via the Email template reference field. The OOTB Unsubscribe and Preferences template used in our example will add some useful links to the footer of the notification.
The next few fields are really the core of what defines the notification content. The Subject field determines the subject of the email. It’s a good idea to keep these short, as most of the information should be contained in the email body. Notification variables can also be used in the Subject, which we will elaborate on in a moment. In the example we’ve been discussing the Content type is HTML Only, so what appears in the body of this notification will be defined by the Message HTML field. Here is a closer look at that field.
This is where all the configuration for the body of the email takes place. There are many different configuration options available, such as formatting the email, adding images, even viewing and editing the source code if you’re fluent in HTML. Notification variables were mentioned earlier and are an extremely useful tool for notifications. In the “Select variables” section on the right, the “Fields” folder can be expanded showing all available fields from the record that can be added to the email.
By simply clicking on the desired field, the appropriate code will be automatically added to the Message HTML allowing you to have dynamic values in the email body or subject. Notification variables are identified by their format of ${field_name} and can also be coded manually. You can see a few examples in the following full screen view of the Message HMTL.
This example has several field notification variables which will dynamically change based on the record that triggered the notification. This means that every time an incident is resolved, and this email is sent, it will have the appropriate caller name, number, short description, and assignment group. We also added another notification variable ${URI_REF}. This adds a link to provide users with an easy way to jump right to the record that the notification relates to. It is good practice to add a link so the user can see more information about the record they are being notified about.
While working on the notification form, there is a button at the top right labeled “Preview Notification”. This button allows you to see what your notification will look like without having to replicate the conditions to trigger it. This is a convenient way to test your notification while developing. This is the preview for our example notification.
In this pop-up window, you can select a user for the event creator and record to use for the preview. It then lists the users who will receive the notification, the subject, and the body. Any links are clickable in the preview, so you are able to make sure they are working as expected. Previewing a notification is a tool that every developer should take advantage of.
Knowing how to create and configure email notifications is an important part of providing users with a positive experience in ServiceNow. This is a skill every developer should possess. It may seem that we have discussed a lot of information in this article, but there are many additional topics not discussed here that relate to email notifications in ServiceNow. Some additional topics not covered here are writing mail scripts, creating email templates, and email digests. As always, we encourage you to continue learning and expand your knowledge. Happy coding!
