Better ServiceNow Notifications (& Another FREE Tool!)
You’ve just implemented a new instance, process, catalog item, or workflow.
You put all that time and thought, and effort into making sure that everything that anyone could possibly want to know about, results in an email notification to all potentially-interested parties, so that nothing can possibly slip through the cracks!
And yet… somehow… you notice that users are still, often, not taking action where appropriate. Didn’t they get the email!?
You look through the email logs, and find that - indeed - among the sea of notifications that had been sent to them, there it is: the email telling them that they need to do something.
You: "Hey [approver], it looks like we've been waiting for you to approve this request for a couple of weeks now. Haven't you got any of the notification or reminder emails?"
Approver: "Uh... I have notifications from ServiceNow filtered to junk..."
Most of us have had some variation of this conversation.
Maybe they’ve filtered emails from ServiceNow to their junk folder. Maybe they’ve got a separate “special” folder just for SN emails, where they can be auto-routed and never looked at. Maybe they’ve just got so accustomed to 90% of the emails they get from ServiceNow being irrelevant or non-actionable for them, that they’ve got into the habit of just deleting them as soon as they show up.
The result is the same: your users aren’t getting your emails!
A notification that’s never read is worse than no notification at all.
So, how do we stop this vicious cycle? -- Let’s talk about notifications in ServiceNow.
Note: To jump straight to the free tool, hover over the Tools menu in the nav bar at the top of this page, and click on “Was this Email Helpful?”
Stick around ‘til the end of the article, for a video on our new FREE tool!
Actionable Notifications
Here’s the short version:
If the notification doesn’t indicate that the user actually needs to do anything, then it probably should not be sent to them!
Ah, if only it were entirely that simple.
Okay, sure, there will be cases - I would argue, rare cases - where an email notification should indeed be sent to a user, even if it doesn’t necessarily mean that that user needs to take any action. I’m not trying to hand down edicts over here, I’m just offering general advice. And that advice again, is: most of the time, if a user doesn’t need to do anything, then don’t send them any notifications. Most of the time.
Sure; notifications which imply that an action should be taken are cool. But, you know what’s really cool? - Notifications that specifically inform the user that an action should be taken.
Whenever possible, it’s even cooler if the notification can tell the user exactly what that action is.
Highlight the Relevant Bits
When creating notifications in ServiceNow, it’s important to think carefully about what information is necessary for the user to understand what the notification is about, as well as what information has changed.
For example, imagine I’ve set up a notification that results in an email which looks something like this:
“Incident ${number} has changed” - followed by a bunch of info about the Incident… but, what has changed!? If I’m the recipient of that notification, I have no idea!
One solution would be to only include those fields which have changed in your notifications, but that’s no good! You need some context to know what you’re looking at.
So, what do you do? I recommend displaying whatever fields are necessary for context (ticket number, assignment group, assignee, state, etc.) as well as, of course, the field which changed to trigger this notification. However, what I recommend that differs from the example above, is to use a mail script to make the fields which changed, bold.
Have a look at this example to see what I mean:
Don’t judge me for my crappy HTML examples!
Yes, writing a mail script is a little more work; but if you do it cleverly, you’ll have to write far fewer total notifications, and those notifications will be actually… useful!
If you make a serious effort to use a consistent “language” such as this for communicating notifications, users will grow accustomed to it. The goal is to make it so that when a user gets a notification from your ServiceNow instance, they can glance at it for no more than a few seconds to get all the info they need, to know if they need to do anything. (Although I would also suggest that if they don’t need to do anything, then there’s a good chance that that notification should not have gone to them at all!)
Email Digests
Email Digests are probably one of the most under-used features in the ServiceNow platform (along with tags, user preferences, and system properties to control custom functionality). In this section, we’re going to talk about why they’re great, and why you should be using them liberally!
Email Digests are simply scheduled emails that go out on some schedule. An admin determines what scheduled cadences are available (every 1 day, 3 days, 7 days, etc.) and the user selects one of the cadences you’ve made available, on which to receive emails of a certain type as a group.
Say a user has selected to receive the “Incident Commented” notification on a digest interval of 1 day, as in the screenshot below. Everyone else will continue to get notifications as they happen, just like normal; but this one user who’s enabled Email Digests for that notification will not get the usual notifications. Instead, they’ll get a “digest” version: a summary of all of the notifications of that type which happened throughout the day, no more than once per day. Every time a notification of that type would go out to them, it instead goes into a sort of queue. Once per day, that queue is emptied out and sent along as a single email.
Making your notification “digestible” is as easy as checking the Allow Digest checkbox on the notification record, and populating the What Digest will contain tab with a summary-version of your notification, and a link to the relevant record (where applicable); but there are some pro-tips and pitfalls to consider, so read on!
Which notifications to make digestible
Any notification can have a “digest version”, but not every notification should.
Consider the “Incident Commented” notification in the screenshot above. If you imagine the typical P3-P4/5 Incident, allowing comment notifications to be digestible is probably a good idea; but what about P1/P2 Incidents? And while you probably want your end-users to be able to roll-up comment notifications into a digest, do you want your service desk agents to be able to do that? - Perhaps not!
You should only check the “Allow Digest” checkbox on a notification, if it is not urgent.
Now, I’m going to level with you — this may mean making additional notifications.
I know, I know. Here I’m telling you that you should be reducing the number of emails that go out, and at the same time suggesting creating additional notification records? Stick with me for a minute -
The reason I would suggest potentially making new notification records, is in order to split existing notifications out so that you can have an “urgent” version of the notification (which does not allow digest), and a “non-urgent” version of the notification (which does allow digest). For example, instead of one “Incident Commented” notification, I might split it out into the following:
INC P1-P3 Commented (to assignee)
Fires when someone other than the assignee makes a comment
Only notifies the assignee
Only fires on P1-P3 Incidents
Does not allow digest
INC P4-P5 Commented (to assignee)
Same as above, but only fires on low-priority Incidents
Does allow digest
INC Commented (to requester)
Fires whenever someone other than the requester makes a comment
Only notifies the requester
Priority-agnostic
Does allow digest
In fact, I might even further break down the “to requester” notification into two separate ones as well, depending on priority! The key is to think carefully about (1) who will receive this notification, (2) what action needs to be taken in response to this notification, (3) is that action time-sensitive, and (4) who else might receive this notification? - Consider the same questions for them, and if the answers to “is that action time-sensitive” are different for the different potential recipients or situations, consider breaking your notification record out into multiple notifications.
Each notification can use the same template, so you don’t have to maintain multiple versions of the notification! The important things are the conditions on the notifications, and whether they’re digestible or not.
Configuring Digest Intervals
Digest Intervals can be found in the sys_email_digest_interval table. By default, there should be 4 Digest Intervals in your environment:
1 Hour
4 Hours
1 Day
7 Days
Personally, I think 7 days is too long to allow users to effectively “snooze” their notifications, and 1 hour is too short to be useful.
This is going to depend heavily on your environment, the types of notifications you’ve chosen to make digestible, and how frustrating you think your users are likely to be, but I personally prefer to have intervals for 4 hours, 1 day, and 2 days; but no more. That’s because if I’m sending a notification that the user can basically ignore for more than 2 full days without needing to actually do anything, then I’m probably sending notifications that don’t need to be sent.
Remember: The longer your max digest interval, the more careful you must be that you don’t make any important notifications digestible!
Additional Documentation
ServiceNow’s documentation on Email Digests is a pretty good resource to reference. Here are some useful links.
Free Tool: Was this Email Helpful?
This tool was developed by myself (Tim Woodruff)/The SN Guys, in collaboration with Robert Fedoruk.
Robert is the CXO of Vividcharts, and is a ServiceNow architect, and reporting/PA ninja-wizard. To subscribe to Robert’s newsletter, click here.
To subscribe to SN Pro Tips, just fill out the subscribe form below, and be notified whenever we release new articles and free tools!
(…Assuming I remember to actually send out an email about it.)