ServiceNow notifications are usually event-driven: a business rule fires an event, and a notification record matching that event sends an email or push. The hard part is not sending one notification, it is sending the right one, once, to the right people, on a system where a single update can fire many rules.
Before you start
You should be comfortable with business rules and the GlideRecord API. This article covers notification triggering and control; it assumes access to a development instance.
Step-by-step walkthrough
Step 1: Trigger through the event queue
Use gs.eventQueue('incident.assigned', current, ...) from a business rule in place of sending mail directly. The event queue decouples the trigger from delivery, so a processing failure does not roll back the transaction that raised the event, and it gives you a record of what fired.
Step 2: Gate with the notification’s own conditions
Put the “should this send” logic on the notification record’s When to send and condition fields rather than in the event. Keeping the gate with the notification makes it visible to admins, easy to change, and applies consistently across every caller of the event.
Step 3: Respect frequency and preference
Group related updates into a digest instead of one mail per change, and honor user notification preferences and subscription settings. For high-volume tables, throttle or batch so a bulk import does not generate thousands of messages.
Worked scenario
The business rule queues an event; the notification decides whether it sends.
(function executeRule(current, previous) {
if (current.assignment_group.changes() || current.assigned_to.changes()) {
gs.eventQueue('incident.assigned', current, current.assigned_to.getDisplayValue());
}
})(current, previous);Walk through the example
The rule fires the event only when the assignment actually changed, so unrelated edits do not notify. The corresponding notification holds the recipient and template, and its conditions decide whether to send. Splitting the trigger from the content means an admin can adjust who and when without touching code.
Common mistake
Sending mail directly from a business rule, which couples delivery to the transaction and bypasses the notification management UI. Another is triggering on every update, so a status change fires an assignment notification that no one needed.
Verify the behavior
Check the event queue log after an update to confirm the event fired once. Temporarily set the event to out of scope and assert no mail is sent. Run a bulk update and confirm digests or throttling keep the message count bounded rather than one per record.
Interview exercise
A bulk import generated thousands of emails. How do you prevent it?
Answer and reasoning
Gate the notification on a condition that excludes bulk or scheduled context, and batch remaining messages into a digest rather than one per update. If the import is a data load, suppress notifications for that operation and optionally send a single summary. The cause is triggering per change without a frequency control, so the fix is a condition plus grouping.
Continue learning
Compare rule timing in Business rule timing and Flow Designer. Read the ServiceNow notifications documentation and try the ServiceNow interview questions.