Event-Driven Notifications in ServiceNow

As we discovered, the email notifications as major form of notifications in ServiceNow. Let us move forward to the event-driven notifications. These notifications decouple simple database inserts and updates using server-side scripts, after registering an event. 

ServiceNow Notifications on Event is fired

When a notification’s Send to field is set to Event is fired, the ServiceNow instance remains idle until a trigger is generated in the system’s event. 

Here, a Workflow or Scheduled Job runs a script. If the condition is met, it fires an event. The Notification listens for that event. The event-triggered notification provides Infinite flexibility and Decouples the logic from the email.

Event Registry 

When an event is fired, the registered entry makes sure that events match the right email notifications and scripts. The navigation path of an event registry is:

1. System Policy: It ensures a specific UI path that you must use within the platfrom to access all the system events in one place. It allows creating, viewing, and modification of events. 
2. Events: It is a digital signal notifying the user that something important has happened in the system. These events are sent to the System event line using Business rules or workflows. 
3. Registry: Event Registry is like a central log or phone book where all events are registered before they are used by the system. 

Script Syntax

gs.eventQueue(‘event.name’, current, ‘parm1’, ‘parm2’). 

The gs.eventQueue() is the server-side process that helps insert events in an event queue. The major components in the Script syntax are: 

1. ‘event.name’ String: Defines the exact name of the event as per the event registry. 
2. Current Glide Record: It is the database record that is attached to the event, like incidents, change requests, or user records.
3. ‘parm1’ (String): Parameter 1 is an optional, generic string that is used to pass additional data to the event queue. 
4. ‘parm2’ (String): Parameter 2 is also an optional string/variable similar to Parameter 1. 

ServiceNow Notifications when a Trigger is Executed (Record-Based)

Scenario: “Email the assignee whenever the Priority changes to Critical.”

• Method: Select the record inserted or updated in the “When to send” tab.
• Pros: No coding required. Fast to set up.
• Cons: Limited logic. Cannot handle “Time-based” triggers (e.g., email 2 days after an update).

Email Subscription ServiceNow

Many a time, users get Notification Fatigue and create rules to delete all system emails. To avoid this, in ServiceNow, users get an option to subscribe to the emails. 

• Users can navigate to their Profile > Preferences > Notifications.
• They can toggle specific categories on/off.
• They can add a “secondary device” (e.g., SMS) for Critical alerts only.

Backend Table Name: cmn_notif_message (links the user to the notification) It stores subscriptions.

What’s Next? 

Now that we have understood the notifications using emails and event driven process for notifications. In the next topic, we will be focusing on the inbound actions that we can take in ServiceNow to process incoming emails.