Explore integration actions

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

Ignore alert

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:

1. Select Add rule in the Incoming section.

2. In the Add alert rule dialog, enter a name for the rule.

3. Select “Ignore” for the Rule type.

4. Set the filters as necessary.

5. Select Save.

If incoming webhook data matches the condition set of the filter, the ignore action is processed, thus, the data will be ignored. Read more about alert filters.

Create alert

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:

1. Select Add rule in the Incoming section.

2. In the Add alert rule dialog, enter a name for the rule.

3. Select “Create alert” for the Rule type.

4. Set the filters as necessary.

5. Define the alert properties as necessary.

6. Select Save.

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. Read more about alert 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 properties from the right panel. Only a few alert property fields are visible by default - select Show more properties to view them all.

• Alert message: A title for the alert. You can use up to 130 characters.

• Alias: The alias is a unique identifier for "open" alerts.
  There can be only one open alert with the same alias in Jira Service Management.

• Description: A detailed description of the alert; anything that may not have fit in the Message field can be entered here.

• Actions: List of actions a recipient can run to respond to an alert.
  Use commas as separators for multiple actions.

• Tags: Labels that are used for easier identification and categorization of alerts.
  Use commas as separators for multiple tags.

• Details > Extra properties: Additional properties of the alert. Enter the name of a property in the first field and its value in the second.

• Entity: The name of the entity that the alert is related to.
  For example, the name of the application or server.

• Priority: The priority of the alert. For example, P1, P2, etc.

• User: The owner of the note that is added to the alert.

• Source: The source of the alert.

• Note: A note to be added to the alert.

Close alert

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. Read more about alert 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.

• Alias: The alias is a unique identifier for "open" alerts.
  There can be only one open alert with the same alias in Jira Service Management.

• User: The owner of the note that is added to the alert.

• Note: A note to be added to the alert.

Acknowledge alert

The 'Acknowledge alert' action acknowledges an existing alert based on its alias if the data matches the condition set of the filter. Read more about alert 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.

• Alias: The alias is a unique identifier for "open" alerts.
  There can be only one open alert with the same alias in Jira Service Management.

• User: The owner of the note that is added to the alert.

• Note: A note to be added to the alert.

Add note to alert

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.

• Alias: The alias is a unique identifier of an alert.

• User: The owner of the note that is added to the alert.

• Note: A note to be added to the alert.

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.