Event trigger
Beta feature
This feature is currently in beta, and should be considered ‘under development’. Learn about the automations beta.Overview
The Event trigger fires when a named platform event occurs, rather than a data-model record being created, updated, or deleted. Some events correspond to changes on an underlying record (for example, a rules violation being raised or resolved), but the event itself: not the record: is what the trigger subscribes to.
You choose which event type to subscribe to, and optionally add an EQL filter to narrow down which occurrences of that event should trigger the workflow.
Configuration
Event type
Select the platform event to subscribe to. Currently available:
| Event type | Description |
|---|---|
| Rules Violation | Fires when a rules-engine violation record is created, updated, or deleted (raised, changed, or cleared) |
Filter (optional)
An EQL (Elastic Query Language) expression over the event, evaluated before the workflow is started. The automation only runs when the filter evaluates to true. Leave it blank to run on every occurrence of the selected event type.
The filter can reference:
current: the event’s payloadprevious: the payload’s prior state, when the event carries one (for example, on an update)operation: the lifecycle that produced this occurrence:Insert,Update, orDeleteeventTypeandsource: the event’s own type and originating system
Note
The trigger filter uses EQL, not JSONata. See the EQL filter documentation for syntax details.Rules Violation filter recipes
| Intent | Filter |
|---|---|
| Violation raised | operation == 'Insert' |
| Violation cleared (rule no longer violated) | operation == 'Delete' |
| User resolved or closed | operation == 'Update' AND current.Status IN ['Closed', 'Acknowledged'] |
| System auto-resolved | operation == 'Update' AND current.Status == 'System Resolved' |
There’s no plain Resolved status: valid values for current.Status are Open, In Progress, Closed, Acknowledged, and the system-only System Resolved.
Rules Violation payload fields
The following fields are available on current (and previous, where applicable) for Rules Violation events:
| Field | Type | Description |
|---|---|---|
Id |
integer | The violation record ID |
RuleId |
text | The rule that fired (for example, resourceUnavailable); tenant-defined when IsCustom is true |
Status |
picklist | Violation status: Open, In Progress, Closed, Acknowledged, or System Resolved |
IsCustom |
checkbox | True when RuleId is a tenant-defined custom rule |
TargetId |
text | UID of the object the violation applies to |
TargetType |
text | Type of the target object (for example, job): not a data-model object name |
SourceId |
text | UID of the object that caused the violation (may equal TargetId) |
SourceType |
text | Type of the source object (for example, resource): not a data-model object name |
StartTime / EndTime |
datetime | Start and end of the violating interval |
RegionId |
text | Region the violation belongs to |
ResourceIds |
text | UIDs of the affected resources |
Description |
textarea | Human-readable description of the violation |
AssignedTo |
text | UID of the user the violation is assigned to, if any |
CreatedTime / CreatedById |
datetime / text | When the violation was created, and by whom |
LastModifiedTime / LastModifiedById |
datetime / text | When the violation was last modified, and by whom |
Note
For Rules Violation events,previous only carries the keys that actually changed, not a full snapshot of the prior state: fields that didn’t change won’t appear on previous.
Trigger output
When the event trigger fires, it injects a set of output values into the workflow that are available to all subsequent steps, accessed via the $trigger namespace.
| Variable | Type | Description |
|---|---|---|
$trigger.eventType |
string | The namespaced event type that fired, for example, rules.violation |
$trigger.source |
string | The system that raised the event |
$trigger.userId |
string | The ID of the user associated with the event, when applicable |
$trigger.current |
object | The event’s payload |
$trigger.previous |
object | The payload’s prior state, when the event carries one |
$trigger.metadata |
object | Arbitrary metadata attached to the event |
Note
$trigger.operation is not available to workflow steps for event triggers: operation can only be used inside the trigger’s own Filter expression. If a later step needs to branch on the lifecycle that caused the event, split the logic into separate automations filtered by operation, or add a Choice step based on other payload fields.
Expression examples
| Goal | Expression |
|---|---|
| Get a field from the event payload | $trigger.current.FieldName |
| Check whether a rules violation was auto-resolved | $trigger.current.Status = 'System Resolved' |
| Get the ID of the object the violation applies to | $trigger.current.TargetId |
| Get the event type that triggered the workflow | $trigger.eventType |
See also
- Introduction to automations
- JSONata expressions: how to use trigger output in expressions
- EQL filter documentation
Feedback
Was this page helpful?