In this article by Martin Wood, the author of the book, Mastering ServiceNow, has discussed about communication which is a key part of any business application. Not only does the boss need to have an updated report by Monday, but your customers and users also want to be kept informed.

ServiceNow helps users who want to know what’s going on. In this article, we’ll explore the functionality available. The platform can notify and provide information to people in a variety of ways:

• Registering events and creating Scheduled Jobs to automate functionality
• Sending out informational e-mails when something happens
• Live dashboards and homepages showing the latest reports and statistics
• Scheduled reports that help with handover between shifts
• Capturing information with metrics
• Presenting a single set of consolidated data with database views

(For more resources related to this topic, see here.)

Dealing with events

Firing an event is a way to tell the platform that something happened. Since ServiceNow is a data-driven system, in many cases, this means that a record has been updated in some way. For instance, maybe a guest has been made a VIP, or has stayed for 20 nights. Several parts of the system may be listening for an event to happen. When it does, they perform an action. One of these actions may be sending an e-mail to thank our guest for their continued business.

These days, e-mail notifications don’t need to be triggered by events. However, it is an excellent example.

When you fire an event, you pass through a GlideRecord object and up to two string parameters. The item receiving this data can then use it as necessary, so if we wanted to send an e-mail confirming a hotel booking, we have those details to hand during processing.

Registering events

Before an event can be fired, it must be known to the system. We do this by adding it to Event Registry [sysevent_register], which can be accessed by navigating to System Policy > Events > Registry. It’s a good idea to check whether there isn’t one you can use before you add a new one.

An event registration record consists of several fields, but most importantly a string name. An event can be called anything, but by convention it is in a dotted namespace style format. Often, it is prefixed by the application or table name and then by the activity that occurred.

Since a GlideRecord object accompanies an event, the table that the record will come from should also be selected. It is also a good idea to describe your event and what will cause it in the Description and Fired by fields.

Finally, there is a field that is often left empty, called Queue. This gives us the functionality to categorize events and process them in a specific order or frequency.

Firing an event

Most often, a script in a Business Rule will notice that something happens and will add an event to the Event [sysevent] queue. This table stores all of the events that have been fired, if it has been processed, and what page the user was on when it happened.

As the events come in, the platform deals with them in a first in, first out order by default. It finds everything that is listening for this specific event and executes them. That may be an e-mail notification or a script. By navigating to System Policy > Events > Event Log, you can view the state of an event, when it was added to the queue, and when it was processed.

To add an event to the queue, use the eventQueue function of GlideSystem. It accepts four parameters: the name of the event, a GlideRecord object, and two run time parameters. These can be any text strings, but most often are related to the user that caused the event.

Sending an e-mail for new reservations

Let’s create an event that will fire when a Maintenance task has been assigned to one of our teams.

1. Navigate to System Policy > Events > Registry. Click on New and set the following fields:
   •     Event name: maintenance.assigned
   •     Table: Maintenance [u_maintenance]
2. Next, we need to add the event to the Event Queue. This is easily done with a simple Business Rule:
   •     Name: Maintenance assignment events
   •     Table: Maintenance [u_maintenance]
   •     Advanced: <ticked>
   •     When: after

Make sure to always fire events after the record has been written to the database. This stops the possibility of firing an event even though another script has aborted the action.

• Insert: <ticked>
• Update: <ticked>
• Filter Conditions:
  • Assignment group – changes
  • Assignment group – is not empty
  • Assigned to – is empty

  This filter represents when a task is sent to a new group but someone hasn’t yet been identified to own the work.

• Script: gs.eventQueue(‘maintenance.assigned’, current, gs.getUserID(), gs.getUserName());

  This script follows the standard convention when firing events—passing the event name, current, which contains the GlideRecord object the Business Rule is working with, and some details about the user who is logged in.

We’ll pick this event up later and send an e-mail whenever it is fired.

There are several events, such as <table_name>.view, that are fired automatically. A very useful one is the login event. Take a look at the Event Log to see what is happening.

Scheduling jobs

You may be wondering how the platform processes the event queue. What picks them up? How often are they processed? In order to make things happen automatically, ServiceNow has a System Scheduler. Processing the event queue is one job that is done on a repeated basis.

ServiceNow can provide extra worker nodes that only process events. These shift the processing of things such as e-mails onto another system, enabling the other application nodes to better service user interactions.

To see what is going on, navigate to System Scheduler > Scheduled Jobs > Today’s Scheduled Jobs. This is a link to the Schedule Item [sys_trigger] table, a list of everything the system is doing in the background. You will see a job that collects database statistics, another that upgrades the instance (if appropriate), and others that send and receive e-mails or SMS messages. You should also spot one called events process, which deals with the event queue.

A Schedule Item has a Next action date and time field. This is when the platform will next run the job. Exactly what will happen is specified through the Job ID field. This is a reference to the Java class in the platform that will actually do the work. The majority of the time, this is RunScriptJob, which will execute some JavaScript code.

The Trigger type field specifies how often the job will repeat. Most jobs are run repetitively, with events process set to run every 30 seconds. Others run when the instance is started—perhaps to preload the cache.

Another job that is run on a periodic basis is SMTP Sender. Once an e-mail has been generated and placed in the sys_email table, the SMTP Sender job performs the same function as many desktop e-mail clients: it connects to an e-mail server and asks it to deliver the message. It runs every minute by default.

This schedule has a direct impact on how quickly our e-mail will be sent out. There may be a delay of up to 30 seconds in generating the e-mail from an event, and a further delay of up to a minute before the e-mail is actually sent.

Other jobs may process a particular event queue differently. Events placed into the metric queue will be worked with after 5 seconds.

Adding your own jobs

The sys_trigger table is a backend data store. It is possible to add your own jobs and edit what is already there, but I don’t recommend it. Instead, there is a more appropriate frontend: the Scheduled Job [sysauto] table.

The sysauto table is designed to be extended. There are many things that can be automated in ServiceNow, including data imports, sending reports, and creating records, and they each have a table extended from sysauto.

Once you create an entry in the sysauto table, the platform creates the appropriate record in the sys_trigger table. This is done through a call in the automation synchronizer Business Rule.

Each table extended from sysauto contains fields that are relevant to its automation. For example, a Scheduled Email of Report [sysauto_report] requires e-mail addresses and reports to be specified.

