Notification

What It Is

Notifications are ServiceNow's automated messaging system that sends emails, SMS messages, or push alerts based on record changes, scheduled events, or specific conditions. They solve the fundamental business problem of keeping stakeholders informed about critical process changes without requiring manual intervention. When an incident escalates, a change approval is needed, or a request gets fulfilled, notifications ensure the right people know immediately rather than discovering issues hours or days later through manual checking.

Architecturally, notifications live in the System Notification application as part of ServiceNow's core platform services. They operate at the business logic layer, sitting between the data model and the user interface, triggered by business rules, workflows, or scheduled jobs. The notification engine integrates with the email subsystem (sys_email table), SMS providers, and mobile push notification services to deliver messages across multiple channels.

The notification framework builds on ServiceNow's event-driven architecture, where record operations (insert, update, delete) can trigger notifications through conditions evaluated in real-time. Each notification record defines a specific table to monitor, conditions that must be met, recipient targeting rules, and the message template to use. The system supports both immediate notifications fired by business rules and scheduled notifications triggered by recurring jobs or escalation timers.

You cannot function without notifications in several critical scenarios: incident management workflows where assignment groups need immediate alerts about high-priority issues, change management processes requiring approval notifications to CAB members, HR service delivery where managers must approve employee requests, and SLA breach warnings that prevent missed commitments. Any process that depends on timely human intervention or stakeholder awareness requires robust notification configuration to meet business objectives and regulatory requirements.

Platform administrators typically own notification configuration and troubleshooting, while application developers create custom notification templates and advanced recipient scripts for complex business logic. Business analysts often define the notification requirements and approval workflows, but admins translate these into working configurations. The relationship requires ongoing collaboration because notification effectiveness depends on accurate recipient targeting, properly formatted templates, and reliable delivery infrastructure that spans multiple technical domains.

Recent ServiceNow releases have enhanced notification capabilities significantly. Vancouver introduced improved mobile push notification support and better template variable handling. Xanadu added enhanced SMS provider integration and more granular notification preferences for end users. The notification engine also received performance improvements for high-volume environments and better debugging tools in the Email Logs and Event Log modules for tracking delivery issues and performance bottlenecks.

Where to Find and Configure It

Navigate to System Notification > Email > Notifications for the primary notification configuration interface where you create, edit, and manage all notification records. Access notification templates at System Notification > Email > Notification Email Templates to design the actual message content and formatting. Check System Notification > Email > Notification Device Variables to configure SMS and mobile push notification settings for multi-channel delivery.

In Application Studio or classic development, find notification configurations under Platform Features > Notification when building custom applications. Monitor notification activity through System Logs > Email Logs to troubleshoot delivery issues and verify message sending. View notification devices and user preferences at User Administration > Notification Devices to manage how different users receive alerts across email, SMS, and push channels.

Global application notifications apply across all scoped applications and appear in the main notification list, while scoped application notifications only trigger for records within that specific application scope. Access scoped notifications through Studio > [Application] > Notification or the application's dedicated notification module. Configure notification preferences and testing through System Properties > Notification to control system-wide behavior like email formatting, retry logic, and delivery throttling.

How It Works Step by Step

The notification engine operates through a multi-stage pipeline that evaluates conditions, identifies recipients, and delivers messages across configured channels. When a record operation occurs (insert, update, delete), the system checks all active notifications configured for that table and evaluates their conditions against the current and previous record values. This condition evaluation happens during the business rule execution phase, allowing notifications to access both the current record state and any changes made by prior business rules or workflows.

Once conditions are met, the notification engine processes recipient targeting through user queries, group membership lookups, or custom recipient scripts that can perform complex logic to determine who should receive the alert. The engine then merges the notification template with record data to generate personalized message content, replacing template variables with actual field values and executing any embedded scripts for dynamic content generation. Finally, the system queues messages for delivery through the appropriate channels (email, SMS, push), respecting user notification preferences and delivery scheduling rules.

