Workflow trigger
The trigger portion of a workflow defines the condition which causes a workflow to run and process data.
In event workflows
For event workflows, the trigger also acts as a filter to determine the events processed. Click inside the Event Filter box and use the suggested fields and operators to build a filter which identifies the events the workflow will process. The workflow is triggered whenever incoming events match the filter.
In alert workflows
An alert workflow is triggered when the selected condition in the trigger occurs:
New or changed alerts: Trigger the workflow when a new alert is created, or a change occurs to an existing alert
New alerts only: Trigger the workflow only when a new alert is created
Changed alerts only: Trigger the workflow only when a change occurs to an existing alert
If you selected either "New or changed alerts" or "Changed alerts only," then you must also specify the type of changes that are allowed to trigger the workflow:
Changes from anywhere: All changes to alerts can trigger the workflow
Changes from deduplication only: Only changes to alerts that result from deduplication can trigger the workflow (a new event is received and the deduplication process adds it to an existing alert)
Alert workflow triggers include a filter which lets you choose a subset of the triggering alerts for the workflow to process. Unlike event workflows, the filter is optional, since the workflow is triggered by create or update changes. To use the filter, click inside the Alert Filter box and use the suggested fields and operators to build a filter which identifies the alerts the workflow will process.
In incident workflows
An incident workflow is triggered when the selected condition in the trigger occurs:
New or changed incidents: Trigger the workflow when a new incident is created, or a change occurs to an existing incident
New incidents only: Trigger the workflow only when a new incident is created
Changed incidents only: Trigger the workflow only when a change occurs to an existing incident
Qualifying incident changes include adding new alert to an incident or updating a value in an incident field. Changes at the alert level (such as deduplication and severity updates) do not qualify as incident changes.
The incident workflow trigger also includes an optional filter which lets you choose a subset of the triggering incidents for the workflow to process. The process for building an incident workflow filter is similar to the method for alert workflow filters: click inside the Incident Filter box and use the suggested fields and operators to build a filter which identifies the incidents the workflow will process.
The trigger filter
For event workflows, the trigger filter defines the events that the workflow will process. In incident and alert workflows, it is optional, but when a filter is present, it determines which alerts or incidents are processed by the workflow.
Click in the filter field and select the fields, values, and operators from the menus.
Note
For additional assistance building filters, refer to Build a scope filter query.
changes field
The changes field is a list that stores all the alert or incident fields that were most recently updated. It is available for alert and incident workflows, and can also be used in the scope filter for the Filter action.
For example, if an incident description was modified in the last update, and the priority was also increased from "Minor" to "Critical," then changes will contain both description and priority as elements.
If your workflow uses a Send to Endpoint action to trigger a webhook endpoint, you can define a scope filter query with changes to reproduce the behavior of the webhook endpoint "Triggers" section. This is useful if you want to check for updates to an incident from the incident workflow instead of the webhook endpoint. Note that if you use changes in this way, the "Triggers" section of the corresponding webhook endpoint will be ignored.
Example: To replicate the behavior of the "Assignee changed" trigger option in the webhook endpoint page, use the following filter:
changes in ( assignee )
Caution
Considerations for using changes with workflow delays
When creating workflows that use changes as part of the trigger filter, keep in mind that an incident might not have the same changes as it passes through the workflow chain. This is especially true if you use the Delay action, which temporarily pauses the workflow and then continues with the most recent instance of the object. If there are updates to the object before or during the delay, the changes field could be different from what it was when the object first entered the workflow.
To avoid issues, place workflows that rely on changes before any workflows that include the Delay action, near the start of your workflow chain.
Note
For more information on alert and incident fields, read the following topics:
Using quotation marks
Quotation marks are only required in filter parameters when there are spaces in a string.
Example: A string with no spaces does not require quotation marks:
tag.key1 = 5
But a string with spaces will not be parsed correctly without quotation marks, as in the following two cases:
"correlation definition" = a551ab9f-c5ab-4dfe-a52d-b325393176af
tag.key1 = "Allegheny Airlines"
Filtering with correlation definitions in incident workflows
When filtering incidents based on the correlation definition responsible for forming the incident, be sure to use the ID of the definition instead of the name.
Example:
"correlation definition" = "a551ab9f-c5ab-4dfe-a52d-b325393176af"
You can retrieve the ID by using an API call, or by opening the definition for editing in the user interface and then copying the final series of characters from the URL:
 |