Uploaded image for project: 'Opsgenie'
  1. Opsgenie
  2. OPSGENIE-338

Ability to filter on Jira/JSM custom fields in create alert actions

    • Our product teams collect and evaluate feedback from a number of different sources. To learn more about how we use customer feedback in the planning process, check out our new feature policy.

      Description

      At this time, Jira and JSM integrations can only filter on default fields in the create alert actions. Having the ability to also filter on custom fields in the new framework would add additional flexibility.

      Workaround

      Custom fields can still be extracted from the Jira / JSM payload, typically with something like:

      {{_payload.issue.fields.customfield_12345.value}}
      
      {{_payload.issue.fields.customfield_12345.substringBetween("value=",",")}}

      To see how a custom field parses in the payload, add:

      {{_payload}}

      to the create alert action's Description field. Sometimes the payload will be truncated in the Logs, but should parse entirely in the alert's Description - since it can parse up to 15k characters.

      String processing and regex can be helpful to extract data as well.

      Once you find the dynamic field that extracts the custom field, parse this into one of the create alert action's alert fields - such as an extra property.

      You can then use Alert policies to filter on the extra property, and modify the alert to add a responder, add a tag, etc.

       

          Form Name

            [OPSGENIE-338] Ability to filter on Jira/JSM custom fields in create alert actions

            We at Omnissa are a customer and are also experience this issue. Would be lovely to see it happen!

            Dimitar I. Dimitrov added a comment - We at Omnissa are a customer and are also experience this issue. Would be lovely to see it happen!

            Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            Tobias Bosshard added a comment - Happy New Year, everyone! May it be filled with joy, success, and - who knows - maybe even some miracles. Like Atlassian resolving to fix this bug. We can dream, right?

            At a minimum, we should be able customize incoming alerts by Customer Request Type.  Our development department uses one JSM project for incoming support requests, which we've found is a better end user experience so users don't need to switch portals and admins don't need to maintain consistency across multiple JSM projects.  Since I can't add a condition to filter by Customer Request Type, if I setup a JSM alert it would notify a team for all request types not just the few the team owns.

            We will have to keep our JSM alerts using the legacy integration and system webhooks until this is an option (and we're already at the recommended max of 50 system webhooks).

            I did think about using labels or components to separate out Alerts by team but then I would have to maintain and keep consistent automation rules with alerts. 

            Erica Larson added a comment - At a minimum, we should be able customize incoming alerts by Customer Request Type.  Our development department uses one JSM project for incoming support requests, which we've found is a better end user experience so users don't need to switch portals and admins don't need to maintain consistency across multiple JSM projects.  Since I can't add a condition to filter by Customer Request Type, if I setup a JSM alert it would notify a team for all request types not just the few the team owns. We will have to keep our JSM alerts using the legacy integration and system webhooks until this is an option (and we're already at the recommended max of 50 system webhooks). I did think about using labels or components to separate out Alerts by team but then I would have to maintain and keep consistent automation rules with alerts. 

            Some of the fields for Service Management functions are classed as 'Locked' custom fields, these are needed in Opsgenie for more detailed routing and passing information to the responders.

            David Harkins added a comment - Some of the fields for Service Management functions are classed as 'Locked' custom fields, these are needed in Opsgenie for more detailed routing and passing information to the responders.

              36bd3fea80e3 Makarand Gomashe
              nhaller Nick Haller
              Votes:
              119 Vote for this issue
              Watchers:
              75 Start watching this issue

                Created:
                Updated: