Send a notification from an async Business Rule

The event queue pattern exists because notifications sent directly from Business Rules create transaction coupling — if the database transaction rolls back after gs.sendMail() executes, users receive emails about changes that never actually happened. gs.eventQueue() defers notification processing until after transaction commit, preventing phantom notifications and improving Business Rule performance by moving email processing to a background worker.

When to use this

• When sending notifications from async Business Rules where transaction rollback is possible
• When you need to pass structured data to the notification (event parameters)
• When Business Rule performance matters — email processing happens in background
• When you want centralized notification logic that multiple Business Rules can trigger

When NOT to use this

• Don't use in before Business Rules — the current record doesn't have a sys_id yet for event context
• Don't use for time-critical notifications where seconds matter — use gs.sendMail() instead
• Don't use when you only need simple email without templates — gs.sendMail() is simpler for basic messages
• Don't use in client scripts — events only work server-side, use GlideAjax to call server-side notification logic

Key behaviors and gotchas

• Event processing is asynchronous — notifications may arrive 30-60 seconds after the Business Rule executes
• Event parameters (parm1, parm2) must be strings — toString() GlideElement values explicitly
• The notification must exist and be active, with matching event name in the When to send tab
• Events are domain-separated — notifications in global scope won't fire for domain-scoped record updates
• Empty assigned_to fields return nil — always check isEmpty() before accessing reference field properties
• Priority values are integers: 1 = Critical, 2 = High, 3 = Moderate, etc.