Events and Notifications

Events and Notifications in ServiceNow – CAD Exam Guide

Events and Notifications in ServiceNow

Why Is This Important?
Events and Notifications are a core part of application automation in ServiceNow. They allow the platform to communicate important information to users, groups, and external stakeholders in a timely and automated manner. Understanding how events trigger notifications is essential for the Certified Application Developer (CAD) exam because it tests your ability to design automated workflows that keep users informed without manual intervention. In real-world implementations, properly configured events and notifications reduce response times, improve user satisfaction, and ensure compliance with SLA commitments.

What Are Events?
An event in ServiceNow is a system-generated indication that something noteworthy has occurred on the platform. Events are registered in the Event Registry (sysevent_register) and are created (fired) by business rules, script actions, or other server-side scripts using the gs.eventQueue() method.

Key characteristics of events:
- Events are logged in the sysevent table.
- Each event has a name, a table it applies to, and parameters (parm1 and parm2) that can pass additional contextual information.
- Events decouple the triggering action from the response action, making the system more modular and maintainable.
- Events are processed asynchronously by the system.

What Are Notifications?
A notification is an email (or other communication) that is sent in response to an event or a record change. Notifications are configured in the Notification (sysevent_email_action) table. They define:
- When to send: The triggering condition — either an event or a record change (insert, update, or both).
- Who will receive: Users, groups, or specific email addresses defined in fields or scripts.
- What to send: The subject line and message body, which can include dynamic content using mail scripts, template variables, and notification templates.

How Events and Notifications Work Together

1. Event Registration: An event is first registered in the Event Registry (System Policy > Events > Registry). You define the event name and the table it is associated with.

2. Event Generation (Firing): An event is fired using the gs.eventQueue() function, typically within a business rule or script. The syntax is:
gs.eventQueue('event.name', current, parm1, parm2);
- The first parameter is the event name (must match the registered event).
- The second parameter is the GlideRecord object (typically current).
- parm1 and parm2 are optional string parameters that pass additional data.

3. Event Processing: The system picks up the event from the sysevent table and processes it. If a notification is configured to respond to that event, the notification engine takes over.

4. Notification Trigger: The notification record specifies the event name in its Send when field (set to Event is fired). When the matching event is processed, the notification is triggered.

5. Recipient Resolution: The system determines who should receive the notification based on the Who will receive tab configuration. Recipients can be defined by users, groups, fields on the record (e.g., assigned_to, opened_by), or via advanced scripting using event.parm1 and event.parm2.

6. Content Assembly: The notification body and subject are assembled. You can use:
- Template variables: Such as ${URI_REF}, ${assigned_to}, ${number}, etc.
- Mail scripts: Reusable scripts inserted using the template.print() or email.setBody() methods for dynamic content generation.
- Notification templates: Predefined reusable templates that standardize the look and feel of emails.

7. Email Delivery: The email is queued in the Email (sys_email) table with a type of send-ready and is sent by the SMTP server configured on the instance.

Key Concepts to Understand

Event-based vs. Record-based Notifications:
- Event-based notifications are triggered by a specific event being fired. They offer more control and are the recommended best practice because they decouple the notification from the record change logic.
- Record-based notifications are triggered directly by record inserts or updates with specified conditions. While simpler, they can be harder to manage at scale.

Email Digests:
Notifications can be configured to use digests, which batch multiple notifications into a single email sent at scheduled intervals. This reduces email overload for users.

Email Layouts:
Email layouts define the structural wrapper (header, footer, styling) around the notification content. They ensure consistent branding across all outgoing emails.

Mail Scripts:
Mail scripts allow dynamic content generation within notifications. They run server-side and have access to the current record, event object, email object, and template object.

Notification Preferences:
Users can subscribe to or unsubscribe from certain notifications through their notification preferences, unless the notification is marked as non-subscribable (the Subscribable checkbox is unchecked).

Weight:
When multiple notifications could fire for the same event or record change and the same recipient, ServiceNow uses the weight field to determine which notification to send. The notification with the highest weight wins, preventing duplicate emails.

How to Answer Exam Questions on Events and Notifications

The CAD exam will test your understanding of the relationship between events and notifications, configuration options, and best practices. Here is how to approach different question types:

Scenario-based questions: You may be given a scenario where a notification needs to be sent when a specific condition is met. Determine whether the question is asking about event-based or record-based triggers. If the scenario mentions firing an event via script, look for answers referencing gs.eventQueue() and the Event Registry.

Configuration questions: Know the three tabs of a notification record — When to send, Who will receive, and What it will contain. Questions may ask which tab controls a specific behavior.

Scripting questions: Understand the syntax of gs.eventQueue(), including the order and purpose of its parameters. Know that parm1 is commonly used to pass the recipient's sys_id and parm2 for additional context.

Exam Tips: Answering Questions on Events and Notifications

1. Remember the decoupling principle: Events decouple the trigger from the action. If an exam question asks for the best practice approach to sending notifications, the answer almost always involves using events rather than direct record-based notifications.

2. Know gs.eventQueue() parameters: The function takes four parameters — event name (string), GlideRecord (current), parm1 (string), and parm2 (string). parm1 is frequently used to specify the intended email recipient. This is a commonly tested concept.

3. Event Registry is required: An event must be registered in the Event Registry before it can be used. If a question describes an event that is not firing, check whether the event has been registered.

4. Distinguish between event-based and record-based notifications: If the Send when field is set to Event is fired, it is event-based. If set to Record inserted or updated, it is record-based. The exam may test whether you can identify which type is being used.

5. Understand notification weight: If two notifications could fire for the same recipient on the same record, the one with the higher weight is sent. This prevents duplicate emails. This is a frequently tested concept on the CAD exam.

6. Mail scripts vs. template variables: Template variables (${field_name}) are used for simple field value insertion. Mail scripts are used when logic or conditional content is needed. Know when to use each.

7. Subscribable notifications: By default, notifications are subscribable, meaning users can opt out. If the exam asks how to ensure a notification is always sent regardless of user preferences, the answer is to uncheck the Subscribable checkbox.

8. Debugging notifications: The sys_email table stores all outgoing emails. The sysevent table stores all generated events. If a question asks how to troubleshoot why a notification was not sent, check these tables and also the email log.

9. Email Digest: Know that digests consolidate multiple notifications into a single email at a configured interval. If a question mentions reducing email volume, digest is likely the answer.

10. Watch for trick answers: The exam may include options that reference client-side scripting for events. Remember that events and notifications are entirely server-side processes. Any answer suggesting client scripts trigger events is incorrect.

By mastering these concepts and practicing with scenario-based questions, you will be well-prepared to answer any CAD exam question related to Events and Notifications in ServiceNow.