Event

What It Is

An Event in ServiceNow is a platform-generated message that triggers asynchronous processing of notifications, event rules, and script actions. Unlike generic IT events (server alerts, application errors, monitoring signals), ServiceNow Events are internal platform constructs designed specifically for workflow automation and inter-system communication. When code executes gs.eventQueue('incident.created', current), it creates an Event record in the sysevent table that gets processed by background schedulers, not the current transaction thread. This architectural decision allows ServiceNow to handle expensive operations like email generation, web service calls, and complex business logic without blocking user interactions or causing transaction timeouts.

Events sit in the platform's messaging layer, bridging synchronous business rule execution with asynchronous background processing. They're the mechanism that allows a simple incident creation to spawn dozens of related activities—notifications to multiple stakeholders, updates to external systems, automated task assignments, and metric calculations—without making the original user wait. The Event system essentially provides guaranteed delivery of work items to background processors, with built-in retry logic and error handling that synchronous code execution cannot offer.

From a business operations perspective, Events solve the fundamental problem of scalable, reliable automation in enterprise ITSM environments. When a P1 incident gets created at 2 AM, the platform needs to immediately notify on-call engineers, update external monitoring systems, create bridge conference lines, and trigger escalation timers—all while ensuring the person reporting the incident isn't waiting for these processes to complete. Events make this possible by queuing these work items for background execution, ensuring they happen reliably even if individual notification servers are temporarily unavailable or external systems are slow to respond.

ServiceNow designed Events this way because early versions of the platform struggled with notification performance and reliability. Before the robust Event system emerged, notifications were processed synchronously within business rule transactions, causing frequent timeouts when SMTP servers were slow or when complex notification logic needed to run. The asynchronous Event model, refined over many releases, provides the reliability and performance characteristics that enterprise customers demand. Alternative approaches like immediate synchronous processing or simple background job queues lack the sophisticated event matching, parameter passing, and retry mechanisms that the Event system provides.

Developers interact with Events primarily through gs.eventQueue() calls in business rules and script includes, while administrators configure Event Rules and Notifications that respond to these events. System administrators monitor event processing through the Event Log and tune event processing performance. End users rarely interact with Events directly, but they experience their effects through notifications, automated task assignments, and system integrations. Process owners rely on Events to ensure business rules execute reliably without impacting user experience, making them critical for service level compliance and operational efficiency.

Without Events, ServiceNow would revert to synchronous processing for all automation, creating a cascade of performance and reliability issues. Notifications would timeout regularly, causing users to wait indefinitely for forms to save. Integration failures would block business processes instead of being retried in the background. Complex approval workflows would grind to a halt when external systems experienced latency. The platform would lose its ability to guarantee that important business logic executes eventually, even when individual components are temporarily unavailable. This architectural foundation is so critical that major enterprise features like Service Mapping, Discovery, and Orchestration all depend on Events for reliable background processing.

Where It Fits in the Platform

Events occupy a central position in ServiceNow's processing architecture, functioning as the primary interface between the synchronous transaction layer where business rules execute and the asynchronous background processing layer where notifications, integrations, and heavy computational work happen. They're created during active user sessions but processed by dedicated background threads called event processors, which run independently of user interactions and can retry failed operations without impacting system responsiveness.

The Event system integrates deeply with ServiceNow's notification infrastructure, workflow engine, and integration capabilities. When business rules determine that notifications need to be sent or external systems need updates, they queue Events rather than performing these operations directly. This architectural pattern ensures that user-facing operations complete quickly while background processes handle the complex, time-consuming work that supports business operations. Events also provide the foundation for ServiceNow's event-driven architecture patterns, enabling loose coupling between different platform components and custom applications.

Key Relationships:

