Jira Service Management parses your data to construct rich and informative alerts. You can use dynamic fields to customize alert properties and alert conditions.
Dynamic (draggable) fields
Draggable fields bring significant data for creating and managing well-informed alerts. The integration framework provides different dynamic fields specific to the integrated application. You can use dynamic fields in the filters of your integration actions as well as alert fields. In the filter, fields are available to select in the condition drop-down. In the alert properties, you can drag a dynamic field into any input you find appropriate.
Jira Service Management interprets the expressions within the double-curly braces as dynamic fields. Dynamic data populates at every notification that's sent to Jira Service Management. For example, someone creates an issue in Jira and enters "This is the summary" for the summary. Using Jira Service Management’s Jira integration, "[Jira] {{summary}}" for Message in a 'Create alert' Action creates an alert with the message "[Jira] This is the summary". It will then notify the users. All we needed to do is drag {{summary}} to the message. When the issue is created, Jira Service Management get notified automatically. It creates an alert with the issue's summary in the message.
You can mix static text with dynamic fields. In the example above, the "[Jira] " in "[Jira] {{summary}}" is static and it'll be at the beginning of the message for every new alert. "{{summary}}" can be different for each alert.
Using raw parameters from webhook URL, payload, and headers
You can insert URL parameters or http payload parameters from webhooks directly into your alerts. For example, an integrated application sends a variable named timestamp to Jira Service Management in the webhook payload. But timestamp isn't available as a draggable field in the configuration page. If you still need to use timestamp in your alerts, you can add {{_payload.timestamp}}
to the input fields.
Nested payload variables are accessible as well. In the example, we could also use _payload.issue.fields.environment to access the following value that is in the http body of the webhook:
{ "issue" : { "fields" : { "environment" : "env_val" } } }
The URL query parameters of a webhook are also accessible via {{_url.param}}
where param is the parameter key. You can add custom parameters to the webhook URL and inject it into your alerts. For example, suppose you're using Jira Service Management’s Stackdriver integration. You're monitoring many projects and want to use a single integration for all your alerts. If you still want to distinguish which alert belongs to which domain, you can use a custom parameter for each of your projects.
You can add your custom parameter to the webhook URL of the Stackdriver integration. For example: ¶m1=val1, and insert {{_url.param1}}
in the integration config to access it. Headers of a webhook request are also available via {{_headers.param}}
where param is the name of the header. You can use all the headers of a request in your alert fields.
For email-based integrations, you can use headers of an email via {{_headers.PARAM1}} notation and {{_headers.IMPORTANCE}} in the alert fields. Use UPPER CASE letters for the keys.
To control your alert fields further, you can use string processing methods on dynamic fields. For example, an Integration has an 'Add Note' action, and Note is configured as "note: {{comment_body.substringAfter("is")}}".
Now when someone in the integrated application adds "This is the comment" as a comment to the issue, a note is added to the corresponding lert, with the text "note: the comment". Learn more about string processing methods.
0 Comments