Creating events every day

Navigate to System Definition > Scheduled Jobs.

Unfortunately, the sys_trigger and sysauto tables have very similar module names. Be sure to pick the right one.

When you click on New, an interceptor will fire, asking you to choose what you want to automate. Let’s write a simple script that will create a maintenance task at the end of a hotel stay, so choose Automatically run a script of your choosing. Our aim is to fire an event for each room that needs cleaning. We’ll keep this for midday to give our guests plenty of time to check out. Set the following fields:

• Name: Clean on end of reservation
• Time: 12:00:00
• Run this script:

  var res = new GlideRecord('u_reservation');

  res.addQuery('u_departure', gs.now());

  res.addNotNullQuery('u_room');

  res.query();

  while (res.next()) {

  gs.eventQueue('room.reservation_end', res.u_room.getRefRecord());

  }

Remember to enclose scripts in a function if they could cause other scripts to run. Most often, this is when records are updated, but it is not the case here.

Our reliable friend, GlideRecord, is employed to get reservation records. The first filter ensures that only reservations that are ending today will be returned, while the second filter ignores reservations that don’t have a room.

Once the database has been queried, the records are looped round. For each one, the eventQueue function of GlideSystem is used to add in an event into the event queue. The record that is being passed into the event queue is actually the Room record. The getRefRecord function of GlideElement dot-walks through a reference field and returns a newly initialized GlideRecord object rather than more GlideElement objects.

Once the Scheduled Job has been saved, it’ll generate the events at midday. But for testing, there is a handy Execute Now UI action. Ensure there is test data that fits the code and click on the button. Navigate to System Policy > Events > Event Log to see the entries.

There is a Conditional checkbox with a separate Condition script field. However, I don’t often use this; instead, I provide any conditions inline in the script that I’m writing, just like we did here. For anything more than a few lines, a Script Include should be used for modularity and efficiency.

Running scripts on events

The ServiceNow platform has several items that listen for events. Email Notifications are one, which we’ll explore soon. Another is Script Actions.

Script Actions is server-side code that is associated with a table and runs against a record, just like a Business Rule. But instead of being triggered by a database action, a Script Action is started with an event.

There are many similarities between a Script Action and an asynchronous Business Rule. They both run server-side, asynchronous code. Unless there is a particular reason, stick to Business Rules for ease and familiarity.

Just like a Business Rule, the GlideRecord variable called current is available. This is the same record that was passed into the second parameter when gs.eventQueue was called.

Additionally, another GlideRecord variable called event is provided. It is initialized against the appropriate Event record on the sysevent table. This gives you access to the other parameters (event.param1 and event.param2) as well as who created the event, when, and more.

Creating tasks automatically

When creating a Script Action, the first step is to register or identify the event it will be associated with. Create another entry in Event Registry.

• Event name: room.reservation_end
• Table: Room [u_room]

In order to make the functionality more data driven, let’s create another template. Either navigate to System Definition > Templates or create a new Maintenance task and use the Save as Template option in the context menu.

Regardless, set the following fields:

• Name: End of reservation room cleaning
• Table: Maintenance [u_maintenance]
• Template:
  • Assignment group: Housekeeping
  • Short description: End of reservation room cleaning
  • Description: Please perform the standard cleaning for the room listed above.

To create the Script Action, go to System Policy > Events > Script Actions and use the following details:

• Name: Produce maintenance tasks
• Event name: room.reservation_end
• Active: <ticked>
• Script:

  var tsk = new GlideRecord('u_maintenance');

  tsk.newRecord();

  tsk.u_room = current.sys_id;

  tsk.applyTemplate('End of reservation room cleaning');

  tsk.insert();

This script is quite straightforward. It creates a new GlideRecord object that represents a record in the Maintenance table. The fields are initialized through newRecord, and the Room field is populated with the sys_id of current—which is the Room record that the event is associated with. The applyTemplate function is given the name of the template.

It would be better to use a property here instead of hardcoding a template name.

Now, the following items should occur every day:

1. At midday, a Scheduled Job looks for any reservations that are ending today
2. For each one, the room.reservation_end event is fired
3. A Script Action will be called, which creates a new Maintenance task
4. The Maintenance task is assigned, through a template, to the Housekeeping group.

   But how does Housekeeping know that this task has been created? Let’s send them an e-mail!

Sending e-mail notifications

E-mail is ubiquitous. It is often the primary form of communication in business, so it is important that ServiceNow has good support. It is easy to configure ServiceNow to send out communications to whoever needs to know.

There are a few general use cases for e-mail notifications:

• Action: Asking the receiver to do some work
• Informational: Giving the receiver an update or some data
• Approval: Asking for a decision

  While this is similar enough to an action e-mail, it is a common enough scenario to make it independent.

We’ll work through these scenarios in order to understand how ServiceNow can help.

There are obviously a lot more ways you can use e-mails. One of them is for a machine-to-machine integration, such as e-bonding. It is possible to do this in ServiceNow, but it is not the best solution.

Setting e-mail properties

A ServiceNow instance uses standard protocols to send and receive e-mail. E-mails are sent by connecting to an SMTP server with a username and password, just like Outlook or any other e-mail client.

When an instance is provisioned, it also gets an e-mail account. If your instance is available at instance.service-now.com through the Web, it has an e-mail address of [email protected].

This e-mail account is not unusual. It is accessible via POP to receive mail, and uses SMTP to send it. Indeed, any standard e-mail account can be used with an instance.

Navigate to System Properties > Email to investigate the settings. The properties are unusually laid out in two columns, for sending and receiving for the SMTP and POP connections. When you reach the page, the settings will be tested, so you can immediately see if the platform is capable of sending or receiving e-mails. Before you spend time configuring Email Notifications, make sure the basics work!

ServiceNow will only use one e-mail account to send out e-mails, and by default, will only check for new e-mails in one account too.

Tracking sent e-mails in the Activity Log

One important feature of Email Notifications is that they can show up in the Activity Log if configured. This means that all e-mails associated with a ticket are associated and kept together. This is useful when tracking correspondence with a Requester.

To configure the Activity Log, navigate to a Maintenance record. Right-click on the field and choose Personalize Activities. At the bottom of the Available list is Sent/Received Emails. Add it to the Selected list and click on Save.

