The Zurich release has arrived! Interested in new features and functionalities? Click here for more

Email Notification: Condition vs Event

salvadormarchan
Kilo Guru

Gurus and Experts,

Can anyone please advise me the pro and con of using Condition vs Event (and vice versa) in triggering Email Notification?

It is somewhat a puzzle to me why one wold favor using event from condition and vice-versa.

Thank you in advance.

Salvador

5 REPLIES 5

Albert13
Kilo Sage

A condition allows for fine tuning of your event. Here's an example



Lets say I want a specific notification email to be sent to the group manger when a priority 1 incident is assigned



Event:incident.assigned.to.group


The notification would be triggered when an incident is assigned to an group.   By itself the email notification would trigger on every assignment.   If I add the condition would be Priority is 1 - Critical the notification is only triggered if an incident is assigned to a group AND the priority is 1.



Hope that help



Albert


Jacob_Andersen
ServiceNow Employee
ServiceNow Employee

Email notifications were coded up very early on in ServiceNow and events were the only way to send a notification.   Being able to send a notification based on a condition is relatively new (introduced last year, I believe).   Most new development will trigger the emails using the new conditions, though you will see legacy notifications still being triggered by events.



I find the conditions to be a much simpler way to setup the notifications.   The only advantage that I would give to events is that you can see fired events in the event log which may help in troubleshooting.


Also in some cases it's not possible to fire a notification via a condition such as inside a workflow or similar. The creation of an event can be triggered by business rule or workflow which allows a few more options than simply the update or insert of a record with conditions.


kungfuu72
Giga Expert

If you had the options, if at anyway possible, we try to make our notifications condition-based rather than event-based.



Pros of Condition-based:


  • For most cases, condition-based notifications cover the broad base of having a notification sent to a particular user. In using the Who will receive tab, you can usually dot-walk to whoever you need the notification to send to, and even hard-coded if needed.
  • Condition-based notifications simplify the process greatly for most use-cases and if you go to the Advanced view you can even write in your own complex conditions in the Advanced condition: script box.
  • Easier to maintain.


Cons of Condition-based:


  • If your notification is set to send on Record inserted or updated the event value does not go away, and if you set your notification to event fired, the conditions do not go away... This can be challenging in itself because (please correct me if I'm wrong) I actually don't think that the event is evaluated if the notification is condition-based, and I don't think the conditions are evaluated if the notification is event-based... If you can keep this straight, I guess you'll be fine, but it just seems like ServiceNow should keep them segregated more; my opinion...


Pros of Event-based:


  • Like Jacob said, back in the early days notifications only fired from events triggered in the Event Registry. On very few occasions now, we have created these event-based notifications to fire off when a Condition-based notification just wouldn't do it. For example, we have a notification to trigger through a UI Action that sends a survey to the Customer if the user has not completed a survey yet for that task. The UI Action triggers the event. It would be much more difficult to do this using only the conditions filters for notifications... if not, impossible.


Cons of Event-based:


  • Troubleshooting event-based notifications, or tracking down who they send to is a process I can live without... Every time we look through an event-based notifications, we have to (1) look at the event and find it in the registry, (2), see where the event is defined in any and all business rules or workflows, (3) see what the parameters are defined as and what their values may return, and then we finally have all the information we need to troubleshoot the notification or just to update it.
  • As mentioned, the events can be written anywhere, so tracking this down can be a burden.