Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 14 Next »

Understand the integration types, advanced settings, alert actions, action filters, and more.

https://support.atlassian.com/opsgenie/docs/the-integration-framework/


The new integration framework is only available for Jira Software Cloud and Jira Service Management Cloud at this moment.

A Jira Service Management integration is a connection between your Jira Service Management account and other apps in your IT environment. When they’re connected, you’ll get alerts from your IT apps, all centralized inside Jira Service Management, and you can also access an alert bucket that’ll be created.

Create custom automation rules for each integration to update and edit data, or take custom actions by triggering the connected apps.

Creating the integration

To create an integration, you must first select Add integration by going to Settings > Integrations. Here you’ll get Jira Service Management’s current integrations. Learn Jira Service Management’s integration types. Currently, Jira Service Management’s new integration framework is only available for Jira Software Cloud and Jira Service Management Cloud, which are highlighted with New tag.

To start setting the integration, select the app:

  • Integration name: Add a name for your integration.

  • Assigned to team: Jira Service Management will set this team as an alert responder. This means that integration will send the alert notifications according to this team’s rules.

  • Connection: This is your connected Jira site. Jira Service Management can automatically detect your connected sites. You can also connect Jira sites manually. Learn how to connect Opsgenie with a Jira Software Cloud ( link )

  • Project: The integration will be triggered with the issues of the selected project. You can select projects from the connected Atlassian sites.

  • Suppress notifications: This mutes notifications. When you mute alert notifications, the responders won’t receive email, SMS or voice notifications.

Saving the settings redirects you to the main integration page where you can set the rules and enable the integration.

Jira Service Management offers two rule sets; Incoming automation rules and Outgoing automation rules.

Incoming automation rules

These rules define how Jira Service Management behaves when it receives data from Jira. In other words, it’s a way to automate the behavior of new or existing alerts when they are triggered by a Jira action. You can acknowledge or update an alert, add a note, close, or create a new alert through Jira issues.

There are five action types to an incoming automation rule. You can set the integration based on these actions and design the alert fields depending on your requirements. Alert fields vary according to the capability of each action. Learn more about dynamic fields.

The action types to the incoming automation rules are:

Ignore alert: Overrides the rules for the selected conditions. Select this option for the actions that you don’t want to receive an alert for.

Create alert: Creates an alert each time your pre-defined action occurs in your Jira project. For example, you can have an alert created for a new issue created in Jira, or when the status of an issue changes. For each action, you can customize the alert Jira Service Management creates. Learn more about action filters.

Close alert: Closes the alert each time your pre-defined action occurs in your Jira project.

Acknowledge alert: Acknowledges the alert each time your pre-defined action occurs in your Jira.

Add note to alert: Adds note to the alert each time your pre-defined action occurs in your Jira.

When you first create the integration we’ll provide some default rules. Unless you disable or delete them, they’ll start working when you enable the integration. These rules are:

  • Create Alert: Whenever a Jira issue is created in your selected project, Jira Service Management creates a new alert.

  • Close Alert: Whenever the Jira issue that created the alert is updated to Resolved, Closed, or Done, Jira Service Management closes the alert.

  • Acknowledge Alert: When the Jira issue that created the alert is updated to ‘Work In Progress’ or ‘Pending’, Jira Service Management acknowledges the alert.

  • Add Note To Alert: Jira Service Management adds a note to the alert when the Jira issue that created the alert receives a comment.

You can edit the default rules or add more rules to an incoming automation. Once you set your rules and enable the integration, Jira Service Management will apply the rule from top to bottom, in its set order. This means that, if your first rule is for “Ignore” action and second is “Create alert”, and, if the data you receive from Jira matches the conditions of both rules, Jira Service Management will stop at the first match – the “Ignore” action. It won’t create an alert.

Outgoing automation rules

Outgoing automation rules define how Jira Service Management alerts affect your Jira project. There are two types of automation rules you can create for an outgoing automation:

Send alert updates to Jira

Choose this rule type to update a Jira issue when the alert triggered by that issue gets an update in Jira Service Management. When an alert is created with an Incoming Automation rule, through an issue created in Jira, and when that alert gets an update, Jira Service Management sends this update information back to Jira and updates the issue. With Send alert updates to Jira rule, you can define how to update the Jira issue according to the rules.

Here, we provide the alert actions and their corresponding Jira actions in a sentence structure. Some actions, such as “a tag is added to alert” might require user input to perform properly. If you leave the input field empty, the rule will apply to all values. If you want to limit the input, enter the values manually, then press Enter. This is similar to how you add tags to an alert.

Create and update Jira issues with Jira Service Management alerts that are created by other integrations

Similar to the previous rule type, you can choose this rule type to trigger a Jira issue with an alert. However, with this option, you’re triggering Jira issues with alerts you received from your other integrated tools.

To define this rule type, first create a filter to choose which alerts you wish to apply this rule for. Then, define properties of the issue you want to trigger. The fields you can edit change depending on the issue type. Later, you can define the actions you want to take for the issue. Later, when Jira Service Management receives an alert matching your filter, it will trigger your Jira to take your chosen action (adding a comment, changing the issue status…etc.). You can enable and disable each of these rules at any time, even when the integration is enabled.

Similar to incoming automation rules, Jira Service Management will apply the rule from top to bottom and stop once it matches with a rule. So, how you order the rules matter. Unlike incoming automation rules, you can order these rules by dragging and dropping.

When you’re done with setting all the rules, enable the integration from top of the page.

Share your feedback

We would love to receive feedback about this documentation, the product experience, functionality, or anything you’ve got to share.

(Simpler: Do you have any feedback about this documentation, your product experience, or any functionality? We'd love to hear from you.)

You can either add comments to this page or add a card on the Trello board.

Criteria for checks

  • Replacing OG with JSM
  • Basic grammar & spell check
  • US English
  • Positive language
  • Removing passive voice (wherever necessary)
  • Simplifying sentences
  • Change V&T
  • Replacing old links and images with new ones
  • Structure of these pages: Do these need to be separate topics? Can it be added /merged with another topic? Does the headline need to revised? Are all the topics + content helpful for our reader?
  • Conceptual validation: Do these journeys, concepts, terms make sense for JSM? Do we need a developer to verify parts of this content?
  • No labels