Once an e-mail has been sent out, check back to the Activity Formatter to see the results.

Assigning work

Our Housekeeping team is equipped with the most modern technology. Not only are they users of ServiceNow, but they have mobile phones that will send and receive e-mails. They have better things to do than constantly refresh the web interface, so let’s ensure that ServiceNow will come to them.

One of the most common e-mail notifications is for ServiceNow to inform people when they have been assigned a task. It usually gives an overview and a link to view more details. This e-mail tells them that something needs to happen and that ServiceNow should be updated with the result.

Sending an e-mail notification on assignment

When our Maintenance tasks have the Assignment group field populated, we need the appropriate team members to be aware. We are going to achieve this by sending an e-mail to everyone in that group. At Gardiner Hotels, we empower our staff: they know that one member of the team should pick the task up and own it by setting the Assigned to field to themselves and then get it done.

Navigate to System Policy > Email > Notifications. You will see several examples that are useful to understand the basic configuration, but we’ll create our own. Click on New.

The Email Notifications form is split into three main sections: When to send, Who will receive, and What it will contain. Some options are hidden in a different view, so click on Advanced view to see them all. Start off by giving the basic details:

• Name: Group assignment
• Table: Maintenance [u_maintenance]

Now, let’s see each of the sections of Email Notifications form in detail, in the following sections.

When to send

This section gives you a choice of either using an event to determine which record should be worked with or for the e-mail notification system to monitor the table directly. Either way, Conditions and Advanced conditions lets you provide a filter or a script to ensure you only send e-mails at the right time. If you are using an event, the event must be fired and the condition fields satisfied for the e-mail to be sent.

The Weight field is often overlooked. A single event or record update may satisfy the condition of multiple Email Notifications. For example, a common scenario is to send an e-mail to the Assignment group when it is populated and to send an e-mail to the Assigned to person when that is populated. But what if they both happen at the same time? You probably don’t want the Assignment group being told to pick up a task if it has already been assigned. One way is to give the Assignment group e-mail a higher weight: if two e-mails are being generated, only the lower weight will be sent. The other will be marked as skipped.

Another way to achieve this scenario is through conditions. Only send the Assignment group e-mail if the Assigned to field is empty.

Since we’ve already created an event, let’s use it. And because of the careful use of conditions in the Business Rule, it only sends out the event in the appropriate circumstances. That means no condition is necessary in this Email Notification.

• Send when: Event is fired
• Event name: maintenance.assigned

Who will receive

Once we’ve determined when an e-mail should be sent, we need to know who it will go to. The majority of the time, it’ll be driven by data on the record. This scenario is exactly that: the people who will receive the e-mail are those in the Assignment group field on the Maintenance task. Of course, it is possible to hardcode recipients and the system can also deliver e-mails to Users and Groups that have been sent as a parameter when creating the event.

• Users/Groups in fields: Assignment group

You can also use scripts to specify the From, To, CC, and BCC of an e-mail. The wiki here contains more information:

http://wiki.servicenow.com/?title=Scripting_for_Email_Notifications

Send to event creator

When someone comes to me and says: “Martin, I’ve set up the e-mail notification, but it isn’t working. Do you know why?”, I like to put money on the reason. I very often win, and you can too. Just answer: “Ensure Send to event creator is ticked and try again”.

The Send to event creator field is only visible on the Advanced view, but is the cause of this problem. So tick Send to event creator. Make sure this field is ticked, at least for now. If you do not, when you test your e-mail notifications, you will not receive your e-mail. Why?

By default, the system will not send confirmation e-mails. If you were the person to update a record and it causes e-mails to be sent, and it turns out that you are one of the recipients, it’ll go to everyone other than you. The reasoning is straightforward: you carried out the action so why do you need to be informed that it happened? This cuts down on unnecessary e-mails and so is a good thing. But it confuses everyone who first comes across it.

If there is one tip I can give to you in this article, it is this – tick the Send to event creator field when testing e-mails. Better still, test realistically!

What it will contain

The last section is probably the simplest to understand, but the one that takes most time: deciding what to send.

The standard view contains just a few fields: a space to enter your message, a subject line, and an SMS alternate field that is used for text messages. Additionally, there is an Email template field that isn’t often used but is useful if you want to deliver the same content in multiple e-mail messages. View them by navigating to System Policy > Email > Templates.

These fields all support variable substitution. This is a special syntax that instructs the instance to insert data from the record that the e-mail is triggered for. This Maintenance e-mail can easily contain data from the Maintenance record.

This lets you create data-driven e-mails. I like to compare it to a mail-merge system; you have some fixed text, some placeholders, and some data, and the platform puts them all together to produce a personalized e-mail.

By default, the message will be delivered as HTML. This means you can make your messages look more styled by using image tags and font controls, among other options.

Using variable substitution

The format for substitution is ${variable}. All of the fields on the record are available as variables, so to include the Short description field in an e-mail, use ${short_description}. Additionally, you can dot-walk. So by having ${assigned_to.email} in the message, you insert the e-mail address of the user that the task is assigned to.

Populate the fields with the following information and save:

• Subject: Maintenance task assigned to your group
• Message HTML:

  Hello ${assignment_group}.

  Maintenance task ${number} has been assigned to your group, for room: ${u_room}.

  Description: ${description}

  Please assign to a team member here: ${URI}

  Thanks!

To make this easier, there is a Select variables section on the Message HTML and SMS alternate fields that will create the syntax in a single click. But don’t forget that variable substitution is available for the Subject field too.

In addition to adding the value of fields, variable substitution like the following ones also makes it easy to add HTML links.

• ${<reference field>.URI} will create an HTML link to the reference field, with the text LINK
• ${<reference field>.URI_REF} will create an HTML link, but with the display value of the record as the text
• Linking to CMS sites is possible through ${CMS_URI+<site>/<page>}

Running scripts in e-mail messages

If the variables aren’t giving you enough control, like everywhere else in ServiceNow, you can add a script. To do so, create a new entry in the Email Scripts [sys_script_email] table, which is available under System Policy > Email > Notification Email Scripts. Typical server-side capability is present, including the current GlideRecord variable. To output text, use the print function of the template object. For example:

template.print('Hello, world!');

