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

Eric K3 · ‎01-07-2016

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.

Uncle Rob · ‎01-07-2016

"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.

View solution in original post

johnram · ‎09-22-2017

The ServiceNow Wiki content is no longer supported. Updated information about this topic is located here:

Scripting for Email Notifications
Business Rules

Visit http://docs.servicenow.com for the latest product documentation

tony_barratt · ‎01-07-2016

Hi Eric,

A plus point for using Record inserted or updated rather than events is that you can use Changes in the Send When section.

Changes operator in notification condition cannot be used with event based notifications

Email Notifications - ServiceNow Wiki

..

2.2 Specifying When to Send the Notification

When creating a notification based on a new or updated record, specify what additional conditions must be met to trigger the notification. You can specify these notification-specific conditions.

Changes: Checks to a see if a field value changes.
Changes from: Checks to see if a field value changes from a particular value.
Changes to: Checks to see if a field changes to a particular value.

Best Regards

Tony

Mike Allen · ‎01-08-2016

Unless you use something like this:

if(current.state.changesTo(6)){

gs.eventQueue('incident.state.cahnged', current, parm1, parm2);

}

Eric K3 · ‎01-11-2016

Thanks for everyone's input.

Also, as far as speed is concerned when running a business rule that fires an event, does it make sense to set the Bus Rule as async? Right now we have it set as After, which based on http://wiki.servicenow.com/index.php?title=Execution_Order_of_Scripts_and_Engines#gsc.tab=0 might be causing the 1 or 2 second delay in sending out the notification. There are a few async Bus Rules on the Task table that fire events, so it makes me think async is the way to go.

Mike Allen · ‎01-11-2016

Asynch is always good if you are not expecting a response. It allows the system to send it and forget it.