Implementing Event-Triggered Notifications in ServiceNow

Takefumi Muto — Sun, 14 Sep 2025 21:16:54 +0000

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:

Register the event in Event Registry.
Use a Business Rule to fire the event with gs.eventQueue().
Create a Notification triggered by the event.
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.

DEV Community: Takefumi Muto