sys_notification Table

Table Reference/sys_notification

The sys_notification table stores email notification configuration records in the Platform module. These records define when and how notifications are sent based on events. The key thing developers need to know: notifications fire based on complex condition logic that evaluates against the triggering record's data.

What This Table Is

The sys_notification table stores email notification configuration records that define when and how ServiceNow sends automated emails. Each record represents a single notification rule that triggers based on specific events (insert, update, delete) on designated tables. These notifications form the backbone of ServiceNow's communication system, alerting users when records change, approvals are needed, or business processes require attention.

This table belongs to the Platform module and supports the core notification engine that runs across all ServiceNow applications. When a record changes on any table, the notification engine evaluates active notification records to determine which emails to send. The system processes these in near real-time, though complex condition scripts can impact performance at scale.

The sys_notification table extends the base sys_metadata table, inheriting standard metadata fields like sys_scope and sys_package. No tables extend this one directly, but notification devices (sysevent_email_action) reference these records to determine recipient lists and message content.

Large enterprises typically maintain 200-500 active notification records, though poorly designed condition scripts can create performance bottlenecks. Each active notification evaluates against every qualifying record change, so complex JavaScript conditions multiply processing overhead. The system maintains an internal cache of active notifications, but changes to notification records require cache refresh across all nodes.

When You'll Script Against This Table

You'll primarily script against sys_notification in Business Rules that need to dynamically enable or disable notifications, Script Includes that manage notification lifecycle, and Scheduled Jobs that audit notification effectiveness. Administrative scripts often query this table to identify notifications that haven't triggered recently or have problematic condition logic.

Access requires the admin role for write operations, though users with notification_admin can modify notification records. Read access varies by scope - global notifications are visible to most developers, but scoped application notifications require appropriate role access. Background scripts run with elevated permissions but should validate scope boundaries when modifying notification records.

Bulk enable/disable notifications during maintenance windows or data migrations
Clone notification templates when creating new applications or processes
Audit which notifications target specific user groups or conditions
Dynamically adjust notification conditions based on business rules or configuration
Validate notification performance by analyzing condition complexity and target tables
Import/export notification configurations between instances during deployments
Create conditional notification logic that responds to environmental factors or business calendars

Table Gotchas

⚠️

The condition field stores JavaScript that executes for every qualifying record change. Complex conditions or database queries in notification conditions can severely impact instance performance during bulk operations.

⚠️

Notifications trigger based on the table field value, but inheritance means a notification on 'task' will evaluate for incident, problem, and change records unless explicitly filtered by sys_class_name.

The when field accepts 'insert', 'update', 'delete', 'query' but 'query' notifications are deprecated and should be avoided
The filter field uses encoded query syntax but doesn't validate field existence - invalid filters fail silently

⚠️

Setting active=false doesn't immediately stop notification processing - the system caches active notifications and may take several minutes to recognize the change across all application nodes.

The sys_domain field controls domain separation but notifications can still trigger across domains if condition logic explicitly queries global data
The order field determines execution sequence but only matters when multiple notifications have identical conditions - most notifications should use order 100

⚠️

Notification conditions execute in a separate JavaScript scope from Business Rules - current.getValue() behaves differently and some GlideRecord operations may not work as expected.

Free Newsletter

Enjoying this? Get one deep-dive per week.

Join 1,000+ ServiceNow pros — scripts, GlideRecord patterns, Flow Designer techniques, and career moves. Free.

The sys_notification table extends sys_metadata, inheriting scope and package management capabilities essential for application lifecycle management. When cloning or migrating applications, notification records follow the same scope rules as other metadata objects, requiring careful attention to cross-scope references in condition scripts.

The sysevent_email_action table stores the actual email device configurations that notifications reference, defining recipient logic and message templates. The sysevent table logs notification firing events for debugging and audit purposes. When troubleshooting notification delivery, developers commonly join these three tables to trace the complete notification lifecycle from trigger to delivery.

The sys_dictionary table becomes critical when building notifications that reference specific fields, as notification conditions often need to validate field existence and attributes before firing. The sys_user_group and sys_user tables frequently appear in notification condition scripts that need to determine recipient eligibility based on group membership, roles, or user attributes.

Chrome Extension

Sourdough: ServiceNow Monitoring and Analytics

A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.

Instance HealthGraphs & ChartsAPI HealthDeveloper ToolsQuick SearchInstance Switcher

Add to Chrome

Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.

Overview

Tasks

CMDB

API

Metrics

Monitor

Internals

Instance:sourdoughdev·Version:Yokohama

Instance StateONLINE

System StatusFully Operational

Session Timeout90 minutes

Logged-In Sessions2 (20 active)

Build Nameyokohama-12-18-2024_p1

IP Address10.159.128.43

Instance HealthHealth Score: 90%

🔥 5dSourdough (Chrome Plugin)Dark Mode

Key Fields

