Understanding Custom Event Queues in ServiceNow

Overview

The Event Queue in ServiceNow is a mechanism used to manage and process system events asynchronously. Events trigger actions based on conditions, enabling tasks such as notifications or workflows.

In ServiceNow, events are stored in the Event [sysevent] table and processed asynchronously. By default, events are placed in the Default queue, but high-volume or time-sensitive workflows can benefit from Custom Event Queues, which allow you to isolate, prioritize, and optimize event processing.

What is Custom Event Queue

A Custom Event Queue is a user-defined event queue separate from the Default queue. Events placed in a custom queue are processed only by a queue processor (Scheduled Job) associated with that queue. This gives you more control over event processing and helps prevent bottlenecks by isolating critical or heavy workloads.

Understanding the 'Queue' Column in [sysevent]

When viewing the Events [sysevent] table in ServiceNow, you may see that:

• Some out-of-the-box (OOB) events have a value in the Queue column.

• Others leave the field blank.

  
  

Why the difference?

• Blank Queue

  • The event is processed in the Default queue.

  • This is the standard behavior for most OOB and custom events.

  • Works well when the event volume is low and performance impact is minimal.

• Queue value populated

  • The event has been explicitly assigned to a custom queue.

  • These events are processed by the queue processor job defined for that queue, separate from the Default queue.

Why Use a Custom Event Queue?

The default event queue can quickly become congested in high-volume environments (e.g., integrations, heavy scheduled jobs, mass updates). If all events share the same queue, delays or bottlenecks can occur.

Custom event queues solve this problem by:

• Separating critical events from non-critical events.

• Ensuring that time-sensitive events are not delayed by background bulk events.

• Allowing parallel event processing to improve overall performance.

  
  

Using a custom event queue is recommended when workflows generate a large number of events or when critical events must be prioritized.

Benefits of Custom Event Queues

• Performance optimization – Custom queues allow events to be processed in parallel, reducing bottlenecks and improving system responsiveness.

• Priority handling – High-priority events can be isolated from low-priority or bulk events, ensuring critical workflows are not delayed.

• Isolation & stability – Overload in one queue does not affect other queues, improving overall system reliability.

• Scalability – Supports large volumes of events without impacting other workflows.

• Flexibility – Developers can design event-driven processes with specific routing and processing logic, tailored to business needs.

Implementation - Using Custom Queues

Here’s how you can implement a custom event queue in ServiceNow:

Step 1: Populate the Queue field for the event in the Event Registry

Populate the Queue field for the event in the Event Registry to define a custom queue. (Note: custom queue names should be all lowercase letters, no spaces, and no special characters except underscore, per best practice.)

When you enter a value in the Queue field, a custom queue is created. Once the “systemMaintenance” event is generated, it is placed into “my_queue”. However, events in “my_queue” remain there because no process is currently monitoring the queue.

Step 2: Create a Custom Queue Processor (Scheduled Job)

1. Navigate to System Scheduler > Scheduled Jobs > Scheduled Jobs.

2. Find and open the text index events process Scheduled Job record.

3. Change the Schedule Item ‘Name’ field and the queue name in the ‘Job Context’.

fcScriptName=javascript\:GlideEventManager('my_queue').process();

4. Set Next action to be in the near future (i.e. 30 seconds from the current moment). This is very important in order to get the job running.

5. (optional) Edit the Repeat interval (short repeat interval may have some negative impact on the system performance, but at the same time, the lower the repeat interval, the sooner your event will be queued and processed).

6. Click the Additional actions menu and select Insert and stay. Do not click Save/Update button.

Step 3: Fire Events to the Custom Queue

To send an event to a custom queue, you must specify the queue name as the fifth parameter in the gs.eventQueue() method.

gs.eventQueue('eventName', recordGr,  parm1, parm2, 'my_queue');

The method above sends the event eventName to the my_queue custom queue, where it will be processed by its dedicated queue processor.

If the fifth parameter (my_queue) is omitted, ServiceNow falls back to the queue defined in the Event Registry. If the event record in the registry has a queue set (e.g., reminder_queue), the event will be processed under that queue. If no queue is defined, it defaults to the Default queue.

Step 4: Validation

To verify the new processor is working as expected, navigate to System Logs > Events, filter by the matching event name and confirm that newly created events are being marked processed and are going into the correct queue.

Best Practices for Custom Event Queues

• Use only when necessary – Recommended only for scenarios with high volumes of events or records.

• Clear and descriptive naming – Assign meaningful names to both the queues and their processors to ensure readability and maintainability.

• Distribute load across multiple queues – For optimal performance, you can create multiple custom queues to handle a particular event. To ensure even distribution of events:

  • Create a Script Include containing an array of queue names.

  • Randomly assign events using:

gs.eventQueue( 'event.name', grSomeObject, null, null, event_queues[Math.floor(Math.random() * event_queues.length)]);

