Jira Service Management Connector action reference
- Latest Dynatrace
- Reference
- 5-min read
- Published Jun 18, 2026
The 
Jira Service Management Connector provides the Send alert action for 
Workflows.
Use it to create, update, acknowledge, and close JSM alerts automatically based on Dynatrace data, for example, Problem events.
The action's input fields accept dynamic values through workflow expressions, so you can populate alert fields, such as message, priority, alias, and others, directly from a triggering event, a previous workflow task, or workflow input.
The action also returns a result object that downstream workflow tasks can use.
Send alert
Create, update, acknowledge, and close an alert in Jira Service Management.
Input
| Field | Description | Required |
|---|---|---|
Connection | The preconfigured connection to JSM. | Required |
Message | Summary shown as the alert title in JSM. For workflows with a problem trigger you can use: | Required |
Priority | JSM priority. One of | Required |
State | Controls whether JSM creates, updates, acknowledges, or closes the alert. The default alert-processing rules configured for the Dynatrace integration in JSM are mapped to the following values:
| Optional |
Tags | A comma-separated list of tags to attach to the alert, for example, | Optional |
Alias | Identifier used by JSM to recognize the same alert across updates. Repeated events with the same Alias and the same State are grouped instead of creating duplicates. When using event-based workflow triggers, this is typically an ID.
For workflows with a problem trigger you can use: | Optional |
Note | Free-form text added to the alert. | Optional |
Description | Longer description displayed on the alert detail view in JSM. | Optional |
Responders | People or teams to notify about this alert. This only takes effect if you're using a global integration instead of a team integration.
Provide a JSON array, each entry with an The Example
| Optional |
Actions | The names of the custom actions that should be exposed on the alert in JSM. You can use it to map functionality of outgoing integrations, or callbacks, for example, using JSM Webhooks. Provide an array or a comma-separated list. Defaults to an empty list. | Optional |
Extra Properties | Additional structured context for the alert, which Dynatrace shows in the alert's Extra Properties section. Provide a JSON object of key-value pairs, both of data type string. | Optional |
Entity | Name or ID of the affected entity, shown on the alert in JSM. | Optional |
Custom alert properties | Extra key-value pairs sent along with the alert payload. Use it to provide additional context and fine-tune the content of your alert-processing rules in JSM. You can't override fields that the action already maps with custom alert properties. | Optional |
Output
The Send alert action provides the following result:
| Property | Description |
|---|---|
| The HTTP status code returned by JSM, for example, |
| The HTTP status text, for example, |
| The full response body returned by the JSM Alerts API. |
| The exact alert payload sent to JSM. Use this for debugging or to pass alert data to downstream workflow actions. |
Use this result as input for other workflow actions via workflow expressions.
Examples
Example: Create a P2 alert for a Dynatrace problem in JSM
The following example creates a JSM alert from Davis problem data, using Jinja expressions to populate dynamic fields, assuming a problem trigger and an identified root cause.
| Field | Value |
|---|---|
Message |
|
Priority |
|
State |
|
Tags |
|
Alias |
|
Description |
|
Entity |
|
Using the Alias field with the problem ID ensures that JSM deduplicates subsequent alerts for the same problem rather than creating new alerts.
Example: Assign a JSM team as responder for an alert
The following example sends an alert and assigns a specific JSM team using the Responders field.
| Field | Value |
|---|---|
Message |
|
Priority |
|
State |
|
Responders |
|
Entity |
|
Extra Properties |
|
Example: Pass a dynamic list of tags via Jinja expression
When your input payload contains a list of tags, represented as a JSON strings array, then you can use Jinja expressions to transform it to a single string of comma-separated values.
For example, suppose you reference a primary Grail tag primary_tags.app, which has been enriched for Davis problem events.
{"primary_tags.app": ["payment-frontend", "payment-service"]}
Assuming you use a problem trigger in the workflow, you can use the following Jinja expressions to pass the correct representation to the Tags field of the Send alert action.
Concatenation the values with the join() function, for example:
{{ event()["primary_tags.app"] | join(", ") }}
The result is payment-frontend, payment-service.
Add a prefix, such as app:, to each value:
{{ "app:" ~ (event()["primary_tags.app"] | join(", app:")) }}
The result is app:payment-frontend, app:payment-service.