Difference between email notification 'Record inserted or updated' and 'Event is fired'

[Eric K3]

What are the differences between having an email notification go out via 'Record inserted or updated' and 'Event is fired?'

Right now, we have an After business rule that checks the incident form and then triggers an event when appropriate. The event then triggers an email notification. But I can just as easily use a 'Record inserted or updated' email notification and bypass the Bus Rule and event.

Is there a reason to stick with a Bus Rule and event instead of just the simple 'Record inserted or updated' email notification? I think I also have noticed that 'Record inserted or updated' email notifications get sent out faster than 'Event if fired' email notifications. Is this because the "notification_engine.process" is faster than the regular event queue?

Any guidance is appreciated.

[Jamsta1912]

Hi Eric,

When creating a new notification, I use 'Record inserted or updated' if I can, just because it's easier to set up and manage. But, there might not be much value in updating existing notifications that are fired by events. The option to use 'Record inserted or updated' only came in a few releases ago (I think after Calgary... but could stand corrected). But events are still useful in a lot of cases, especially if the logic behind the trigger is quite complex. Events are also useful for passing other parameters to the notification, like the current user or a state or field value from some other record type.

I'm not sure about relative speeds, but you might be right that it's faster to use 'Record inserted or updated' as I guess there are less steps in the process.

[Uncle Rob · Accepted solution]

"Fire on event" rules are extraordinarily handy as a way to keep your notifications simple, and organized.

For example.   Lets say you have a number of potential notifications based on an Incident that reaches P1.   Lets say there's 6 conditions that need to be true, and only one differentiating condition between the notifications.   You can have a business rule control the firing of the event if the first 5 conditions are true, then each notification only evaluates its single condition.

More importantly, troubleshooting notifications can be difficult because you can define notifications into extremely common locations.   Lots of people build notificaitons directly into Workflow, which I consider dangerous.   A year goes by, a new admin is at the helm, and someone says "Hey, change this notification", and it can't be found in hte notification list.   Why?   Because Workflow Notifications aren't stored in the Notification table.

So what I do is have my workflows fire events, then have notifications look for the event.   As an added bonus, I can leverage the Script Actions for added complexity.   Script Actions let you run scripts on the firing of an event.

[Mike Allen]

I always use the events-based notifications because I find it much easier to troubleshoot in the records, as well.   If you have the condition-based notifications, in my opinion, you either see the notification or you don't.   Events give you a middle ground that allow you to segment your troubleshooting into pieces (ie, did the event fire?   No?   OK, go fix the events piece on the task's business rule.   Yes?   OK, troubleshoot the actual email piece.).   You don't get a similar view using conditions.

[tony_barratt]

Hi Eric,

Good question BTW!

In addition to the points already made, Parm 1 and Parm2 can be useful when using an event - so that is plus point for using events.

Scripting for Email Notifications - ServiceNow Wiki

..

2.1 Parm1 and Parm2

The event.parm1 and event.parm2 parameters that come from the originating event can also be used within the <mail_script>. To use these, enter event.parm1 or event.parm2 in the mail script.

Events and Email Notification - ServiceNow Wiki

gs.eventQueue("incident.updated", current, gs.getUserID(), gs.getUserName());
..

The gs.eventQueue function takes the following parameters:

Field	Input Value
Name	The name of the event triggered, set in quotation marks
Record	The record referenced when the condition in the script evaluates to true. Usually this is expressed as current, meaning the current record the business rule is working on. If the business rule is being triggered as part of a scheduled job, use a GlideRecord argument in its place.
Parm1	Passes a string value. Notification events pass the Sys ID of the user with the gs.getUserID() method. Other scripts can reference this string value as parm1 using the format ${event.parm1}.
Parm2	Passes a string value. Notification events pass the user name with the gs.getUserName() method. Other scripts can reference this string values as parm2 using the format ${event.parm2}.

Best Regards

Tony