Column	Type	Label	Notes
name	string	Name	Human-readable notification identifier. Must be unique within scope and commonly follows naming convention like 'Incident Assignment Notification'.
table	string	Table	Target table name where records changes trigger this notification. Uses actual table name like 'incident' not display name, and applies to child tables via inheritance.
when	choice	When to Send	Trigger event type: 'insert', 'update', 'delete'. Multiple values stored comma-separated but 'query' option is deprecated and should be avoided.
filter	conditions	Condition	Encoded query string defining when notification should fire. Uses same syntax as list filters but doesn't validate field existence - invalid filters fail silently.
condition	script_plain	Advanced Condition	JavaScript condition evaluated against current record. Executes in separate scope from Business Rules with limited GlideRecord functionality and different current.getValue() behavior.
active	boolean	Active	Controls whether notification processes record changes. Cache delays mean setting to false doesn't immediately stop processing across all application nodes.
order	integer	Order	Execution sequence when multiple notifications have identical conditions. Lower numbers execute first but most notifications should use standard value of 100.
category	string	Category	Organizational grouping for notifications like 'workflow' or 'approval'. Used primarily for administrative organization and reporting.
collection	string	Collection	Alternative name for table field, maintained for backward compatibility. Modern notifications should use table field instead.
weight	integer	Weight	Priority factor affecting notification processing order. Higher weights indicate higher priority but rarely used in practice.
message	string	Message HTML	Direct HTML message content for notifications not using separate email templates. Supports variable substitution using ${field_name} syntax.
subject	string	Subject	Email subject line supporting variable substitution. Commonly uses ${number} or ${short_description} to identify the triggering record.
recipients	string	Recipients	Comma-separated list of email addresses or user sys_ids for direct notification delivery. Most notifications use email devices instead for dynamic recipient logic.
description	string	Description	Documentation field explaining notification purpose and business logic. Critical for maintenance as condition logic can be complex and non-obvious.
sys_domain	domain_id	Domain	Domain separation identifier restricting notification visibility and execution. Global domain notifications (empty value) are visible across all domains.
force_delivery	boolean	Force delivery	Bypasses user notification preferences and subscription settings to guarantee delivery. Use sparingly as it overrides user privacy controls.
notification_filter	choice	User notification filter	Defines which users receive notifications based on relationship to record: 'event.parm1', 'affected_user', 'caller', or custom field references.
digest	choice	Digest	Groups multiple notifications into summary emails: 'never', 'daily', 'weekly'. Reduces email volume but delays notification delivery.
mandatory	boolean	Mandatory	Prevents users from unsubscribing from this notification type. Reserved for critical business notifications like security alerts or compliance requirements.

Common Queries

Get all active notifications

// Most basic query - what every developer tries first
var gr = new GlideRecord('sys_notification');
gr.addQuery('active', true);
gr.orderBy('name');
gr.query();
while (gr.next()) {
    gs.info('Active notification: ' + gr.name + ' on table: ' + gr.table);
}

Find active incident notifications with specific conditions

// Filter by table and active status - common troubleshooting pattern
var gr = new GlideRecord('sys_notification');
gr.addQuery('active', true);
gr.addQuery('table', 'incident');
gr.addQuery('when', 'CONTAINS', 'update'); // Notifications that fire on updates
gr.query();
while (gr.next()) {
    gs.info('Incident update notification: ' + gr.name);
    gs.info('Condition: ' + gr.filter);
}

Audit notifications targeting assignment group changes

// Real-world scenario - find notifications that fire on assignment changes
var gr = new GlideRecord('sys_notification');
gr.addQuery('active', true);
gr.addQuery('filter', 'CONTAINS', 'assignment_group'); // Basic filter check
gr.addQuery('when', 'CONTAINS', 'update');
gr.query();
while (gr.next()) {
    // Also check advanced condition for assignment group references
    if (gr.condition.indexOf('assignment_group') > -1) {
        gs.info('Assignment notification: ' + gr.name + ' on ' + gr.table);
    }
}

Count active notifications by target table

// Aggregate query to identify tables with most notification overhead
var ga = new GlideAggregate('sys_notification');
ga.addQuery('active', true);
ga.addAggregate('COUNT');
ga.groupBy('table');
ga.orderByAggregate('COUNT');
ga.query();
while (ga.next()) {
    var table = ga.table.toString();
    var count = ga.getAggregate('COUNT');
    gs.info('Table: ' + table + ' has ' + count + ' active notifications');
}

Query gotcha - avoid current object references in condition

// WRONG: This breaks because 'current' context differs in notifications
// var gr = new GlideRecord('sys_notification');
// gr.addQuery('condition', 'CONTAINS', 'current.assignment_group.changes()');

// RIGHT: Query the actual condition text and validate syntax
var gr = new GlideRecord('sys_notification');
gr.addQuery('active', true);
gr.addQuery('condition', '!=', ''); // Has advanced condition
gr.query();
while (gr.next()) {
    // Check for potentially problematic condition patterns
    if (gr.condition.indexOf('GlideRecord') > -1) {
        gs.warn('Notification with GlideRecord in condition: ' + gr.name);
    }
}

Test Your Knowledge

Quick 3-question quiz — see how your ServiceNow skills stack up.

Question 1 of 3Performance

A list view on a table with millions of records is slow. Best fix?

Select an answer to continue

sys_notification