Work with alert properties
This article highlights a new alerting feature that's natively available in Jira Service Management which is gradually rolling out to some Jira Service Management Cloud customers. It may not yet be visible or available on your site.
Jira Service Management parses your data to construct rich and informative alerts. You can use custom alert properties to tailor your alerts and alert conditions.
Draggable alert properties
Draggable alert properties bring significant data for creating and managing well-informed alerts. The integration framework provides different alert properties specific to the integrated application. You can use custom alert properties in the filters of your integration actions as well as alert fields. In the filter, custom alert properties are available to select in the condition drop-down. In the alert properties, you can drag a custom alert property into any alert field you find appropriate.
Jira Service Management interprets the expressions within the double-curly braces as custom alert properties. Custom 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 custom alert 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:
1
2
3
4
5
6
7
{
"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 Google Cloud Operations Suite 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.alert
You can add your custom parameter to the webhook URL of the Google Cloud Operations Suite 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 alert 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.
Integrations that don’t support alert properties
api
apica
appsignal-v2
atatus
blue-matador
circleci
cloudspoint
consul
detectify
dnscheck
dripstat
dynatrace
grafana-v2
graylog
humio
instana
jec
kapacitor
logstash
loom
nagios-legacy
nagios-xi-legacy
oec
opsdash
prometheus
riemann
rigor
sematext-spm
sensu
sentry
servicenow-legacy-v1
signal-sciences
signalfx-v2
solarwinds-db-performance-monitor
stack-storm
thundra
tideways
trace-by-risingstack
track-it
uptime-project
whatsup-gold
workato
xl-release
xmpp
zapier
Was this helpful?