Opsgenie JiraServiceDesk Integration - Assignee
Asked by Wei:

Hi,

When an alert is created in opsgenie, a corresponding Jira Service Desk (cloud) ticket is created. The reporter is an agent I created in jira for this specific purpose.

When a human agent ack's the alert in opsgenie, I see the corresponding ack that moves the JSD ticket to the next step in the workflow.

Is there a way for me to have the assignee of the JSD ticket changed to the user that ack'ed the ticket instead of showing unassigned?

Thanks,

Wei


Answers:
author: Nick H
body: Hi [@Wei](/t5/user/viewprofilepage/user-id/4023799) ,

This functionality is not currently available. I know we have an open feature request for this that I'll certainly add you to though.

As a workaround we've seen customers using automation rules to accomplish this.

You'd first want the integration to add a comment to the issue when an alert is acknowledged:

![auto comm 1.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/127080i8B062270FC932679/image-size/large?v=v2&px=999 "auto comm 1.jpg")

That comment would look like this:

![auto comm 2.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/127084iAEED032AF2DCF879/image-size/large?v=v2&px=999 "auto comm 2.jpg")

You would then add an automation rule that filters on this comment / user's name, and assigns the issue to the corresponding JSM user:

![auto comm 3.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/127083i557A4B8FBF491835/image-size/large?v=v2&px=999 "auto comm 3.jpg")

![auto comm 4.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/127082iF16B2087554AC53A/image-size/large?v=v2&px=999 "auto comm 4.jpg")

You'd have to add an automation rule for each user - so it's not the most robust workaround, but the only real workaround at this time.

Let us know if you have any additional questions!


author: Wei
body: Thanks! I'm no stranger to rube goldberg like automations :).


author: Liron
body: Hi Wei!

This is an interesting question, and actually helps validate a usecase we're building towards within Jira Service Management. In the future, we will have more and more incident response features available right from the Jira Service Management interface and we have been considering that acknowledging first should also assign the incident to that person.

What happens when there are multiple possible responders? Would you still want that behaviour?

Thanks

Liron

comments: author: Wei
body: Hi Liron,

This is great to hear. My "want" in this case is that anyone who visits the Opsgenie dashboard and sees an alert ack'ed versus another party who is looking from the Jira dashboard would see the same assignee at all times.

Thanks!

Wei


author: Liron
body: Yep. Makes sense. Thank you Wei!


author: mitch_b
body: [@Liron](/t5/user/viewprofilepage/user-id/530946) are we any closer to not having to use comments and jira automation to map priorities, assignees, and statuses? This is a compelling reason to switch to pagerduty which seems to do this a lot easier.


author: Nick H
body: Hi [@mitch_b](/t5/user/viewprofilepage/user-id/4899965) ,

The new [JSM framework](https://support.atlassian.com/opsgenie/docs/integrate-opsgenie-with-jira-service-management-cloud/) / [Jira framework](https://support.atlassian.com/opsgenie/docs/use-opsgenie-with-jira-service-management-cloud/) does provide easier mapping of Opsgenie alert priority to JSM / Jira issue priority.

Under these integrations' "*Create and update requests with Opsgenie alerts that are created by other integrations*" section, you can configure multiple outgoing automation rules to map alert priority to issue priority:

![p1.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/202176iDFBEE22DF0621E91/image-size/large?v=v2&px=999 "p1.jpg")![p2.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/202174i27F8EE61402B98D1/image-size/large?v=v2&px=999 "p2.jpg")![p3.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/202175i8D2F931B309C1510/image-size/large?v=v2&px=999 "p3.jpg")

In the example above, the automation is mapping P1 Opsgenie alerts to Blocker - P1 JSM issues.

You'll notice as well there is ability to map a Reporter and Assignee when an Opsgenie alert creates a JSM / Jira issue through the new framework:

![p3.jpg](https://community.atlassian.com/t5/image/serverpage/image-id/202177iD66E90D55E6E0C0A/image-size/large?v=v2&px=999 "p3.jpg")

I'll say this is an improvement from our older JSM / Jira framework, but does lack a bit of functionality at this time as it cannot dynamically map the assignee to the user who ack's the alert at this time.

There is an open feature request for this you can follow, watch and vote for here though: <https://jira.atlassian.com/browse/OPSGENIE-133>

As for updating more JSM / Jira issue statuses, those still require some form of automation. Having said that, the new JSM / Jira framework provides more functionality to include additional Opsgenie alert data is different issue fields. So there should be easier ways to filter an automation on a specific issue field vs. a comment.

~~I'll also get some feature request entered and shared here if we don't already have one that allows for better mapping to JSM / Jira statuses. Couldn't find one with a quick JQL.~~

Here's a feature request I just entered that allows for our new JSM / Jira cloud integrations to transition issues to more statues: <https://jira.atlassian.com/browse/OPSGENIE-605>


Tags: cloud