Here, event_queues is an array containing the names of your custom queues. This approach balances event processing and helps prevent overloading a single queue.

Job IDs in Scheduled Jobs & Their Role with Custom Event Queues

What is a Job ID?

In ServiceNow, each Scheduled Job is stored in the [sys_trigger] table. Each record in this table has a unique identifier, commonly referred to as the Job ID. This Job ID links the scheduled job in the UI to its underlying execution logic.

Why Job IDs Matter for Custom Event Queues

When you configure a Custom Event Queue, you generally have to create a corresponding Scheduled Job that acts as the queue processor — the job that picks up and processes events in that queue. This job is assigned a Job ID.

Understanding and utilizing this Job ID is crucial for:

• Monitoring: Tracking the execution and success/failure of your custom queue processor.

• Troubleshooting: Investigating logs and identifying issues related to event processing.

• Auditing: Maintaining a record of when the custom queue was processed.

Finding Job IDs & Their Parameters

All existing and available "Job ID"s you can use in your Scheduled Jobs can be found in the Sys Job [sys_job] table.

For example, in the screenshot below, you can see a Scheduled Job “Stock Rule Runner”, which references the Job ID “RunScriptJob”.

The ‘Job context’ field contains information for the execution of the ‘RunScriptJob’. In the case of the RunScriptJob, the parameter fcScriptName is set to “in the schedule record”. This instructs the executing job (RunScriptJob) to look into the ‘Script’ field of the Scheduled Item and execute the Script defined there.

Alternatively, you can write a script directly into the Job context field. To do so, prefix the code with “javascript\:” to indicate that the content should be treated as inline JavaScript.

To identify and understand the parameters associated with a Job ID:

1. Navigate to the [sys_job] table:

   In the Application Navigator,  type “sys_job.list” and press Enter to view all registered Sys Jobs that can be referenced in Scheduled Jobs.

2.  Review Job Details:

   Open the details of a specific Sys job and review the ‘Job details’ of the record.

   
   

   For example, the ‘RunScriptJob’ Sys Job might have a parameter like ‘fcScriptName’ set to ‘in the schedule record’ which specifies the script to execute.

3. Investigate Scheduled Jobs Using the Job ID:

   Some Scheduled Jobs may reference records in other tables. For instance, a Scheduled Item might reference a record in the [sysauto_script] table, indicating a specific script to execute.

To locate the specific script that this schedule item executes, you can use the fcDocumentKey value, which is the sys_id of the record in the [sysauto_script] table.

Open the table by navigating to “sysauto_script.list”. Filter by the fcDocumentKey value to find the Scheduled Script Execution record.

General Rule of Thumb for Job IDs

• Start with the [sys_job] table: Locate the specific Sys Job record and open it in form view to review its Job details.

• Trace scheduled jobs: Identify any Scheduled Jobs that reference this Sys Job to understand how it is being executed.

• Compare implementations: If multiple Scheduled Jobs use the same Sys Job, review each implementation. This will give you insights into the different ways the Job ID can be invoked.

• Document your findings: Always record where and how a Job ID is being referenced, to avoid confusion and to maintain system transparency.

Custom Event Queue Use Cases

Custom Event Queues are particularly useful in scenarios where event volume is high, or certain events require isolation or prioritization.

Below are some practical examples:

• High-Volume Integrations For instance, when integrating with an external HR system that pushes thousands of employee updates every hour, processing all these events in the Default queue can cause performance delays. A dedicated integration_queue ensures these events are processed independently without impacting other system operations.

• Priority Notifications When a critical incident is created, the system can trigger an incidentPriority_queue to send urgent alerts and updates immediately—ensuring that time-sensitive actions are not delayed by bulk background events like report generation.

• Preventing Race Conditions When multiple updates occur on the same record (e.g., financial transactions or asset updates), a single-threaded custom queue such as asset_update_queue can handle them sequentially to prevent data conflicts or record locking.

• Mass Record Updates During scheduled maintenance or data imports, the platform may generate numerous downstream events (e.g. email notifications). By routing these notifications to a dedicated notification_queue, you can process them asynchronously without delaying core record updates.

• Complex or Long-Running Scripts A scheduled job that recalculates department budgets each night can use a custom queue budget_processing_queue to isolate heavy processing and prevent it from blocking other business-critical events.

Conclusion

Implementing Custom Event Queues helps maintain system performance and stability in high-volume or complex environments.

By isolating critical or resource-intensive events from general event processing, you can:

• Prevent delays and bottlenecks in the Default queue

• Prioritize time-sensitive workflows

• Improve overall processing efficiency and scalability

  
  

Use Custom Event Queues strategically—only where necessary—and ensure that each queue and processor is clearly named and documented for ongoing maintenance and troubleshooting.