Like a Script Include, the Name field is important. Call the script by placing ${mail_script:<name>} in the Message HTML field in the e-mail.

An object called email is also available. This gives much more control with the resulting e-mail, giving functions such as setImportance, addAddress, and setReplyTo.

This wiki has more details: http://wiki.servicenow.com/?title=Scripting_for_Email_Notifications.

Controlling the watermark

Every outbound mail contains a reference number embedded into the body of the message, in the format Ref:MSG0000100. This is very important for the inbound processing of e-mails, as discussed in a later section. Some options are available to hide or remove the watermark, but this may affect how the platform treats a reply.

Navigating to System Mailboxes > Administration > Watermarks shows a full list of every watermark and the associated record and e-mail.

Including attachments and other options

There are several other options to control how an e-mail is processed:

• Include Attachments: It will copy any attachments from the record into the e-mail. There is no selection available: it simply duplicates each one every time. You probably wouldn’t want this option ticked on many e-mails, since otherwise you will fill up the recipient’s inboxes quickly!
  

  The attach_links Email Script is a good alternative—it gives HTML links that will let an interested recipient download the file from the instance.

• Importance: This allows a Low or High priority flag to be set on an e-mail
• From and Reply-To fields: They’ll let you configure who the e-mail purports to be from, on a per–e-mail basis. It is important to realize that this is e-mail spoofing: while the e-mail protocols accept this, it is often used by spam to forge a false address.

Sending informational updates

Many people rely on e-mails to know what is going on. In addition to telling users when they need to do work, ServiceNow can keep everyone informed as to the current situation.

This often takes the form of one of these scenarios:

• Automatic e-mails, often based on a change of the State field
• Completely freeform text, with or without a template
• A combination of the preceding two: a textual update given by a person, but in a structured template

Sending a custom e-mail

Sometimes, you need to send an e-mail that doesn’t fit into a template. Perhaps you need to attach a file, copy in additional people, or want more control over formatting. In many cases, you would turn to the e-mail client on your desktop, such as Outlook or perhaps even Lotus Notes. But the big disadvantage is that the association between the e-mail and the record is lost. Of course, you could save the e-mail and upload it as an attachment, but that isn’t as good as it being part of the audit history.

ServiceNow comes with a basic e-mail client built in. In fact, it is just shortcutting the process. When you use the e-mail client, you are doing exactly the same as the Email Notifications engine would, by generating an entry in the sys_email table.

Enabling the e-mail client

The Email Client is accessed by a little icon in the form header of a record. In order to show it, a property must be set in the Dictionary Entry of the table. Navigate to System Definition > Dictionary and find the entry for the u_maintenance table that does not have an entry in the Column name field.

The value for the filter is Table – is – u_maintenance and Column name – is – empty.

Click on Advanced view. Ensure the Attributes field contains email_client.

Navigate to an existing Maintenance record, and next to the attachments icon is the envelope icon. Click on it to open the e-mail client window.

The Email Client is a simple window, and the fields should be obvious. Simply fill them out and click on Send to deliver the mail.

You may have noticed that some of the fields were prepopulated. You can control what each field initially contains by creating an Email Client Template. Navigate to System Policy > Email > Client Templates, click on New, and save a template for the appropriate table. You can use the variable substitution syntax to place the contents of fields in the e-mail. There is a Conditions field you can add to the form to have the right template used.

Quick Messages are a way to let the e-mail user populate Message Text, similar to a record template. Navigate to System Policy > Email > Quick Messages and define some text. These are then available in a dropdown selection field at the top of the e-mail client.

The e-mail client is often seized upon by customers who send a lot of e-mail. However, it is a simple solution and does not have a whole host of functionality that is often expected. I’ve found that this gap can be frustrating. For example, there isn’t an easy way to include attachments from the parent record.

Instead, often a more automated way to send custom text is useful.

Sending e-mails with Additional comments and Work notes

The journal fields on the task table are useful enough, allowing you to record results that are then displayed on the Activity log in a who, what, when fashion. But sending out the contents via e-mail makes them especially helpful. This lets you combine two actions in one: documenting information against the ticket and also giving an update to interested parties. The Task table has two fields that let you specify who those people are: the Watch list and the Work notes list.

An e-mail notification can then use this information in a structured manner to send out the work note. It can include the contents of the work notes as well as images, styled text, and background information.

Sending out Work notes

The Work notes field should already be on the Maintenance form. Use Form Design to include the Work notes list field too, placing it somewhere appropriate, such as underneath the Assignment group field.

Both the Watch list and the Work notes list are List fields (often referred to as Glide Lists). These are reference fields that contain more than one sys_id from the sys_user table. This makes it is easy to add a requester or fulfiller who is interested in updates to the ticket. What is special about List fields is that although they point towards the sys_user table and store sys_id references, they also store e-mail addresses in the same database field. The e-mail notification system knows all about this. It will run through the following logic:

• If it is a sys_id, the user record is looked up. The e-mail address in the user record is used.
• If it is an e-mail address, the user record is searched for. If one is found, any notification settings they have are respected.
  

  A user may turn off e-mails, for example, by setting the Notification field to Disabled in their user record.

• If a user record is not found, the e-mail is sent directly to the e-mail address.

Now create a new Email Notification and fill out the following fields:

• Name: Work notes update
• Table: Maintenance [u_maintenance]
• Inserted: <ticked>
• Updated: <ticked>
• Conditions: Work notes – changes
• Users/Groups in fields: Work notes list
• Subject: New work notes update on ${number}
• Send to event creator: <ticked>
• Message:

  ${number} - ${short_description} has a new work note added.

  ${work_notes}

This simple message would normally be expanded and made to fit into the corporate style guidelines—use appropriate colors and styles. By default, the last three entries in the Work notes field would be included. If this wasn’t appropriate, the global property could be updated or a mail script could use getJournalEntry(1) to grab the last one. Refer to this wiki article for more information: http://wiki.servicenow.com/?title=Using_Journal_Fields#Restrict_the_Number_of_Entries_Sent_in_a_Notification.

To test, add an e-mail address or a user into the Work notes list, enter something into the Work notes field, and save.

Don’t forget about Send to event creator! This is a typical example of how, normally, the person doing the action wouldn’t need to receive the e-mail update, since they were the one doing it. But set it so it’ll work with your own updates.

Approving via e-mail

