Table of Contents | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Overview
You can further make advanced settings in the integration to cover a variety of alert scenarios. These scenarios are called "actions" and they specify how and when alerts can be created, closed, acknowledged, etc. Jira Service Management offers default actions for every integration, but you can customize them or add as many actions of your own as you like. For example, you can have three ‘Create alert’ actions; which means the webhook data that comes to Jira Service Management is evaluated against these three scenarios in order, and if any one rule you set matches, a new alert is created.
Action processing
There is a specific order in which the actions are evaluated. For example, ‘Ignore’ actions are evaluated first by design, and ‘Add note’ actions, last. This means the incoming data is evaluated against ‘Ignore’ actions and if one of them has a match, then no further actions are evaluated; only that Ignore action gets processed.
The following is the order of evaluation of actions: Ignore > Create alert> Close alert> Acknowledge alert > Add note to alert
Expand | ||
---|---|---|
| ||
An Ignore action means that the webhook data if it matches the action filter is ignored completely and isn’t evaluated by any other action. Ignore actions come with no default rules. These are the actions to be processed first when webhook data comes to Jira Service Management. On the integration configuration page:
If incoming webhook data matches the condition set of the filter, the ignore action is processed, thus, the data will be ignored. Learn more about action filters. |
Expand | ||
---|---|---|
| ||
The “Create alert” action creates a Jira Service Management alert if the condition set of its filter matches the incoming data. Specify the conditions for when an alert is created and fully customize the content of those new alerts. On the integration configuration page:
Alert filters If the data that's sent to Jira Service Management matches the condition set in this filter, the 'Create alert' action is processed to create an alert. Learn more about action filters. Alert properties Alert properties are data that define the content of a Jira Service Management alert. You can type free text to describe the alert, set the priority, etc. You can also drag and drop the dynamic fields from the right panel. Only a few alert property fields are visible by default - select Show more properties to view them all.
|
Expand | ||
---|---|---|
| ||
The 'Close alert' action closes an existing Jira Service Management alert based on its alias if the data matches the condition set of the filter. Learn more about action filters. Alert properties Alias is a mandatory field for this action. When a ‘Close alert’ action is processed, Jira Service Management looks for an "open" alert to close, whose alias is equal to the alias specified in this action.
|
Expand | ||
---|---|---|
| ||
The 'Acknowledge alert' action acknowledges an existing alert based on its alias if the data matches the condition set of the filter. Learn more about action filters. Alert properties Alias is a mandatory field for this action. When a ‘Acknowledge alert’ action is processed, Jira Service Management looks for an "open" alert to acknowledge, whose alias is equal to the alias specified in this action.
|
Expand | ||
---|---|---|
| ||
The 'Add note to alert' action is used to add a comment to an existing alert according to the data Jira Service Management API receives. When this action is processed, Jira Service Management looks for an alert with an alias equal to the alias specified in this action to add a note to. Both Alias and Note fields are mandatory for this action.
|
Info |
---|
You can have up to 255 actions for each integration, up to 250 rules for the incoming part, and up to 50 for the outgoing. |
Changing the order of actions
The actions of the same type also are evaluated in order and you can change it. For example, you have three 'Create alert' actions in the order of CreateAlert1, CreateAlert2, and CreateAlert3. You can just drag CreateAlert3 and move it up to change the order to CreateAlert3, CreateAlert1, and CreateAlert2. Now upon saving the rules, CreateAlert3 is evaluated before the other two against the incoming data. If the filter for CreateAlert3 has a match, CreateAlert1 and CreateAlert2 are evaluated. Remember that for one incoming request, only one action is run.