--- title: "Create Jira issue for incident follow-ups | Grafana Cloud documentation" description: "When a critical or major incident is resolved, open a Jira issue to track follow-up work and link it on the incident timeline." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt). # Create Jira issue for incident follow-ups > Note > > Grafana Workflows is currently in [public preview](https://grafana.com/docs/release-life-cycle/). Grafana Labs offers limited support, and breaking changes might occur prior to the feature being made generally available. When a critical or major incident is resolved, open a Jira issue to track follow-up work and link it on the incident timeline. This Grafana Workflows blueprint is in the **Integrations** category of the Blueprints library. ## Before you begin To use this blueprint, you need: - Grafana IRM set up on your stack. - A workflow secret named `jira-api-token`. To create a secret, refer to [Manage secrets](https://grafana.com/docs/grafana-cloud/platform/workflows/manage/secrets). ## Steps Steps run in order from first to last. A step inside a switch branch runs only when Workflows chooses that branch. Expand table | Step | ID | Type | Description | |-----------------------------------|-----------------|---------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Create the Jira issue | `create-issue` | `http.call` | Creates a follow-up issue. Replace `your-company.atlassian.net` with your Jira site, set `authUsername` to the Jira account email that owns the API token, and set the project key in the body. Also create a workflow secret named jira-api-token that holds a Jira API token. Change the issue type or labels if needed. | | Fail if the issue was not created | `check-created` | `filter` | Fails the run with an error when Jira does not create the issue. No changes needed. | | Link the issue on the incident | `link-issue` | `incident.add-note` | Adds a link to the new Jira issue on the incident timeline. No changes needed. | For the inputs and outputs of each step type, refer to [Step and trigger types reference](https://grafana.com/docs/grafana-cloud/platform/workflows/reference/step-trigger-types). Before you turn on the workflow, customize any steps that need input from you, such as a channel ID or a schedule name. Each step’s description says what to set. ## Workflow definition Save this definition as a YAML file to create the workflow with gcx, the Workflows API, or Terraform, or give it to a coding agent as an example. Replace *FOLDER\_UID* with the UID of the folder for the workflow. Blueprints start disabled, so finish customizing the steps before you set `enabled` to `true`. For details, refer to [Manage workflows as code](https://grafana.com/docs/grafana-cloud/platform/workflows/as-code). YAML ![Copy code to clipboard](https://grafana.com/media/images/icons/icon-copy-small-2.svg) Copy ```yaml apiVersion: workflows.ext.grafana.app/v1alpha1 kind: Definition metadata: name: create-jira-issue-for-incident annotations: grafana.app/folder: spec: name: Create Jira issue for incident follow-ups enabled: false runOnceFor: 'jira:${inputs.data.incidentID}' startWhen: matchingRules: - eventNameRegex: 'grafana_irm_app\.incident\.updated' filter: "inputs.data.eventKind == 'incident_updated_status' && inputs.data.newStatus == 'resolved' && resources.incident.event.severity.matches('(?i)^(critical|major)$') && !resources.incident.event.isDrill" schedules: [] resources: secrets: jiraApiToken: 'secret://jira-api-token' steps: - id: create-issue type: http.call name: Create the Jira issue description: >- Creates a follow-up issue. Replace your-company.atlassian.net with your Jira site, set authUsername to the Jira account email that owns the API token, and set the project key in the body. Also create a workflow secret named jira-api-token that holds a Jira API token. Change the issue type or labels if needed. inputs: method: 'POST' url: 'https://your-company.atlassian.net/rest/api/2/issue' headers: '["Accept: application/json"]' body: | { "fields": { "project": { "key": "" }, "issuetype": { "name": "Task" }, "summary": ${json_stringify('Follow-ups for incident ' + inputs.data.incidentID + ': ' + resources.incident.event.title)}, "description": ${json_stringify('Incident: ' + resources.incident.event.overviewURL + '\nSeverity: ' + resources.incident.event.severity + '\n\n' + resources.incident.event.summary)}, "labels": [ "incident-follow-up" ] } } authMethod: 'basic' authUsername: '' authPassword: '${resources.secret.jiraApiToken}' - id: check-created type: filter name: Fail if the issue was not created description: Fails the run with an error when Jira does not create the issue. No changes needed. inputs: condition: "steps['create-issue'].outputs.responseCode == 201" failOnExit: 'true' - id: link-issue type: incident.add-note name: Link the issue on the incident description: Adds a link to the new Jira issue on the incident timeline. No changes needed. inputs: incidentID: '${inputs.data.incidentID}' message: "Follow-up work is tracked in Jira issue ${json_parse(steps['create-issue'].outputs.responseBody).key}." ``` ## How it works This section explains when the workflow runs and how its steps work together. ### When it runs This blueprint starts on the `grafana_irm_app.incident.updated` event. Its trigger filter starts a run only when this CEL expression is true: text ![Copy code to clipboard](https://grafana.com/media/images/icons/icon-copy-small-2.svg) Copy ```text inputs.data.eventKind == 'incident_updated_status' && inputs.data.newStatus == 'resolved' && resources.incident.event.severity.matches('(?i)^(critical|major)$') && !resources.incident.event.isDrill ``` It runs at most once for each run-once key. This blueprint’s key is `jira:${inputs.data.incidentID}`, so a later event with the same key doesn’t start another run. For details, refer to [Deduplicate workflow runs](https://grafana.com/docs/grafana-cloud/platform/workflows/build/triggers/#deduplicate-workflow-runs). ### How the steps fit together These notes cover how the steps connect and which Workflows behaviors the blueprint relies on. - Triggers on `eventKind` `incident_updated_status` when `newStatus` is resolved, filtered in the trigger to Critical and Major incidents that are not drills. - `runOnceFor` keys on the incident ID, so you get one issue per incident. - `http.call` uses basic auth. - `authUsername` is the Jira account email and `authPassword` references a Jira API token stored as a workflow secret. - Both are `secretString` parameters, so their values are redacted from run history. - The body uses the Jira REST API v2 issue format, because v2 accepts a plain-text description. - Every dynamic value goes through `json_stringify()` to stay valid JSON. - A filter with `failOnExit` fails the run unless Jira returns 201. - The last step reads the new issue key with json\_parse(steps\[‘create-issue’].outputs.responseBody).key. - Customize the Jira site in the URL, the account email, the project key, the issue type, and the labels. ## Next steps - [Blueprints](https://grafana.com/docs/grafana-cloud/platform/workflows/reference/blueprints) - [Start from a blueprint](https://grafana.com/docs/grafana-cloud/platform/workflows/build/use-blueprints) - [Manage workflows as code](https://grafana.com/docs/grafana-cloud/platform/workflows/as-code) - [Step and trigger types reference](https://grafana.com/docs/grafana-cloud/platform/workflows/reference/step-trigger-types)