Graphical Workflow generates records that someone will need to evaluate and make a decision on. Most often, approvers will want to receive an e-mail notification to alert them to the situation.

There are two approaches to sending out an e-mail when an approval is needed. An e-mail is associated with a particular record; and with approvals, there are two records to choose from:

• The Approval record, asking for your decision. The response will be processed by the Graphical Workflow. The system will send out one e-mail to each person that is requested to approve it.
• The Task record that generated the Approval request. The system will send out one e-mail in total.

Attaching notifications to the task is sometimes helpful, since it gives you access to all the fields on the record without dot-walking.

This section deals with how the Approval record itself uses e-mail notifications.

Using the Approval table

An e-mail that is sent out from the Approval table often contains the same elements:

• Some text describing what needs approving: perhaps the Short description or Priority. This is often achieved by dot-walking to the data through the Approval for reference field.
• A link to view the task that needs approval.
• A link to the approval record.
• Two mailto links that allow the user to approve or reject through e-mail.

This style is captured in the Email Template named change.itil.approve.role and is used in an Email Notification called Approval Request that is against the Approval [sys_approver] table.

The mailto links are generated through a special syntax: ${mailto:mailto.approval} and ${mailto:mailto.rejection}. These actually refer to Email Templates themselves (navigate to System Policy > Email > Templates and find the template called mailto.approval). Altogether, these generate HTML code in the e-mail message that looks something like this:

<a href="mailto:<instance>@service-now.com.com?subject=Re:MAI0001001 -
 approve&body=Ref:MSG0000001">Click here to approve MAI0001001</a>

Normally, this URL would be encoded, but I’ve removed the characters for clarity.

When this link is clicked on in the receiver’s e-mail client, it creates a new e-mail message addressed to the instance, with Re:MAI0001001 – approve in the subject line and Ref:MSG0000001 in the body. If this e-mail was sent, the instance would process it and approve the approval record. A later section, on processing inbound e-mails, shows in detail how this happens.

Testing the default approval e-mail

In the baseline system, there is an Email Notification called Approval Request. It is sent when an approval event is fired, which happens in a Business Rule on the Approval table. It uses the e-mail template mentioned earlier, giving the recipient information and an opportunity to approve it either in their web browser, or using their e-mail client.

If Howard Johnson was set as the manager of the Maintenance group, he will be receiving any approval requests generated when the Send to External button is clicked on. Try changing the e-mail address in Howard’s user account to your own, but ensure the Notification field is set to Enable. Then try creating some approval requests.

Specifying Notification Preferences

Every user that has access to the standard web interface can configure their own e-mail preferences through the Subscription Notification functionality. Navigate to Self-Service > My profile and click on Notification Preferences to explore what is available. It represents the Notification Messages [cmn_notif_message] table in a straightforward user interface.

The Notification Preferences screen shows all the notifications that the user has received, such as the Approval Request and Work notes update configured earlier. They are organized by device. By default, every user has a primary e-mail device.

To never receive a notification again, just choose the Off selection and save. This is useful if you are bombarded by e-mails and would rather use the web interface to see updates!

If you want to ensure a user cannot unsubscribe, check the Mandatory field in the Email Notification definition record. You may need to add it to the form. This disables the choice, as per the Work notes update notification in the screenshot.

Subscribing to Email Notifications

The Email Notifications table has a field labeled Subscribable. If this is checked, then users can choose to receive a message every time the Email Notification record’s conditions are met. This offers a different way of working: someone can decide if they want more information, rather than the administrator deciding.

1. Edit the Work notes update Email Notification. Switch to the Advanced view, and using Form Design, add the Subscribable field to the Who will receive section on the form.
2. Now make the following changes. Once done, use Insert and Stay to make a copy.
   •     Name: Work notes update (Subscribable)
     
   •     Users/Groups in fields: <blank>
   •     Subscribable: <ticked>

   

3. Go to Notification Preferences and click on To subscribe to a new notification click here. The new notification can be selected from the list. Now, every time a Work note is added to any Maintenance record, a notification will be sent to the subscriber.

It is important to clear Users/Groups in field if Subscribable is ticked. Otherwise, everyone in the Work notes list will then become subscribed and receive every single subsequent notification for every record!

The user can also choose to only receive a subset of the messages. The Schedule field lets them choose when to receive notifications: perhaps only during working hours. The filter lets you define conditions, such as only receiving notifications for important issues. In this instance, a Notification Filter could be created for the Maintenance table, based upon the Priority field. Then, only Work notes for high-priority Maintenance tasks would be sent out.

Creating a new device

The Notification Devices [cmn_notif_device] table stores e-mail addresses for users. It allows every user to have multiple e-mail addresses, or even register mobile phones for text messages.

When a User record is created, a Business Rule named Create primary email device inserts a record in the Notification Devices table. The value in the Email field on the User table is just copied to this table by another Business Rule named Update Email Devices.

A new device can be added from the Notification Preferences page, or a Related List can be added to the User form.

Navigate to User Administration > Users and create a new user. Once saved, you should receive a message saying Primary email device created for user (the username is displayed in place of user). Then add the Notification Device > User Related List to the form where the e-mail address record should be visible. Click on New.

The Notification Device form allows you to enter the details of your e-mail- or SMS-capable device. Service provider is a reference field to the Notification Service Provider table, which specifies how an SMS message should be sent. If you have an account with one of the providers listed, enter your details.

There are many hundreds of inactive providers in the Notification Service Provider [cmn_notif_service_provider] table. You may want to try enabling some, though many do not work for the reasons discussed soon.

Once a device has been added, they can be set up to receive messages through Notification Preferences. For example, a user can choose to receive approval requests via a text message by adding the Approval Request Notification Message and associating their SMS device. Alternatively, they could have two e-mail addresses, with one for an assistant.

If a Notification is sent to a SMS device, the contents of the SMS alternate field are used. Remember that a text message can only be 160 characters at maximum.

The Notification Device table has a field called Primary Email. This determines which device is used for a notification that has not been sent to this user before. Despite the name, Primary Email can be ticked for an SMS device.

Sending text messages

Many mobile phone networks in the US supply e-mail-to-SMS gateways. AT&T gives every subscriber an e-mail address in the form of [email protected]. This allows the ServiceNow instance to actually send an e-mail and have the gateway convert it into an SMS. The Notification Service Provider form gives several options to construct the appropriate e-mail address. In this scheme, the recipient pays for the text message, so the sending of text messages is free.