The notification system includes sophisticated caching and fallback mechanisms to handle high-volume scenarios and delivery failures. User preference caching reduces database queries for recipient lookups, while template caching improves message generation performance. If primary delivery channels fail (email server down, SMS provider unavailable), the system can fall back to alternative channels based on user device configurations and notification priorities defined in the notification record.

The Execution Order

1. Record operation triggers business rule execution phase
2. System queries all active notifications for the target table
3. Notification conditions evaluate against current record and previous values
4. Recipient targeting executes through user queries, groups, or recipient scripts
5. Template processing merges record data with notification template content
6. User notification preferences determine delivery channels and timing
7. Messages queue for delivery through email, SMS, or push notification services
8. Delivery status and errors log to email and event logs for monitoring

// Common notification condition script for priority escalation
// Triggers when incident priority changes to High or Critical

var triggerNotification = false;

// Check if priority field changed
if (current.priority.changes()) {
    var newPriority = parseInt(current.priority);
    var oldPriority = parseInt(previous.priority);
    
    // Priority 1 = Critical, 2 = High, 3 = Moderate, 4 = Low
    // Trigger if escalated to High (2) or Critical (1)
    if (newPriority <= 2 && oldPriority > 2) {
        triggerNotification = true;
    }
}

// Additional check for new high priority incidents
if (current.isNewRecord() && parseInt(current.priority) <= 2) {
    triggerNotification = true;
}

triggerNotification;

Real-World Scenarios

Critical Incident Escalation to Management

Business requirement: When any incident reaches Priority 1 (Critical) or has been Priority 2 (High) for more than 2 hours, automatically notify the IT manager and on-call director via email and SMS for immediate attention. The notification must include incident details, business impact, and direct links to the incident record for rapid response.

Create a notification with Table: incident, When to send: Created or Updated. Set condition to priority=1^ORpriority=2^sys_updated_on<=javascript:gs.daysAgoEnd(-0.083) (0.083 days = 2 hours). Configure recipients as Groups: IT Management, On-Call Directors. Enable both email and SMS delivery channels. Create a template with subject URGENT: Critical Incident ${number} - ${short_description} and include business impact, assigned team, and incident URL using ${URI_REF} template variable.

Watch for notification storms when incidents update frequently during resolution - add a condition like state!=6 (not resolved) to prevent notifications after closure. Ensure user notification preferences allow SMS delivery for management users, and verify that the SMS provider configuration is active. The time-based condition requires careful testing because it evaluates against the sys_updated_on field, which changes with every update - use a separate escalation timer business rule for more precise control.

Change Approval Request with Custom Recipients

Business requirement: When a normal change request requires approval, send notifications to different approval groups based on the affected CI category - server changes go to Server Team leads, network changes to Network CAB, and application changes to both Development managers and the CI owner. Recipients must receive formatted emails with change details, risk assessment, and approval action links.

// Advanced recipient script for change approval notifications
// Dynamically assigns approvers based on affected CI categories

var recipients = [];
var affectedCIs = current.cmdb_ci.toString();

// Query affected CIs and categorize
var ciGR = new GlideRecord('cmdb_ci');
if (ciGR.get(affectedCIs)) {
    var ciClass = ciGR.sys_class_name.toString();
    
    if (ciClass.indexOf('cmdb_ci_server') === 0) {
        // Server changes - notify Server Team leads
        recipients.push('server_leads@company.com');
    } else if (ciClass.indexOf('cmdb_ci_netgear') === 0) {
        // Network changes - notify Network CAB
        recipients.push('network_cab@company.com');
    } else if (ciClass.indexOf('cmdb_ci_appl') === 0) {
        // Application changes - notify Dev managers and CI owner
        recipients.push('dev_managers@company.com');
        if (ciGR.owned_by.email) {
            recipients.push(ciGR.owned_by.email.toString());
        }
    }
}

return recipients.join(',');

Configure the notification with Table: change_request, condition type=normal^approval=requested, and set Recipients: Advanced recipient script using the code above. Create an email template with approval action buttons using ${mail.approval_links} for one-click approval/rejection. Performance issues can arise with complex CI queries in the recipient script - consider caching CI category lookups or using a separate business rule to populate a custom field with approver group references for faster notification processing.

