Create / Close alert based on custom field

[Alexander Frisch]

I connected the Jira Service Management of a customer to OpsGenie. For every JIRA ticket there is an alert being created.

The customer has a custom field for the team that is responsible. Only if its value "Team X" an alert should be created at all.

I found out the ID of the custom field and how to create an extra property:

How do I query this extra property or the custom field in the filter section? If that is not possible can I at least auto-close the alert depending on that value?

Another issue is that this custom field is filled automatically right AFTER the creation of the ticket:

Is that still possible or does the filtering only work if the "Responsible" field is set at the time of the Jira issue creation?

[Nick H]

Hi @Alexander Frisch ,

I don't think this is possible unfortunately, since an integration cannot filter on custom fields to create or close an alert. 

You can determine what statuses, fields, etc. create and close an alert under the integration's Advanced tab, but these fields are set in Opsgenie already and cannot be customized. Note this tab is only available on the Opsgenie Standard and Enterprise plans, or the JSM Premium and Enterprise plans:

Based on your screenshot, I think your plan is either Opsgenie Free / Essentials, or JSM Standard. On these plans, Opsgenie will only try creating alerts when JSM issues are created. Since your custom field is added AFTER the issue is created, I don't think it'd be possible to add the Responsible field into the alert's body.

Otherwise, you could configure this use case under the integration's Advanced tab / Create Alert action(s) to create an alert when the issue is updated:

And parsing the custom field into one of the alert fields.

Apologies if this isn't helpful due to plan restrictions, but let me know if you have any other questions.

[Alexander Frisch]

Thank you for your helpful answer. We certainly use a paid plan but I don't know which one it is and where to check it out (I also do not have the permission to access Atlassian Admin). Here is a screenshot from the integration:

It looks like your workaround shown in the last screenshot is supported.

A few hours ago I also applied for Early Access Program for the new Jira Service Management integration. Will that help me with the use-case?

[Nick H]

Oh great! Didn't realize you sent a screenshot of only the extra properties of one of the actions.

The new framework provides the same existing functionality as the "legacy" (or existing) framework, but still doesn't allow you to filter on a custom field. It may later on as we provide more feedback to engineering since it's still EAP:

Since your plan supports the Advanced tab, you can filter on the webhook event, status, comment author, etc. and tell Opsgenie to create an alert for these issues when they are updated - which is happening due to the automation rule.

Note that the Create Alert actions (and all actions listed an integration) follow an order of operations review the top action first trying to match on the filter / conditions, and will continue through the others until it finds a match.

So you may want to consider moving this action to the top of the list, at least for testing.  

[Alexander Frisch]

Thanks for clarifying the situation with the new EAP integration.

Do I understand the following correctly?

By creating the Alert only on issue_updated which is triggered automatically after the creation of an issue I will be able to display the content of the custom field in the alert.

BUT I still won‘t be able to prevent that alert from being created or from Auto-Closing it based on the value of the custom field.

If that is the case my only option might be to write a small tool myself which hooks in the OpsGenie API and closes these alerts. However, I don‘t think that is worth the effort.

[Nick H]

That is all correct. You can create the issue when its updated (which would happen after the automation rule is run).

And yes - you cannot create / auto-close an alert based on a custom field since it cannot be used in the filter of the create action or close action.

So using the Opsgenie API might be the only option for the use case.