Implementing Event-Triggered Notifications in ServiceNow

Introduction

In ServiceNow, the most common way to send a Notification is to trigger it when a record is inserted or updated.
However, sometimes this approach is not flexible enough, especially when:

• The condition is too complex for the GUI.
• You need to compare old and new values in the notification.
• You want to suppress notifications for API calls.
• You want to reuse the same trigger across multiple notifications or processes.

This is where event-triggered notifications come in handy.
In this post, I’ll walk you through an implementation where a notification is sent when the priority of an Incident changes, using an Event as the trigger.

Implementation Steps

1. Event Registry

First, create a custom Event Registry entry.

• Name: Test_incident.priority_changed
• Table: incident
• Description: Event fired when the priority changes

<event_name>Test_incident.priority_changed</event_name> <table>incident</table> <description>Event Registration of test</description> 

2. Business Rule: Fire the Event

Next, create a Business Rule that fires the event whenever the priority changes.

• Name: Test_incident events
• Table: incident
• When: after update

if (current.priority.changes() && current.priority != previous.priority) { gs.eventQueue( "Test_incident.priority_changed", // event name current, // source record current.priority.toString(), // parm1: new priority previous.priority.toString() // parm2: old priority ); } // Optional: exclude updates from Connect API function isConnect() { var transaction = GlideTransaction.get(); if (!transaction) return false; var request = transaction.getRequest(); if (!request) return false; var path = request.getRequestURI(); return path && path.match(/\/api\/now\/connect/); } 

👉 Here, I’m passing parm1 (new priority) and parm2 (old priority) so they can be referenced later in the notification body.

3. Notification

Now, configure the Notification that listens for the event.

• Name: Test_Event trigger notification
• When to send: Event is fired → Test_incident.priority_changed
• Subject:

 Test Subject: ${number} 

• Body:

 Incident ${number} priority has changed! Previous: ${event.parm2} Current: ${event.parm1} 

4. Unit Test

Finally, let’s test with an Incident record.

• Incident: INC0010005

  • Short description: Event Trigger Notification Test
  • Priority: changed from 3 → 1

• Notification Result

Subject:

Test Subject: INC0010005 

Body:

Incident INC0010005 priority has changed! Previous: 3 Current: 1 

✅ Works as expected — the event parameters were passed into the notification successfully.

Why Use Events?

From this small experiment, I can summarize the main benefits of event-triggered notifications:

• Handle complex conditions via scripts.
• Easily insert old/new values into notifications.
• Reuse the same event across multiple notifications or flows.
• Prevent unnecessary notifications (e.g., API updates).

For simple cases like “notify the assignee when an Incident is created,” a standard notification is fine.
But once conditions get more advanced, events give you much more control.

Conclusion

Here’s the overall flow again:

1. Register the event in Event Registry.
2. Use a Business Rule to fire the event with gs.eventQueue().
3. Create a Notification triggered by the event.
4. Pass parameters (parm1, parm2) for richer notification content.

This approach is flexible, reusable, and prevents unwanted notifications.

Next Steps

• Use Flow Designer to trigger Slack messages from the event.
• Explore Notification Email Scripts for richer email content.
• Try applying the same pattern to Change or Problem records.

✍️ That’s it! This was a simple but effective pattern for event-triggered notifications in ServiceNow.