---
sourceDocument: Zurich Build workflows
sourceDocumentLink: https://www.servicenow.com/docs/r/zurich/build-workflows

 Release :

    - zurich

ft:locale :

    - en-US

ft:publication_title :

    - Zurich Build workflows

ft:clusterId :

    - crworkflow

bundleId :

    - crworkflow

workflow :

    - Creator


---

# System Events

# System Events {#ariaid-title1}

* Release version: Zurich
* 
* Updated July 31, 2025
* 
* ![](https://www.servicenow.com/docs/portal-asset/ico-clock) 2 minutes to read

Summarize  
![AI sparkle icon](https://servicenow.com/docs/portal-asset/ai-sparkle-icon) Summarized using AI  
This content was generated using new OpenAI-powered functionality. Results are provided on an as is basis and are not guaranteed to be accurate or complete.  

## Summary of System Events

System Events in ServiceNow are specialized records that log when specific conditions occur within the platform and trigger actions in response.
Business rules monitor system conditions and generate event records stored in theEvent \[sysevent\]table, also known as the event log or event queue.
These events enable automation and system responsiveness by invoking scripts, notifications, workflows, or monitors based on changes to records.
Show full answer Show less  

## Key Features

* **Event Generation:** Business rules use the `GlideSystem.eventQueue` method to insert event records when certain conditions are met, such as adding or updating incident records.
* **Event Record Structure:** Events typically contain:
  * **Name:** Unique event identifier, usually combining the affected record and action (e.g., `incident.commented`).
  * **Parm1 and Parm2:** Parameters that pass record-specific information like Sys IDs or field values.
  * **Table:** The table to which the event applies.
  * **Instance:** Sys ID of the specific record involved.
* **Event Processing:** Scheduled jobs periodically read the event queue and forward events to appropriate handlers for processing actions such as running script actions, sending notifications, triggering workflows, or initiating inactivity monitors.
* **Customization:** Customers can create custom events if the default events do not meet their specific monitoring or automation needs.
* **Monitoring:** The **System Events and Jobs Dashboard** provides visibility into event processing and scheduled jobs status.
* **Upgrade Considerations:** During platform upgrades, event processing can be controlled via system properties:
  * `glide.eventprocessor.alleventsupgradesafe` (default: false) determines if all events are processed during upgrades.
  * `glide.eventprocessor.upgradesafeevents` allows specifying a list of events to process during upgrades when the above property is false.

## Key Outcomes

By understanding and utilizing system events, ServiceNow customers can automate responses to record changes, improve system monitoring, and customize event-driven workflows to better fit organizational requirements. The ability to control event processing during upgrades ensures system stability and predictable behavior throughout platform maintenance.  
Events are special records that the system uses to log when certain conditions occur and to take some kind of action in response to the conditions.

The system uses business rules to monitor for system conditions and to generate event
records in the Event \[sysevent\] table, which is also known as the event log or event
queue.

Event-generating business rules typically use this script logic:

If \[some condition is true for the current record\], then \[add a specific event to the
queue\].  
For example, here are some of the conditions in the incident event business rule:

* If a user adds a comment to an incident record, add an incident.commented event.
* If a user adds an incident record, add an incident.inserted event.
* If a user updates an incident record, add an incident.updated event.
{#events__ul_xnm_jwg_vw}  
Event-generating business rules use the GlideSystem eventQueue method to insert event records, which typically contain this information:{#events__table_fjs_st1_vw__entry__2}

| Field | Description |
|-|-|
| Name | Unique name of event. Baseline event names include the record affected and the triggering action, such as incident.commented. |
| Parm1 | Event-specific parameter the system uses to pass record information to other parts of the system, such as a record Sys ID or a field value. |
| Parm2 | Event-specific parameter the system uses to pass record information to other parts of the system, such as a record Sys ID or a field value. |
| Table | Table to which the event applies. This is the same table on which the business rule ran. |
| Instance | Sys ID of the record to which this event applies. |
[Table 1. Event fields]

{#events__table_fjs_st1_vw}  
Scheduled jobs periodically read the event queue and forward them to the appropriate handler for processing. The handler uses information from event records to take some kind of action such as:

* Run a script action
* Send a notification
* Trigger a workflow activity
* Trigger an inactivity monitor
{#events__ul_vph_sq1_vw}

By default, the system provides events covering a broad view of application activity. If
existing events do not meet your needs, you can create your own events to watch for
specific changes to records.

For developer training, see [Scheduled Script Executions and Events Objectives](https://developer.servicenow.com/dev.do#!/learn/courses/xanadu/app_store_learnv2_automatingapps_xanadu_automating_application_logic/app_store_learnv2_automatingapps_xanadu_scheduled_script_executions_and_events/app_store_learnv2_automatingapps_xanadu_scheduled_script_executions_and_events_objectives)
on the ServiceNow®
Developer Site.

Use the [System Events and Jobs Dashboard](https://www.servicenow.com/docs/access?context=track-events&version=zurich&pubname=zurich-platform-administration&ft:locale=en-US) to monitor the system event processing system and the scheduled jobs processing system.

## Event processing during platform upgrade {#events__section_t45_dqx_ktb}

Determine which events are to be processed during a platform upgrade by configuring the
following properties:

* glide.event_processor.all_events_upgrade_safe: Set to true to process all events during platform upgrade. Default = false.
* glide.event_processor.upgrade_safe_events: Configure a comma-separated list of event names to indicate that only specified events are processed. Default = \<empty\>.

  This property is relevant only when
  glide.event_processor.all_events_upgrade_safe = false.
{#events__ul_t2g_gqx_ktb}