Routing alerts in Opsgenie using Jira Service Desk custom fields

[#1]

This article explains how you can route alerts in Opsgenie to specific teams using values from custom fields in Jira Service Desk.

Please Note: This document covers only the cloud version of Jira Service Desk.

Sample Scenario

For demonstration purposes, let's consider a scenario where there is a custom field in Jira Service Desk (JSD) which has dropdown fields showing specific teams. When a user creates a ticket in JSD, they will be able to select which team is responsible for actioning the ticket. Let’s say, a ticket was created for printer maintenance. The user selects IT from the custom field “Department”. The goal is to create an alert in Opsgenie and route it to the IT team and alert the on-call engineer.

Instructions

First let's assume that there are teams created in Opsgenie with the corresponding on-call schedules. We will also assume that the JSD integration is set up in Opsgenie and that alerts are successfully created for tickets created in JSD. Here is one way to route alerts based on custom fields. 

1. First, find the ID of the custom field in JSD. If you don't know how to find it, check out this article.

2. Under the "Advanced" tab in the integration options enter the label name and value as shown in the screenshot below. In this case, the value is entered as {{_payload.issue.fields.customfield_10117.value}} where customfield_10117 is the ID of the dropdown field. If your custom field is an array, then you need to retrieve data using format “customfield.get(0)”. For more information on working with string processing methods click here. You can also refer to the dynamic field string processing documentation here.

3. When the above settings are applied, new alerts are created with the custom field values populated under the alert’s extra properties.
4. A screenshot of a sample alert's extra field properties is shown below.
   
5. Once this is achieved, we can now navigate to Opsgenie → Teams →. Select the desired team and define the routing rules. In this example, we want to route alerts created with the “Department” value as “IT” so that it's routed to the IT team.
6. Click on “Add routing rule” under Teams → On-call and then define routing rule as shown below:
7. Once this is saved, the routing rule will look like the screenshot below. Here, if the Department value is IT, Opsgenie will route the alert to the IT team schedule, otherwise the alert will be routed to the team’s default schedule.

[Rumyana Simeonova]

It'd be good if an example is given with the array-type fields.

[Darryl Lee]

As a correction for this post since it's been almost one year ago, there are some changes to fetch the custom fields.

Here is the way I adjust my settings of the Create Alert For Next-Gen Projects rule of my Jira Service Desk Cloud integration to print out the full payload in the Description field by adding the {{_payload}} and extract my text-based custom field, Affected Environment (its ID is 10112) to be added into the extra properties section.

Expression:

{{_payload.issue.fields.customfield_10112}}

And here is the result.

[Amir Katz (Outseer)]

This is a great tip.

I do worry, though, that this is a hack workaround that relies on (I assume) an undocumented entity (_payload). What happens if OpsGenie changes this?

If this is documented, my apologies - please provide a link to the docs.

Either case, this mechanism should definitely be part of the integration configuration screen. I don't expect OpsGenie to retrieve all the CFs from Jira, but a generic field will do.

Since OpsGenie is also an Atlassian product, they should make it simple (I would suggest something like  {{customfield_12345}}) and document it, so everyone will be assured that this is supported going forward.

[Ronnie Kingston]

Hi Amir,

Thanks for your feedback.
With regards to the usage of "_payload" option, this is documented and explained in our public knowledge base here. You can find the details under the heading "Using Raw Parameters From Webhook Url, Payload and Headers".

Regards,
Ronnie

[Amir Katz (Outseer)]

Thanks, @Ronnie Kingston , apologies (as I promised :-)). 

This is really cool and it's great that those extended options are provided (and documented) for advanced users.

[Will Pilcher]

Does any of the above work for the new integration? Can't seem to access any Advanced settings on the Jira Service Management Cloud Integration. Do we have to use the legacy one for this? 

[Darryl Lee]

Hi @Will Pilcher ,

Yes, this workaround is still available on the new framework integration.

On the new framework, you can directly expand Incoming automation rules and click on the Create Alert one to edit it.

On the editing window, click to expand all the fields and you will be able to implement the same workaround here.

Hope this helps.

Kind regards,
Darryl Lee
Support Engineer, Atlassian

[Will Pilcher]

Hi @Darryl Lee thanks for the reply! 

I was on the right path then as I had been attempting the exact method above, but I think I may have to create a support ticket as I am unable to get this working. I have noticed after some attempts that the payload does not have issue= or fields= like you point out, it just goes straight into the default fields (summary etc) then starts listing CFs after customFields=. 

This made me think my expression must be wrong, however if I try a different format to pull this info such as {{_payload.customFields.customfield_00000}} the alert will not even create it seems. Is there any kind of audit log available to be able to see where it's getting stuck? 

[Darryl Lee]

Hi @Will Pilcher ,

Unfortunately, there are no further logs other than Settings > Logs to observe the details.

Since you've created a support request with us, I would suggest staying focused on the ticket to avoid confusion and my colleague will try to help you resolve this.

Kind regards,
Darryl Lee
Support Engineer, Atlassian

[Nick Sommerfeld]

@Will Pilcher - were you able to get this resolve via support? i am seeing the same thing and am curious what the issue is.

[Will Pilcher]

@Nick Sommerfeld sorry for slow reply, not sure if you still need the help here but for reference my issue was just formatting as expected. With help from Atlassian support the answer was to use simply: 

{{customFields.customfield_*****}} 

 So without the _payload.issue.fields at the start. 

[Nick Sommerfeld]

@Will Pilcher - thanks. no worries. using that, i'm getting the full string returned (added ".value" at the end with the same result.

{"self":"https://************.atlassian.net/rest/api/2/customFieldOption/10000","value":"Extensive / Widespread","id":"10000"}

[Tim Geling]

@Nick Sommerfeld did you manage to get this sorted? I am having the same issue.

[Nick Sommerfeld]

@Tim Geling - not yet. i've got a ticket in w/ Atlassian. we'll see what answers i can get. i'll reply here if i get something workable!

[Nick Sommerfeld]

@Tim Geling - was able to get this smart value working with the help of Atlassian Support

{{customFields.customfield_####.value.value}}

replace "####" with your custom field ID.

[Fabian Renner]

Are there any plans of updating this in the documentation? This is no where to be found at the moment