Work with dynamic properties

1 Overview
2 Dynamic (draggable) properties
3 Using raw parameters from webhook URL, payload, and headers

Overview

Jira Service Management parses your data to construct rich and informative alerts. You can use dynamic properties to customize your alerts and alert conditions.

Dynamic (draggable) properties

Draggable properties bring significant data for creating and managing well-informed alerts. The integration framework provides different dynamic properties specific to the integrated application. You can use dynamic properties in the filters of your integration actions as well as alert fields. In the filter, dynamic properties are available to select in the condition drop-down. In the alert properties, you can drag a dynamic property into any alert field you find appropriate.

Jira Service Management interprets the expressions within the double-curly braces as dynamic properties. 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 gets notified automatically. It creates an alert with the issue's summary in the message.

You can mix static text with dynamic properties. 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 property in the configuration page. If you still need to use timestamp in your alerts, you can add {{_payload.timestamp}} to the input field.

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 properties. 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 alert, with the text "note: the comment". Read more about string processing methods.