Many European providers do not provide such functionality, since the sender is responsible for paying. Therefore, it is more common to use the Web to deliver the message to the gateway: perhaps using REST or SOAP. This gives an authenticated method of communication, which allows charging.

The Notifications Service Provider table also provides an Advanced notification checkbox that enables a script field. The code is run whenever the instance needs to send out an e-mail. This is a great place to call a Script Include that does the actual work, providing it with the appropriate parameters.

Some global variables are present: email.SMSText contains the SMS alternate text and device is the GlideRecord of the Notification Device. This means device.phone_number and device.user are very useful values to access.

Delivering an e-mail

There are a great many steps that the instance goes through to send an e-mail. Some may be skipped or delivered as a shortcut, depending on the situation, but there are usually a great many steps that are processed. An e-mail may not be sent if any one of these steps goes wrong!

1. A record is updated: Most notifications are triggered when a task changes state or a comment is added. Use debugging techniques to determine what is changing.
   

   These next two steps may not be used if the Notification does not use events.

2. An event is fired: A Business Rule may fire an event. Look under System Policy > Events > Event Log to see if it was fired.
3. The event is processed: A Scheduled Job will process each event in turn. Look in the Event Log and ensure that all events have their state changed to Processed.
4. An Email Notification is processed: The event is associated with an Email Notification or the Email Notification uses the Inserted and Updated checkboxes to monitor a table directly.
5. Conditions are evaluated: The platform checks the associated record and ensures the conditions are met. If not, no further processing occurs.
6. The receivers are evaluated: The recipients are determined from the logic in the Email Notification.
   

   The use of Send to event creator makes a big impact on this step.

7. The Notification Device is determined: The Notification Messages table is queried. The appropriate Notification Device is then found. If the Notification Device is set to inactive, the recipient is dropped.
   

   The Notification field on the User record will control the Active flag of the Notification Devices.

8. Any Notification Device filters are applied: Any further conditions set in the Notification Preferences interface are evaluated, such as Schedule and Filter.
9. An e-mail record is generated: Variable substitution takes place on the Message Text and a record is saved into the sys_email table, with details of the messages in the Outbox. The Email Client starts at this point.
10. The weight is evaluated: If an Email Notification with a lower weight has already been generated for the same event, the e-mail has the Mailbox field set to Skipped.
11. The email is sent: The SMTP Sender Scheduled Job runs every minute. It picks up all messages in the Outbox, generates the message ID, and connects to the SMTP server specified in Email properties. This only occurs if Mail sending is enabled in the properties. Errors will be visible under System Mailboxes > Outbound > Failed.

The generated e-mails can be monitored in the System Mailboxes Application Menu, or through System Logs > Emails. They are categorized into Mailboxes, just like an e-mail client. This should be considered a backend table, though some customers who want more control over e-mail notifications make this more accessible.

Knowing who the e-mail is from

ServiceNow uses one account when sending e-mails. This account is usually the one provided by ServiceNow, but it can be anything that supports SMTP: Exchange, Sendmail, NetMail, or even Gmail.

The SMTP protocol lets the sender specify who the mail is from. By default, no checks are done to ensure that the sender is allowed to send from that address. Every e-mail client lets you specify who the e-mail address is from, so I could change the settings in Outlook to say my e-mail address is [email protected] or [email protected].

Spammers and virus writers have taken advantage of this situation to fill our mailboxes with unwanted e-mails. Therefore, e-mail systems are doing more authentication and checking of addresses when the message is received. You may have seen some e-mails from your client saying an e-mail has been delivered on behalf of another when this validation fails, or it even falling into the spam directly.

ServiceNow uses SPF to specify which IP addresses can deliver service-now.com e-mails. Spam filters often use this to check if a sender is authorized. If you spoof the e-mail address, you may need to make an exception for ServiceNow. Read up more about it at:

http://en.wikipedia.org/wiki/Sender_Policy_Framework.

You may want to change the e-mail addresses on the instance to be your corporate domain. That means that your ServiceNow instance will send the message but will pretend that it is coming from another source. This runs the real risk of the e-mails being marked as spam. Instead, think about only changing the From display (not the e-mail address) or use your own e-mail account.

Receiving e-mails

Many systems can send e-mails. But isn’t it annoying when they are broadcast only? When I get sent a message, I want to be able to reply to it. E-mail should be a conversation, not a fire-and-forget distribution mechanism.

So what happens when you reply to a ServiceNow e-mail? It gets categorized, and then processed according to the settings in Inbound Email Actions.

Lots of information is available on the wiki: http://wiki.servicenow.com/?title=Inbound_Email_Actions.

Determining what an inbound e-mail is

Every two minutes, the platform runs the POP Reader scheduled job. It connects to the e-mail account specified in the properties and pulls them all into the Email table, setting the Mailbox to be Inbox.

Despite the name, the POP Reader job also supports IMAP accounts.

This fires an event called email.read, which in turn starts the classification of the e-mail. It uses a series of logic decisions to determine how it should respond. The concept is that an inbound e-mail can be a reply to something that the platform has already sent out, is an e-mail that someone forwarded, or is part of an e-mail chain that the platform has not seen before; that is, it is a new e-mail. Each of these are handled differently, with different assumptions.

As the first step in processing the e-mail, the platform attempts to find the sender in the User table. It takes the address that the e-mail was sent from as the key to search for. If it cannot find a User, it either creates a new User record (if the property is set), or uses the Guest account.

1. Should this e-mail be processed at all? If either of the following conditions match, then the e-mail has the Mailbox set to skipped and no further processing takes place:
   •     Does the subject line start with recognized text such as “out of office autoreply”?
   •     Is the User account locked out?
2. Is this a forward? Both of the following conditions must match, else the e-mail will be checked as a reply:
   •     Does the subject line start with a recognized prefix (such as FW)?
   •     Does the string “From” appear anywhere in the body?
3. Is this a reply? One of the following conditions must match, else the e-mail will be processed as new:
   •     Is there a valid, appropriate watermark that matches an existing record?
   •     Is there an In-Reply-To header in the e-mail that references an e-mail sent by the instance?
   •     Does the subject line start with a recognized prefix (such as RE) and contain a number prefix (such as MAI000100)?