SLA Breach Warning with Escalating Frequency

Business requirement: Send progressive warning notifications as incidents approach SLA breach - first warning at 80% of SLA time remaining, second at 95%, and final warning at 100% with different urgency levels and recipient escalation. Each warning should include time remaining, breach impact, and escalation path to prevent SLA violations that affect customer satisfaction metrics.

Create three separate notifications for each escalation level: Notification 1 with condition task_sla.percentage>=80^task_sla.percentage<95 targeting assigned user and team lead. Notification 2 with task_sla.percentage>=95^task_sla.percentage<100 adding IT manager to recipients. Notification 3 with task_sla.percentage>=100 including director-level contacts and SMS delivery. Each template should calculate remaining time using ${task_sla.planned_end_time} and current timestamp for precise breach timing.

SLA-based notifications are highly sensitive to timing and can trigger multiple times if not properly configured. Add Send reschedule: true with appropriate intervals to prevent notification flooding during SLA updates. Monitor the task_sla table directly rather than joining through incidents to avoid performance issues. Consider using workflow activities or scheduled jobs for more precise SLA monitoring rather than update-triggered notifications, especially in high-volume environments where SLA calculations may lag behind actual breach timing.

The Classic Mistake

// BAD: Using current object directly in notification condition
// This runs BEFORE the business rule commits
function evaluateCondition() {
    // This will often return stale data
    var user = new GlideRecord('sys_user');
    user.get(current.assigned_to);
    
    // current.state might not reflect the actual database value yet
    if (current.state == '2' && user.department == 'IT') {
        return true;
    }
    
    // This check fails because current.sys_updated_on
    // reflects the in-memory object, not committed data
    var lastUpdate = new GlideDateTime(current.sys_updated_on);
    var now = new GlideDateTime();
    var diff = gs.dateDiff(lastUpdate.getDisplayValue(), now.getDisplayValue(), true);
    return diff < 3600; // Less than 1 hour
}

This fails because notifications triggered by Business Rules execute in the same database transaction context, meaning the current object represents the in-memory state before commit, not the actual database state. Users report notifications not firing when they should, or firing with outdated field values. ServiceNow internally queues the notification evaluation during the Business Rule execution, but the condition script runs with potentially stale or uncommitted data. The symptom is particularly confusing because the notification appears correctly configured and the trigger conditions seem met when viewing the record afterward.

// GOOD: Query the database directly for current state
function evaluateCondition() {
    // Always query the database for authoritative data
    var incident = new GlideRecord('incident');
    if (!incident.get(current.sys_id)) {
        return false;
    }
    
    var user = new GlideRecord('sys_user');
    user.get(incident.assigned_to);
    
    // Use the database record, not the current object
    if (incident.state == '2' && user.department == 'IT') {
        return true;
    }
    
    // Database sys_updated_on is always accurate
    var lastUpdate = new GlideDateTime(incident.sys_updated_on);
    var now = new GlideDateTime();
    var diff = gs.dateDiff(lastUpdate.getDisplayValue(), now.getDisplayValue(), true);
    return diff < 3600;
}

When to Use This vs Alternatives

Notifications are the right choice for time-sensitive, event-driven communications that need to reach users outside the ServiceNow interface. Use them when you need guaranteed delivery tracking, template-based formatting, and integration with external email systems or mobile push notifications.

When Notifications are the Correct Choice

Choose notifications for approval requests, SLA breach warnings, and incident escalations where users must be informed immediately regardless of whether they're logged into ServiceNow. Business Rules and Script Actions can't deliver content outside the platform, and Flow Designer's email actions lack the template sophistication and delivery tracking that enterprise email communications require. Notifications also provide automatic retry logic and delivery status tracking that custom solutions would need to replicate.

When to Use Flow Designer Instead

