Events and script actions
Quick answer
Decouple logic with the event queue: register events, fire them, and process them asynchronously.
Key takeaways
- Events decouple triggers from reactions
- eventQueue takes a record, two parameters and a user
- Script actions and notifications are the consumers
- Processing is asynchronous, do not rely on ordering
Why events
Firing an event separates the thing that happened from the reactions to it. One record update can trigger a notification, an integration and an audit entry without any of them knowing about each other.
Registering and firing
Register the event name in the event registry, then fire it with up to two parameters plus an optional user.
// registry: x_acme.order.approved on table sc_request
gs.eventQueue('x_acme.order.approved', current, current.number, gs.getUserID());Consuming events
Notifications can trigger on an event, and script actions run server code when an event is processed.
- Script actions receive event and current, and run asynchronously
- Events are processed by the scheduler, so ordering is not guaranteed
- Use parm1 and parm2 for small values, never for payloads
- Watch the event log when nothing happens, unprocessed events show up there
Want to learn this properly?
Our live, instructor-led ServiceNow Training covers this hands-on, with real projects and a certification path.
Check your understanding
Which call places an event on the queue?
- A. gs.fireEvent
- B. gs.eventQueue
- C. gs.trigger
- D. gs.publish
Show answer
B. gs.eventQueue
gs.eventQueue registers the event for asynchronous processing.
What runs server side code in response to an event?
- A. A UI action
- B. A script action
- C. A client script
- D. A data policy
Show answer
B. A script action
Script actions are the server side consumers of events.