4. If none of these are affirmative, the e-mail is treated as a new e-mail.

The prefixes and recognized text are controlled with properties available under System Properties > Email.

This order of processing and logic cannot be changed. It is hardcoded into the platform. However, clever manipulation of the properties and prefixes allows great control over what will happen. One common request is to treat forwarded e-mails just like replies. To accomplish this, a nonsensical string should be added into the forward_subject_prefix, and the standard values added to the reply_subject prefix. property. For example, the following values could be used:

• Forward prefix: xxxxxxxxxxx
• Reply prefix: re:, aw:, r:, fw:, fwd:…

This will ensure that a match with the forwarding prefixes is very unlikely, while the reply logic checks will be met.

Creating Inbound Email Actions

Once an e-mail has been categorized, it will run through the appropriate Inbound Email Action. The main purpose of an Inbound Email Action is to run JavaScript code that manipulates a target record in some way. The target record depends upon what the e-mail has been classified as:

• A forwarded or new e-mail will create a new record
• A reply will update an existing record

Every Inbound Email Action is associated with a table and a condition, just like Business Rules. Since a reply must be associated with an existing record (usually found using the watermark), the platform will only look for Inbound Email Actions that are against the same table. The platform initializes the GlideRecord object current as the existing record.

An e-mail classified as Reply must have an associated record, found via the watermark, the In-Reply-To header, or by running a search for a prefix stored in the sys_number table, or else it will not proceed.

Forwarded and new e-mails will create new records. They will use the first Inbound Email Action that meets the condition, regardless of the table. It will then initialize a new GlideRecord object called current, expecting it to be inserted into the table.

Accessing the e-mail information

In order to make the scripting easier, the platform parses the e-mail and populates the properties of an object called email. Some of the more helpful properties are listed here:

• email.to is a comma-separated list of e-mail addresses that the e-mail was sent to and was CC’ed to.
• email.body_text contains the full text of the e-mail, but does not include the previous entries in the e-mail message chain.
  

  This behavior is controlled by a property. For example, anything that appears underneath two empty lines plus —–Original Message—– is ignored.

• email.subject is the subject line of the e-mail.
• email.from contains the e-mail address of the User record that the platform thinks sent the e-mail.
• email.origemail uses the e-mail headers to get the e-mail address of the original sender.
• email.body contains the body of the e-mail, separated into name:value pairs. For instance, if a line of the body was hello:world, it would be equivalent to email.body.hello = ‘world’.

Approving e-mails using Inbound Email Actions

The previous section looked at how the platform can generate mailto links, ready for a user to select. They generate an e-mail that has the word approve or reject in the subject line and watermark in the body.

This is a great example of how e-mail can be used to automate steps in ServiceNow. Approving via e-mail is often much quicker than logging in to the instance, especially if you are working remotely and are on the road. It means approvals happen faster, which in turn provides better service to the requesters and reduces the effort for our approvers. Win win!

The Update Approval Request Inbound Email Action uses the information in the inbound e-mail to update the Approval record appropriately. Navigate to System Policy > Email > Inbound Actions to see what it does. We’ll inspect a few lines of the code to get a feel for what is possible when automating actions with incoming e-mails.

Understanding the code in Update Approval Request

One of the first steps within the function, validUser, performs a check to ensure the sender is allowed to update this Approval. They must either be a delegate or the user themselves. Some companies prefer to use an e-Signature method to perform approval, where a password must be entered. This check is not up to that level, but does go some way to helping.

E-mail addresses (and From strings) can be spoofed in an e-mail client.

Assuming the validation is passed, the Comments field of the Approval record is updated with the body of the e-mail.

current.comments = "reply from: " + email.from + "nn" + email.body_text;

In order to set the State field, and thus make the decision on the Approval request, the script simply runs a search for the existence of approve or reject within the subject line of the e-mail using the standard indexOf string function. If it is found, the state is set.

if (email.subject.indexOf("approve") >= 0)

current.state = "approved";

if (email.subject.indexOf("reject") >= 0)

current.state = "rejected";

Once the fields have been updated, it saves the record. This triggers the standard Business Rules and will run the Workflow as though this was done in the web interface.

Updating the Work notes of a Maintenance task

Most often, a reply to an e-mail is to add Additional comments or Work notes to a task. Using scripting, you could differentiate between the two scenarios by seeing who has sent the e-mail: a requester would provide Additional comments and a fulfiller may give either, but it is safer to assume Work notes.

Let’s make a simple Inbound Email Action to process e-mails and populate the Work notes field.

Navigate to System Policy > Email > Inbound Actions and click on New. Use these details:

• Name: Work notes for Maintenance task
• Target table: Maintenance [u_maintenance]
• Active: <ticked>
• Type: Reply
• Script:

  current.work_notes = "Reply from: " + email.origemail + "nn" + email.body_text;

  current.update();

This script is very simple: it just updates our task record after setting the Work notes field with the e-mail address of the sender and the text they sent. It is separated out with a few new lines. The platform impersonates the sender, so the Activity Log will show the update as though it was done in the web interface.

Once the record has been saved, the Business Rules run as normal. This includes ServiceNow sending out e-mails. Anyone who is in the Work notes list will receive the e-mail. If Send to event creator is ticked, it means the person who sent the e-mail may receive another in return, telling them they updated the task!

Having multiple incoming e-mail addresses

Many customers want to have logic based upon inbound e-mail addresses. For example, sending a new e-mail to [email protected] would create a task for the Finance team, while [email protected] creates a ticket for the Networking group. These are easy to remember and work with, and implementing ServiceNow should not mean that this simplicity should be removed.

ServiceNow provides a single e-mail account that is in the format [email protected] and is not able to provide multiple or custom e-mail addresses. There are two broad options for meeting this requirement:

• Checking multiple accounts
• Redirecting e-mails

Using the Email Accounts plugin

While ServiceNow only provides a single e-mail address, it has the ability to pull in e-mails from multiple e-mail accounts through the Email Accounts plugin.

The wiki has more information here: http://wiki.servicenow.com/?title=Email_Accounts.

