Development · LessonBy Sneha I, ServiceNow Trainer, 8 yrs · Published · ServiceNow · all levels
Events and script actions
Decouple logic with the event queue: register events, fire them, and process them asynchronously.
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
Practice challenge
+0 XPStreak ×0
Question 1 of 2
Which call places an event on the queue?
Frequently asked questions
Event or flow?
Flows are the modern default for process automation. Events remain useful for fan out, for notifications and for integrating with older platform features.
Why did my event not fire?
Check that it is registered in the event registry with the right table, and look for it in the event log with state ready or processed.