Create a system event with gs.eventQueue

System events via gs.eventQueue are ServiceNow's fire-and-forget messaging system. The critical insight: events are processed after your current database transaction commits, meaning downstream event scripts see the final, committed state of your record. Most developers expect synchronous execution and get confused when their event scripts run with stale data or in unexpected order. Events run in separate transactions with their own rollback boundaries — use them to decouple heavy processing from user-facing operations.

When to use this

• Triggering notifications that should send even if subsequent processing fails
• Launching expensive operations (REST calls, bulk data processing) without blocking the user
• Creating audit trails or analytics events that shouldn't affect transaction success
• Decoupling business logic across applications or scopes

When NOT to use this

• Don't use for validation logic that should prevent record saves — validation must be synchronous
• Don't use when you need the result immediately in the same session — events are async
• Don't fire events in loops over large record sets — you'll flood the event queue and degrade performance
• Don't use for simple field updates on the same record — do them directly in your business rule

Key behaviors and gotchas

• Events execute after the current transaction commits — event scripts see the final database state, not intermediate changes
• Pass primitive values as parameters, not GlideElement objects — toString() or getDisplayValue() to avoid serialization issues
• Event order is not guaranteed — multiple events from the same transaction may process in any sequence
• Events are domain-aware — they inherit the domain context of the triggering transaction
• Failed events retry automatically up to 5 times with exponential backoff before being marked failed
• Event processing can be delayed during high system load — don't assume immediate execution