Event Script Actions let you run server-side JavaScript automatically when specific events fire across your instance. You'll have a reliable way to execute background logic without blocking user interactions.
The problem with synchronous workflows
Before Event Script Actions, you were stuck running heavy server-side logic synchronously — inside Business Rules, UI Actions, or other user-facing operations. This meant users waited for database queries, web service calls, or complex calculations to finish before their forms would save. Platform teams ended up with slow interfaces and complaints about performance, especially when integrations were involved.
How event-driven logic works
An Event Script Action is JavaScript that runs asynchronously when ServiceNow fires a named event. The event carries parameters (event.parm1, event.parm2, etc.) that your script can use, plus a GlideRecord called 'current' if the event relates to a specific table record. Events get fired by gs.eventQueue() calls from anywhere in the system — Business Rules, workflows, integrations, or custom scripts. Your script action listens for events with matching names and processes them in the background without blocking the original operation.
Production-quality event handling
Once basic event processing works, you'll want error handling that logs meaningful messages, idempotent scripts that can safely run twice on the same data, and event parameters that carry everything your script needs without querying the database. Advanced implementations use events for decoupling — firing events from forms and handling the complex logic asynchronously, so users get immediate feedback while heavy operations run in the background.
Before you start
- •admin role or elevated developer access
- •Understanding of server-side JavaScript and GlideRecord
Sourdough: ServiceNow Monitoring and Analytics
A Chrome extension for ServiceNow Admins and Developers with essential tools, analytics, graphs and monitoring features.
Free to install. Pro $5/month after a 14-day no-card trial.
Pro requires the ServiceNow admin role. Upgrade inside the extension.
Step by step
Navigate to Script Actions
Go to System Policy > Events > Script Actions. This is where all event-driven server scripts live, separate from Business Rules or other synchronous logic.
Script Actions are often overlooked — many developers don't realize this module exists and try to handle events in Business Rules instead.
Create the Script Action record
Click New to create a Script Action. Set Name to something descriptive like 'Process User Onboarding' or 'Sync Asset Data'. The Name appears in system logs when the script runs, so make it meaningful for debugging.
Use verb-noun naming that matches your event names — it makes troubleshooting much easier later.
Configure the event name
Set Event name to the exact string your gs.eventQueue() calls will use. This is case-sensitive matching — 'user.onboard' will only trigger for events fired with that exact name. Leave Table blank unless you want this script to only run for events related to a specific table.
Use dot notation like 'user.onboard' or 'asset.sync' to group related events — it makes the event log much more readable.
Write the script logic
In the Script field, write your JavaScript. Access event parameters through event.parm1, event.parm2, etc. If the event was fired with a record context, use the 'current' GlideRecord to access that record's fields. Add error handling with try-catch blocks since failed script actions don't automatically retry.
Set execution properties
Check Active to enable the script action. Set Order to control execution sequence if multiple script actions listen for the same event — lower numbers run first. Leave Condition empty unless you need additional filtering beyond the event name match.
Start with Order 100 so you can insert higher-priority script actions later without renumbering everything.
Test the event firing
Save the Script Action, then test it by firing your event from a Background Script: gs.eventQueue('your.event.name', current, 'param1', 'param2'). Check System Logs > Events to see if your event fired and System Logs > System Log > All to catch any script errors.
Monitor execution and debug
Watch the Events log (System Logs > Events) to confirm your events are firing with the right parameters. If script actions fail, errors appear in the main System Log with your Script Action name. Failed script actions don't retry automatically — you'll need to fix the code and re-fire the event.
Add gs.log() statements in your script action during development — they'll appear in the system log with your script action's name for easy filtering.
Best practices
Always include try-catch error handling in script actions — uncaught exceptions kill the script and the event gets lost without retry logic.
Pass all necessary data through event parameters rather than querying the database inside the script action — it's faster and makes the script more testable.
Use meaningful event names with dot notation like 'user.created' or 'incident.escalated' — avoid generic names like 'process' or 'update' that don't indicate purpose.
Log both successful completion and meaningful error details using gs.log() — event script actions run asynchronously so you won't see failures in the UI.
Keep script actions idempotent — if the same event fires twice with the same parameters, running your script twice shouldn't break anything.
Test Your Knowledge
Quick 3-question quiz — see how your ServiceNow skills stack up.
A list view on a table with millions of records is slow. Best fix?
Select an answer to continue