• Business Rule — Business rules create Events using gs.eventQueue() to trigger asynchronous processing without blocking the current transaction.
• GlideSystem — The gs.eventQueue() method is the primary interface for creating Events, accepting event names, record references, and parameter objects.
• Notifications — Events trigger notification processing through event-notification matching, with notifications subscribing to specific event names and conditions.
• Event Rules — Custom server-side scripts that execute when specific Events are processed, providing a way to implement complex business logic asynchronously.
• Script Actions — Reusable code modules that can be triggered by Events, allowing for standardized processing logic across multiple event types.
• MID Server — Events can trigger outbound integrations that are processed by MID Servers, enabling reliable communication with external systems even when network connectivity is intermittent.

How You Encounter This in Practice

Debugging Missing Notifications

You're a ServiceNow administrator and users are reporting that they're not receiving email notifications when incidents are assigned to them, even though the notification configuration looks correct. You check the Email Logs and find no record of emails being sent, but you can see in the business rule logs that assignment business rules are executing. The missing piece becomes clear when you examine the Events [sysevent] table and discover that no events are being created for incident assignments.

Understanding Events reveals that notifications don't fire directly from business rules—they require Events to be queued first. This knowledge leads you to check whether the assignment business rule contains the proper gs.eventQueue() call, or whether a customization has accidentally removed the out-of-box event generation. You can then trace the complete flow: business rule creates Event, Event triggers notification processing, notification generates email.

Someone without this understanding would focus exclusively on notification configuration, spending hours adjusting recipients, conditions, and email templates while never addressing the root cause. They might create duplicate notifications or resort to synchronous email sending from business rules, introducing performance problems and reliability issues that the Event system was designed to prevent.

Building Reliable Integration Workflows

You're a ServiceNow developer tasked with integrating incident creation with an external CMDB system that needs to be updated whenever configuration items are added or modified. Your first implementation uses REST calls directly in business rules, but you quickly discover that when the external system is slow or temporarily unavailable, users experience form save timeouts and sometimes changes aren't synchronized at all. Testing reveals that under load, the synchronous integration calls cause transaction rollbacks that lose both the ServiceNow updates and the external system updates.

Understanding Events shows you the proper integration pattern: business rules queue Events with the CI data, Event Rules process these Events in background threads to make external API calls, and the built-in retry mechanism handles temporary failures. This architectural approach ensures that user interactions complete quickly while external integrations happen reliably in the background, with proper error handling and retry logic built into the platform.

A developer without this knowledge would continue trying to solve integration reliability through synchronous methods—adding timeouts, error handling, and transaction management to business rules. This approach inevitably leads to either unreliable integrations (when you prioritize user experience) or poor user experience (when you prioritize integration reliability), never achieving both simultaneously like the Event-driven approach provides.

Troubleshooting Performance Issues

You're a platform administrator dealing with user complaints about slow form saves, particularly during business hours when incident volume is high. Performance monitoring shows that business rule execution times are acceptable, but overall transaction times are much longer. Investigating the Event Queue reveals thousands of unprocessed Events backing up, and examining individual Event records shows they're failing repeatedly due to external system timeouts. The Event processing backlog is consuming system resources and causing cascading performance issues.

Understanding Events reveals that background processing problems can impact foreground user experience through resource contention and queue buildup. This knowledge guides you to tune event processor configuration, identify problematic Event Rules that need better error handling, and implement circuit breaker patterns for external integrations. You can also see how Event processing metrics directly correlate with overall system performance.

Someone without this understanding would focus on frontend performance tuning—adjusting business rule conditions, optimizing database queries, or increasing server resources—while ignoring the background processing bottleneck. They might even disable notifications or integrations to improve perceived performance, unknowingly breaking critical business processes that depend on reliable Event processing.

What People Get Wrong

Events are processed asynchronously by background threads, often seconds or minutes after they're created, and there's no guarantee about processing order or timing. This fundamental misunderstanding leads developers to write code that depends on Event processing completing before subsequent logic runs, creating race conditions and unreliable workflows. The misconception exists because gs.eventQueue() returns immediately and doesn't throw errors, making it appear that the event processing has completed successfully.