Use Flow Designer for complex multi-step processes that include email as one component, especially when you need conditional branching, wait timers, or integration with external systems before sending communications. Flow Designer's email actions are sufficient for simple internal notifications and provide better visibility into the overall process execution. Notifications become unwieldy when you need different email content based on complex business logic or when the email is part of a larger orchestrated workflow.

When to Use Both Together

Combine notifications with Business Rules for immediate alerts triggered by database changes, while using Flow Designer for follow-up communications or escalations with timing delays. For example, use a notification for instant incident assignment alerts, then trigger a Flow that waits 4 hours and sends escalation emails if the incident remains unresolved. This approach leverages notifications' real-time efficiency and Flow Designer's sophisticated timing and conditional logic.

Platform Interactions & Side Effects

• Creates records in sys_email table for every sent notification, including delivery status, retry attempts, and failure reasons
• Business Rules with async=false can delay notification processing until transaction commit, causing apparent delivery delays
• ACLs on the source table affect notification condition evaluation - if the notification runs as a user without read access, conditions fail silently
• Update Sets capture notification records but not the sys_email_account configurations, breaking SMTP delivery in target instances
• Session impersonation affects notification recipient calculation when using gs.getUserID() in advanced recipient scripts
• The glide.email.send.enabled system property globally disables all email delivery while still creating sys_email records with 'Ignored' state
• Scheduled Jobs process the Events Queue Processor - if this job is stuck or disabled, event-triggered notifications queue indefinitely in sysevent table
• Attachment access in email templates is limited by the notification's security context, not the recipient's permissions
• Database transactions that fail after notification triggering will still send emails, creating inconsistent user experience with 'phantom' notifications
• Performance impact occurs when notifications with complex recipient scripts query large user tables during high-volume record processing

Debugging and Troubleshooting

The most common failure symptom is notifications that simply don't send, with users reporting they never received expected emails while the triggering record shows the correct state changes. Admins typically see empty results when searching the sys_email table, indicating the notification never executed rather than failing during delivery. Less obvious is when notifications send with incorrect or missing content, often caused by template variable evaluation errors or recipient script failures that fail silently.

Start debugging in System Logs > System Log > All filtered by source 'notification' to see condition evaluation and template processing errors. Check System Definition > Events to verify the triggering event fired, then examine sysevent table for queued but unprocessed events. The System Mailboxes > Outbound > Email Logs shows delivery attempts and SMTP-level failures with specific error codes.

Key error messages include 'Condition script failed' in system logs when JavaScript syntax errors occur, 'No recipients found' when recipient scripts return empty results, and 'Template processing failed' when email template variables reference non-existent fields or null objects. SMTP errors appear as 'Connection refused' for network issues or 'Authentication failed' for credential problems. The notification preview feature in the notification form provides immediate feedback for template variable resolution and recipient calculation without sending actual emails.

Diagnostic Checklist:

• Verify glide.email.send.enabled=true in System Properties
• Check if notification's Active checkbox is selected and Table field matches the triggering record type
• Test the condition script in Scripts - Background with a real record sys_id
• Use the notification's Preview button to validate recipient calculation and template rendering
• Query sysevent table for events with State=Ready that haven't been processed
• Confirm Events Queue Processor scheduled job is active and running successfully
• Validate SMTP configuration in System Mailboxes > Administration by sending a test email

Quick Reference

• Maximum email size limit is 25MB including attachments, enforced by glide.email.max_size system property
• Notifications triggered by Import Sets ignore the Send to event creator option and always use system context
• The ${mail_script:} template variable executes server-side JavaScript and can access any ServiceNow API
• Notification conditions run with 'maint' user privileges when triggered by system processes like scheduled jobs
• Email templates support both Jelly and Angular-style ${field_name} syntax but process them differently for escaping
• Push notifications to mobile apps require the Device Type field set to 'Push Notification' and active mobile app registration
• Notification digest functionality groups multiple events into single emails based on recipient and configurable time windows
• The sys_email table retains sent email records for 90 days by default, controlled by cleanup job settings
• Clone operations on tables with notifications require manual reactivation of cloned notification records
• Advanced recipient scripts can return User, Group, or Email Address records but must populate the correct recipient type field