I don't know why, but in years of mentoring ServiceNow admins, this seems to come up as a popular topic. For beginning Now Platform enthusiasts, its worth noting your notification options before attending to customer requirements. This post will focus on email, and depending on popularity I'll explore some more exotic options.:
OPTION 1: SELF CONTAINED NOTIFICATION RECORD
This is your standard "define a notification with triggering conditions" option. Believe it or not, back in 1912 we old timers didn't have this option. Notifications used to be entirely event drive (see option 2). Today you youngin's get all the conditional wizard goodness of a business rule, combined with the specific email targeting of a notification record.
Your Send When will be "record inserted or updated" or "triggered". 90% of the time you're picking "record inserted or updated". "triggering" has to do with the Flow Designer, which I'll get to later. If you pick "record inserted or updated", you're presented with a condition builder from which you determine the rules for when the notification works. Easy peasy. Fill out your recipients and content fields and this notification is good to go.
This method will be your go to most of the time, but Option 2 is also *very* important.
OPTION 2: EVENT DRIVEN NOTIFICATION
Option 2 gives you all the conditional logic of Option 1, but also adds another triggering condition. Before the notification's conditions evaluate, an event must be fired. Once the event is fired, the notification considers the additional conditions, then fires as normal
What's an Event, though?
Its deceptively simple. Its just a "thing" the system can declare at any time and feed parameters. You frequently see it in business rules and workflow. "If this happens, throw event XYZ". Once the event is thrown, other parts of the tool react to the thrown event, such as notifications and event scripts. Think of it like a script based condition.
To fire an event, you simply define what table it's valid for, and what the event name is. If you're a *good* admin, and I know you are, you also leave a good description, as well as describing what mechanisms fire the event (workflows, business rules, etc).
But why the complexity?
Easy. Complexity is often the path to greater flexibility and nuance. Event driven Notifications can simply handle more exotic triggers. Consider the following OOB examples:
Scheduled Import Completed
After a scheduled import happens, a script will fire the scheduled_import_set.completed event. That event will trigger the Scheduled Import Completed email.
How would you have built this with Option 1? You wouldn't, because the triggering condition isn't happening in a usefull place (the table handling the transaction).
Any "Comment" Notification
Almost all comment notifications are event driven. Why? Because a business rule is determining which *way* it was commented, which is why you magically have notifications going to either the customer or the assigned to based on who actually made the comment. The recipient is often loaded into the event as a parameter.
Other exotic use cases?
- use gs.eventqueue() in order to launch a notification and determine recipient via script (any script: business rule, script include, inbound email action, UI action, etc)
- Simplifying conditions: Say you have 5 potential closure notifications. A business rule can fire the "thing.closed" event for your table, but you can have 5 notification records triggered by the event, each with their own additional conditions. Very handy if you ever have situations where multiple notifications *can* trigger off a single complex occurrence.
- using workflow to trigger events. Very handy if the parameters might be determined via variables or scratchpad variables within a workflow.
OPTION 3: WORKFLOW NOTIFICATION
The least advantageous of the notification options. A workflow hard codes a notification within an activity. Why is this a bad option? LET ME COUNT THE WAYS!
1) It forces you to express condition logic as workflow activities (scripts, if, switches, or otherwise)... making a workflow canvas even more crowded than usual
2) Its far less feature rich than a normal Notification Record
3) If anything's wrong with the notification, it will laugh at you while you impotently search through the Notification list to find something to troubleshoot. Workflow Notification are not of the same class as Options 1 and 2. They are seperately stored. Where? In the workflows! The most frustrating and high friction place they can possibly be defined.
REMEMBER! It is *always* better to create an event, trigger it from workflow, and use that event as a condition on a Notification record. ALWAYS.
KEY TAKE AWAYS
- Option 1 is effective most of the time.
- Option 2 is just as effective, but provides far more nuance and control
- Option 3 isn't really an option. Ask a coworker to stomp on your foot, pour a glass of cold water on your head, re-evaluate Options 1 and 2.
1 Comment