Once the plugin has been activated, it converts the standard account information into a new Email Account [sys_email_account] record. There can be multiple Email Accounts for a particular instance, and the POP Reader job is repurposed to check each one. Once the e-mails have been brought into ServiceNow, they are treated as normal.

Since ServiceNow does not provide multiple e-mail accounts, it is the customer’s responsibility to create, maintain, and configure the instance with the details, including the username and passwords. The instance will need to connect to the e-mail account, which is often hosted within the customer’s datacenter. This means that firewall rules or other security methods may need to be considered.

Redirecting e-mails

Instead of having the instance check multiple e-mail accounts, it is often preferable to continue to work with a single e-mail address. The additional e-mail addresses can be redirected to the one that ServiceNow provides.

The majority of e-mail platforms, such as Microsoft Exchange, make it possible to redirect e-mail accounts. When an e-mail is received by the e-mail system, it is resent to the ServiceNow account. This process differs from e-mail forwarding:

• Forwarding involves adding the FW: prefix to the subject line, altering the message body, and changing the From address.
• Redirection sends the message unaltered, with the original To address, to the new address. There is little indication that the message has not come directly from the original sender.

Redirection is often an easier method to work with than having multiple e-mail accounts. It gives more flexibility to the customer’s IT team, since they do not need to provide account details to the instance, and enables them to change the redirection details easily. If a new e-mail address has to be added or an existing one decommissioned, only the e-mail platform needs to be involved. It also reduces the configuration on the ServiceNow instance; nothing needs to change.

Processing multiple e-mail address

Once the e-mails have been brought into ServiceNow, the platform will need to examine who the e-mail was sent to and make some decisions. This will allow the e-mails sent to [email protected] to be routed as tasks to the networking team.

There are several methods available for achieving this:

• A look-up table can be created, containing a list of e-mail addresses and a matching Group reference. The Inbound Email Script would use a GlideRecord query to find the right entry and populate the Assignment group on the new task.
• The e-mail address could be copied over into a new field on the task. Standard routing techniques, such as Assignment Rules and Data Lookup, could be used to examine the new field and populate the Assignment group.
• The Inbound Email Action could contain the addresses hardcoded in the script. While this is not a scalable or maintainable solution, it may be appropriate for a simple deployment.

Recording Metrics

ServiceNow provides several ways to monitor the progress of a task. These are often reported and e-mailed to the stakeholders, thus providing insight into the effectiveness of processes.

Metrics are a way to record information. It allows the analysis and improvement of a process by measuring statistics, based upon particular defined criteria. Most often, these are time based. One of the most common metrics is how long it takes to complete a task: from when the record was created to the moment the Active flag became false. The duration can then be averaged out and compared over time, helping to answer questions such as Are we getting quicker at completing tasks?

Metrics provide a great alternative to creating lots of extra fields and Business Rules on a table.

Other metrics are more complex and may involve getting more than one result per task.

• How long does each Assignment group take to deal with the ticket?
• How long does an SLA get paused for?
• How many times does the incident get reassigned?

The difference between Metrics and SLAs

At first glance, a Metric appears to be very similar to an SLA, since they both record time.

However, there are some key differences between Metrics and SLAs:

• There is no target or aim defined in a Metric. It cannot be breached; the duration is simply recorded.
• A Metric cannot be paused or made to work to a schedule.
• There is no Workflow associated with a Metric.

In general, a Metric is a more straightforward measurement, designed for collecting statistics rather than being in the forefront when processing a task.

Running Metrics

Every time the Task table gets updated, the metrics events Business Rule fires an event called metric.update. A Script Action named Metric Update is associated with the event and calls the appropriate Metric Definitions.

If you define a metric on a non-task-based table, make sure you fire the metric.update event through a Business Rule.

The Metric Definition [metric_definition] table specifies how a metric should be recorded, while the Metric Instance [metric_instance] table records the results. As ever, each Metric Definition is applied to a specific table.

The Type field of a Metric Definition refers to two situations:

• Field value duration is associated with a field on the table. Each time the field changes value, the platform creates a new Metric Instance. The duration for which that value was present is recorded. No code is required, but if some is given, it is used as a condition.
• Script calculation uses JavaScript to determine what the Metric Instance contains.

Scripting a Metric Definition

There are several predefined variables available to a Metric Definition: current refers to the GlideRecord under examination and definition is a GlideRecord of the Metric Definition.

The MetricInstance Script Include provides some helpful functions, including startDuration and endDuration, but it is really only relevant for time-based metrics. Metrics can be used to calculate many statistics (like the number of times a task is reopened), but code must be written to accomplish this.

Monitoring the duration of Maintenance tasks

Navigate to Metrics > Definitions and click on New. Set the following fields:

• Name: Maintenance states
• Table: Maintenance [u_maintenance]
• Field: State
• Timeline: <ticked>

Once saved, test it out by changing the State field on a Maintenance record to several different values. Make sure to wait 30 seconds or so between each State change, so that the Scheduled Job has time to fire. Right-click on the Form header and choose Metrics Timeline to visualize the changes in the State field.

Adding the Metrics Related List to the Maintenance form will display all the captured data. Another Related List is available on the Maintenance Definition form.

Summary

This article showed how to deal with all the data collected in ServiceNow. The key to this is the automated processing of information. We started with exploring events. When things happen in ServiceNow, the platform can notice and set a flag for processing later. This keeps the system responsive for the user, while ensuring all the work that needs to get done, does get done.

Scheduled Jobs is the background for a variety of functions: scheduled reports, scripts, or even task generation. They run on a periodic basis, such as every day or every hour. They are often used for the automatic closure of tasks if the requester hasn’t responded recently.

Email Notifications are a critical part of any business application. We explored how e-mails are used to let requesters know when they’ve got work to do, to give requesters a useful update, or when an approver must make a decision. We even saw how approvers can make that decision using only e-mail.

Every user has a great deal of control over how they receive these notifications. The Notification Preferences interface lets them add multiple devices, including mobile phones to receive text messages.

The Email Client in ServiceNow gives a simple, straightforward interface to send out e-mails, but the Additional comments and Work notes fields are often better and quicker to use. Every e-mail can include the contents of fields and even the output of scripts.

Every two minutes, ServiceNow checks for e-mails sent to its account. If it finds any, the e-mail is categorized into being a reply, forward, or new and runs Inbound Email Actions to update or create new records.