Work with alert properties
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 a work item 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 work item is created, Jira Service Management gets notified automatically. It creates an alert with the work item’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.
Add or edit alert rules
Rule type: Select the action you want this rule to perform when the rule is run.
Rule name: Name your rule to easily identify it later.
Add filter conditions: You can add alert filters to set the conditions that the alert must match for the rule to run. Filter types:
All the alerts (no conditions in use): No conditions are in effect, so all alerts will cause this rule to run. This is the default setting. Here are the alert filters:
Alerts that match at least one condition: When there are alerts that match one or more conditions, the rule will run and execute the selected action.
Alerts that match all the conditions: When there are alerts that match all the conditions, the rule will run and execute the selected action.
Alert properties
Drag and drop the alert properties available in the Alert properties section to Alert details fields and .
Click + to create a new property. You can also create a custom alert property by typing this syntax directly in the alert detail fields: {{_payload.customField}}, {{_headers.customField}} or {{_url.customField}
Select the Turn on now setting if you want to immediately turn on the rule, and select Add to continue.
You can edit, turn off, and duplicate the rule from More actions.
You can drag and drop the rules within a group to rearrange the order of execution.
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 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 work item, 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?