In production, this manifests as workflows that work perfectly in development environments with low data volumes but fail intermittently under load when Event processing delays become noticeable. For example, a business rule might queue an event to update an external system and then immediately query that system expecting to find the updated data, only to discover that the Event hasn't been processed yet. The resulting integration failures appear random and are extremely difficult to debug without understanding Event processing timing.

This timing misunderstanding also causes developers to create unnecessary duplicate Events when they don't see immediate results, compounding performance problems and creating duplicate notifications or integration calls. The correct approach requires designing workflows that are inherently asynchronous, using Event Rules or Script Actions to handle the work that needs to happen after Event processing, and building idempotent operations that can handle duplicate processing gracefully.

The most serious production consequence is data consistency issues in integrated environments, where ServiceNow and external systems can become permanently out of sync because developers assumed Event-triggered updates would complete before dependent operations ran. These issues are particularly problematic during upgrades or high-load periods when Event processing delays increase, causing previously reliable integrations to fail unpredictably.

Events can only accept serializable parameters—strings, numbers, and simple objects—because Event data gets stored in database fields and passed between different execution contexts. GlideRecord objects, complex JavaScript objects with functions, and references to server-side resources cannot be serialized and will either cause Events to fail during creation or result in empty parameter values when the Event is processed. This limitation exists because Events are processed in completely separate threads from where they're created, often on different application server nodes in clustered environments.

The misconception arises because gs.eventQueue() appears to accept any parameters without immediate error, and in development environments with simple test data, developers might successfully pass small objects that happen to serialize correctly. However, production data often contains complex nested structures, binary data, or circular references that break serialization, causing Events to fail silently or process with incomplete data.

In production, this results in Event processing failures that are extremely difficult to trace because the failures occur in background threads, often without adequate logging. Integration data gets corrupted or lost entirely, notifications contain blank fields instead of expected record data, and Event Rules fail with mysterious null pointer exceptions. The proper approach requires passing only sys_id values and primitive data types, then reconstructing GlideRecord objects within Event Rules and Script Actions using fresh database queries.

The most dangerous aspect of this mistake is that it often works partially—simple string fields from GlideRecord objects might serialize correctly while complex fields fail, leading to integrations that appear functional but silently lose data. This creates data integrity issues that can persist for months before being discovered, particularly affecting audit trails, approval workflows, and compliance reporting that depend on complete data transmission through Event processing.

Admin vs Developer Perspective

For Admins

Admins primarily configure Event Rules and Notifications that respond to events, making decisions about which system behaviors should trigger what notifications and to whom. They monitor the sysevent table to troubleshoot why notifications didn't fire or to track down performance issues caused by excessive event generation. The critical admin decision is determining processing order through the order field on Event Rules, as this can make or break complex automation chains. Admins must understand that events are asynchronous—they don't fire immediately when gs.eventQueue() is called, which affects troubleshooting timing-sensitive workflows.

For Developers

Developers trigger events using gs.eventQueue() to decouple immediate transaction logic from downstream processing, passing parameters through the parm1 and parm2 arguments to provide context to Event Rules or Script Actions. They write Script Actions that process events server-side, accessing event data through event.parm1, event.parm2, and current variables. The key developer pattern is using events for expensive operations that don't need to complete within the original transaction—like external API calls, complex calculations, or bulk data operations. Developers must be careful not to queue events in loops without throttling, as this can overwhelm the event processor and impact instance performance.

How It Connects to Other Concepts

