{"revision":"c10276e953456835cdbb1f3a60d58ae1980be353","document":{"id":3840,"path":"build-workflows/system-events/events.md","title":"System Events","bundle":null,"doc_type":null,"release":"australia","body":"\n# System Events\n\nEvents 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.\n\nThe 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.\n\nEvent-generating business rules typically use this script logic:\n\nIf \\[some condition is true for the current record\\], then \\[add a specific event to the queue\\].\n\nFor example, here are some of the conditions in the **incident event** business rule:\n\n-   If a user adds a comment to an incident record, add an **incident.commented** event.\n-   If a user adds an incident record, add an **incident.inserted** event.\n-   If a user updates an incident record, add an **incident.updated** event.\n\nEvent-generating business rules use the GlideSystem eventQueue method to insert event records, which typically contain this information:\n\n|Field|Description|\n|-----|-----------|\n|Name|Unique name of event. Baseline event names include the record affected and the triggering action, such as **incident.commented**.|\n|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.|\n|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.|\n|Table|Table to which the event applies. This is the same table on which the business rule ran.|\n|Instance|Sys ID of the record to which this event applies.|\n\nScheduled 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:\n\n-   Run a script action\n-   Send a notification\n-   Trigger a workflow activity\n-   Trigger an inactivity monitor\n\nBy 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.\n\nFor 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.\n\nUse the [System Events and Jobs Dashboard](https://raw.githubusercontent.com/ServiceNow/ServiceNowDocs/australia/markdown/platform-administration/track-events.md) to monitor the system event processing system and the scheduled jobs processing system.\n\n## Event processing during platform upgrade\n\nDetermine which events are to be processed during a platform upgrade by configuring the following properties:\n\n-   **glide.event\\_processor.all\\_events\\_upgrade\\_safe**: Set to **true** to process all events during platform upgrade. Default = **false**.\n-   **glide.event\\_processor.upgrade\\_safe\\_events**: Configure a comma-separated list of event names to indicate that only specified events are processed. Default = <empty>.\n\n    This property is relevant only when **glide.event\\_processor.all\\_events\\_upgrade\\_safe = false**.\n\n\n"}}