Event-Driven Architecture Pattern in…

advancedTested on Xanadu

The Event-Driven Architecture pattern in ServiceNow uses the platform's built-in event system to decouple business logic components and enable asynchronous processing. Instead of tightly coupling business rules to direct synchronous operations, this pattern publishes events when certain conditions occur and allows multiple independent subscribers to react appropriately.

This pattern solves the problem of monolithic business rules that become difficult to maintain and can cause performance issues when multiple complex operations need to occur on record changes. By using gs.eventQueue() to publish events from business rules and script actions to subscribe and process them asynchronously, you create a more maintainable and scalable architecture.

The pattern works by having lightweight business rules that focus solely on detecting when events should occur, publishing those events to ServiceNow's event queue, and then having dedicated script actions that execute the actual business logic. This creates clear separation of concerns and allows for better error handling, logging, and monitoring of each processing step.

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

Use This When

Use this pattern when you have complex business processes that involve multiple systems, lengthy operations that could impact user experience, or when you need to integrate multiple loosely-coupled components that shouldn't directly depend on each other. It's particularly valuable when building scalable solutions that need to handle high transaction volumes or when you want to improve maintainability by separating detection logic from processing logic.

Avoid When

Avoid this pattern for simple, fast operations that complete in under a second and don't require integration with external systems, as the event overhead adds unnecessary complexity. Don't use it when you need immediate synchronous feedback to the user or when the business process requires strict transactional consistency where all operations must succeed or fail together within the same database transaction.

Implementation

Server-side

// Business Rule: Incident State Change Publisher
// Table: incident, When: after, Insert: false, Update: true
// Condition: gs.isInteractive() && current.state.changes()

(function executeRule(current, previous) {
    var eventName = 'incident.state.changed';
    var eventParms = {
        'incident_sys_id': current.sys_id.toString(),
        'old_state': previous.state.toString(),
        'new_state': current.state.toString(),
        'caller_id': current.caller_id.toString(),
        'priority': current.priority.toString()
    };
    
    gs.info('Publishing event: ' + eventName + ' for incident ' + current.number);
    gs.eventQueue(eventName, current, gs.getUserID(), JSON.stringify(eventParms));
    
})(current, previous);

// Script Action: Incident State Change Handler
// Name: IncidentStateChangeHandler
// Event name: incident.state.changed

(function() {
    try {
        var eventParms = JSON.parse(event.parm1 || '{}');
        var incidentId = eventParms.incident_sys_id;
        var oldState = eventParms.old_state;
        var newState = eventParms.new_state;
        
        gs.info('Processing incident state change event for: ' + incidentId);
        
        // Handle resolved state
        if (newState == '6') { // Resolved
            handleIncidentResolution(incidentId, eventParms);
        }
        
        // Handle closed state
        if (newState == '7') { // Closed
            handleIncidentClosure(incidentId, eventParms);
        }
        
        // Send notifications asynchronously
        sendStateChangeNotification(incidentId, oldState, newState);
        
    } catch (error) {
        gs.error('Error processing incident state change event: ' + error.message);
        gs.error('Event details: ' + JSON.stringify(event));
    }
    
    function handleIncidentResolution(incidentId, parms) {
        var gr = new GlideRecord('incident');
        if (gr.get(incidentId)) {
            gr.resolved_at = new GlideDateTime();
            gr.resolved_by = gs.getUserID();
            gr.update();
            
            // Trigger customer satisfaction survey
            gs.eventQueue('incident.satisfaction.survey', gr, gs.getUserID());
            gs.info('Resolution processing completed for incident: ' + gr.number);
        }
    }
    
    function handleIncidentClosure(incidentId, parms) {
        // Update related problem records
        var problemGr = new GlideRecord('problem');
        problemGr.addQuery('related_incidents', 'CONTAINS', incidentId);
        problemGr.query();
        
        while (problemGr.next()) {
            gs.eventQueue('problem.incident.closed', problemGr, gs.getUserID(), incidentId);
        }
    }
    
    function sendStateChangeNotification(incidentId, oldState, newState) {
        var notificationEvent = 'incident.state.notification';
        var notificationParms = {
            'incident_id': incidentId,
            'state_transition': oldState + '_to_' + newState
        };
        gs.eventQueue(notificationEvent, null, gs.getUserID(), JSON.stringify(notificationParms));
    }
    
})();

The code demonstrates a complete event-driven workflow where a business rule publishes lightweight events when incident states change, and a script action asynchronously processes the complex business logic. The business rule focuses only on detecting changes and publishing relevant data, while the script action handles multiple downstream operations like updating timestamps, triggering surveys, and cascading to related records, all while maintaining proper error handling and logging.

Alternatives

Direct Business Rule Processing

Simpler to implement and debug with immediate execution, but creates tightly coupled code that can cause performance issues and is harder to maintain when business logic becomes complex across multiple systems.

Scheduled Job Polling

Better for batch processing large volumes of records and provides more control over execution timing, but introduces latency since changes aren't processed immediately and requires more complex state tracking mechanisms.

Flow Designer Workflows

Provides visual workflow design with built-in error handling and is more accessible to non-developers, but has less flexibility for complex scripting scenarios and can be more resource-intensive for high-volume operations.

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