• Business Rules — the most common place events are triggered, typically in 'after' Business Rules to avoid blocking the main transaction. Events allow Business Rules to trigger downstream processing without making the user wait, and multiple Business Rules can queue the same event name to create processing chains.
• Notifications — triggered directly by events through the notification's When to send condition set to 'Event is fired'. The event's parm1 typically contains the sys_id of the record context, which notifications use to determine recipients and populate email content.
• Script Actions — server-side scripts that execute when specific events fire, configured through Event Rules that match event names. Script Actions provide more flexibility than notifications for complex event processing, with access to the full server-side API and the ability to query, update, or create records based on event parameters.
• Scheduled Jobs — often trigger events to notify about completion, failures, or processing results. The pattern of having scheduled jobs queue events allows other systems to react to batch processing completion without tight coupling, and provides an audit trail in the sysevent table.
• REST APIs — can trigger events to provide webhook-like functionality, allowing external systems to initiate ServiceNow processing chains without direct database access. Events bridge the gap between external API calls and internal ServiceNow automation, maintaining security boundaries while enabling integration.
• Workflow Activities — can wait for specific events to fire before continuing execution, creating synchronization points in long-running processes. The 'Wait for Event' workflow activity listens for named events and can extract data from event parameters to use in subsequent workflow steps.

Junior vs Senior Knowledge Gap

Junior developers treat events as immediate triggers and don't grasp the asynchronous processing model, leading to timing assumptions that break in production. They'll queue an event in a Business Rule and immediately expect dependent processing to be complete, not understanding that events are processed by background schedulers after the transaction commits. This misunderstanding causes failed integrations and race conditions, especially when they try to read data that event-triggered processes should have created. Juniors also tend to queue events in loops or from high-frequency Business Rules without considering the performance impact, creating event storms that can overwhelm an instance.

The mental model shift happens when developers understand events as a message-passing system rather than function calls—they're sending instructions to be processed later, not executing immediate actions. Senior developers design event-driven architectures that decouple systems and reduce transaction complexity, understanding that events provide natural retry mechanisms and error isolation. They know to include enough context in event parameters for processing to succeed independently, without relying on database state that might change between event creation and processing. Experienced developers also understand event ordering isn't guaranteed—multiple events with the same priority might process in any sequence, affecting how they design dependent operations.

Senior professionals know that event processing has built-in retry logic and dead letter queuing that never appears in documentation—failed Script Actions will retry several times before being marked as failed. They understand the subtle differences between event processing threads and how node shutdown affects in-flight events in clustered environments. Architects know to check event throughput and processing times when diagnosing performance issues, as event backlogs can cascade into broader system problems. They also understand that events provide natural audit trails and debugging information that makes troubleshooting complex automation chains much easier than debugging synchronous script execution.

The questions an experienced architect asks reveal the depth of understanding: How will this event pattern behave during heavy load? What happens if the target record is deleted between event creation and processing? How will we monitor and alerting on event processing failures? Should this be multiple granular events or one complex event with conditional processing? How does this event design support our disaster recovery and business continuity requirements? These questions separate system designers from script writers, focusing on operational resilience rather than just functional requirements.

Quick Reference

• Events are stored in the sysevent table with states: Ready, Processing, Processed, Error—events stuck in Processing state indicate scheduler thread issues or infinite loops in Script Actions.
• Event Rules with identical order values don't guarantee execution sequence—use distinct order values (0, 100, 200) to ensure Script Actions run in specific sequence for dependent operations.
• The gs.eventQueue() function has a maximum parameter length limit around 4000 characters—longer data should be stored in a staging table with the sys_id passed as a parameter.
• Events queued within the same transaction are processed in the order they were queued, but events from different transactions with the same timestamp process in unpredictable order.
• Script Actions that throw unhandled exceptions mark the event as Error state but don't retry automatically—you must reprocess failed events manually or through scheduled cleanup jobs.
• Event processing threads are limited per node—typically 5-10 concurrent threads—so Script Actions with external API calls or complex processing can create bottlenecks affecting all event processing.
• The current object in Script Actions points to the sysevent record itself, not the source record—access the source record using new GlideRecord().get(event.parm1) pattern.
• Events created with gs.eventQueue() from scheduled jobs run in a different security context than events from interactive user sessions—some ACLs and business rule conditions behave differently.
• Event names are case-sensitive and support wildcards in Event Rules using asterisk (*) patterns, but wildcard matching is expensive and should be avoided in high-volume scenarios.
• The sysevent table grows rapidly in active instances—implement retention policies to prevent it from becoming the largest table in your instance and impacting database performance.