--- title: "Load incident data | Grafana Cloud documentation" description: "Load incident data from Grafana IRM into workflows as a resource, with automatic loading for incident events and explicit declarations for any workflow." --- > For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt). # Load incident data > Note > > Grafana Workflows is currently in [public preview](/docs/release-life-cycle/). Grafana Labs offers limited support, and breaking changes might occur prior to the feature being made generally available. Incident resources let workflows load full incident data from Grafana IRM and reference individual fields in step inputs. Workflows loads incidents when a run starts, before any steps run. Workflows loads incidents in two ways: - **Automatically** for workflows triggered by incident events - **Explicitly** through the `resources.incidents` section of the workflow definition ## Automatic loading for incident events When a workflow triggers on an incident event (any event matching `grafana_irm_app.incident.*`), Workflows loads the full incident and makes it available under the key `event`: YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml spec: name: Respond to incident startWhen: matchingRules: - eventNameRegex: "grafana_irm_app\\.incident\\..*" steps: - id: notify type: slack.message.post inputs: channelID: "C0123456789" messageText: "Incident ${resources.incident.event.title} is ${resources.incident.event.status} (${resources.incident.event.severity})" ``` You don’t need to configure anything. Workflows reads the incident ID from the event and loads the current incident from Grafana IRM. Automatic loading doesn’t apply when you test a workflow with **Run**. For details, refer to [Test with incident data](#test-with-incident-data). ## Declare incident resources explicitly To load incidents that aren’t part of the triggering event, declare them in the `resources.incidents` section. Each entry maps a reference name to an incident URI using the `incident://id/` scheme: YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml spec: resources: incidents: related: "incident://id/456" current: "incident://id/${inputs.data.incidentID}" ``` Each value must use the `incident://id/` prefix followed by the numeric incident ID. The `id/` segment is required. You can use CEL expressions in the path: - **Literal URIs**: A constant incident URI such as `"incident://id/456"`. - **CEL expressions in the URI**: Use `${expression}` in the path, for example, `"incident://id/${inputs.data.incidentID}"` to pull the ID from the triggering event data. ## Reference incident fields in step inputs To use an incident field in a step input, write `${resources.incident..}`: YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml steps: - id: post-summary type: slack.message.post inputs: channelID: "C0123456789" messageText: | Incident: ${resources.incident.event.title} Status: ${resources.incident.event.status} Severity: ${resources.incident.event.severity} Created: ${resources.incident.event.createdTime} ``` ### Available fields The incident object contains these fields, using camel case names that match the Grafana IRM Incident API: Expand table | Field | Type | Description | |----------------------|--------|------------------------------------------------------| | `incidentID` | string | The incident identifier. | | `title` | string | The incident title. | | `status` | string | Current status, for example, `active` or `resolved`. | | `severity` | string | Severity as shown in IRM, for example, `Critical`. | | `summary` | string | A short recap of the incident. | | `isDrill` | bool | Whether the incident is a drill. | | `createdTime` | string | When the incident was created (RFC 3339). | | `modifiedTime` | string | When the incident was last modified (RFC 3339). | | `closedTime` | string | When the incident was closed (RFC 3339). | | `incidentStart` | string | When the incident began (RFC 3339). | | `incidentEnd` | string | When the incident ended (RFC 3339). | | `durationSeconds` | int | How long the incident has been open. | | `overviewURL` | string | Full URL to the incident overview page. | | `labels` | array | Labels associated with the incident. | | `incidentMembership` | object | People involved in the incident. | | `taskList` | object | Tasks associated with the incident. | | `createdByUser` | object | The user who created the incident. | To match a severity in a condition, use a case-insensitive comparison, for example: text ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```text resources.incident.event.severity.matches('(?i)^critical$') ``` ### Derived fields Workflows adds these fields to the incident: Expand table | Field | Type | Description | |------------------|--------|-----------------------------------------------| | `slackChannelID` | string | Channel ID of the first linked Slack channel. | | `fieldValues` | object | Custom field values keyed by field slug. | | `keyUpdates` | array | The most recent key updates, newest first. | ### Custom field values The `fieldValues` object contains the incident’s [custom field](/docs/grafana-cloud/alerting-and-irm/irm/manage-incidents/customize-incident-response/incident-response-settings/#custom-fields) values, keyed by the field slug. The slug is the stable identifier shown in the field settings, for example, `root_cause` or `debrief_status`. Unset fields aren’t included. YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml steps: - id: check-root-cause type: slack.message.post inputs: channelID: "C0123456789" messageText: "Root cause recorded: ${resources.incident.event.fieldValues.root_cause}" ``` Select field values are strings, and multi-select field values are arrays of strings. Use `has()` in conditions to guard against fields that might be unset: text ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```text has(resources.incident.event.fieldValues.root_cause) ``` ### Key updates The `keyUpdates` array contains the incident’s most recent [key updates](/docs/grafana-cloud/alerting-and-irm/irm/reference/incident-api/reference/#keyupdatesservice), newest first, limited to the 20 latest entries. Each entry includes these fields: Expand table | Field | Type | Description | |------------------|--------|-----------------------------------------------------------------| | `id` | string | The key update identifier. | | `title` | string | The key update title, or `null` if the key update has no title. | | `content` | string | The key update body, rendered as Markdown. | | `createdTime` | string | When the key update was posted (RFC 3339). | | `modifiedTime` | string | When the key update was last edited (RFC 3339). | | `createdBy` | object | The user who posted the key update. | | `lastModifiedBy` | object | The user who last edited the key update. | | `statusID` | string | The incident status ID at the time of the update. | | `severityID` | string | The incident severity ID at the time of the update. | For example, to include the latest key update in a message: YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml steps: - id: post-latest-update type: slack.message.post inputs: channelID: "C0123456789" messageText: "Latest update: ${resources.incident.event.keyUpdates[0].content}" ``` If the incident has no key updates, the array is empty. To check for key updates before you read one, use `size()`: text ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```text size(resources.incident.event.keyUpdates) > 0 ``` ## Combine automatic and explicit resources A workflow can use both automatic and explicit incident resources. When a workflow triggers on an incident event and also declares explicit resources, both are available. If an explicit entry uses the key `event`, it overrides the auto-loaded incident: YAML ![Copy code to clipboard](/media/images/icons/icon-copy-small-2.svg) Copy ```yaml spec: startWhen: matchingRules: - eventNameRegex: "grafana_irm_app\\.incident\\.updated" resources: incidents: related: "incident://id/456" steps: - id: compare type: transform inputs: template: "Event incident: ${resources.incident.event.title}, Related: ${resources.incident.related.title}" ``` In this example, `resources.incident.event` is auto-loaded from the triggering incident event, and `resources.incident.related` is loaded from the explicitly declared ID. ## Test with incident data When a Grafana IRM event triggers a workflow, Workflows loads the incident automatically. When you test with **Run**, it doesn’t, and trigger filters don’t apply. To test a workflow that uses incident data, add the resource yourself: 1. Open the **More** menu, select **Settings**, and select the **Resources** tab. 2. Click **Add Resource**. 3. Set **Type** to **Incident**, **Name** to `event`, and **URI** to `incident://id/${inputs.data.incidentID}`. 4. Click **Save**. Make sure the event data uses the ID of a real incident in your stack. You can keep the resource after you finish testing. When a real event triggers the workflow, it loads the same incident. ## Error handling If Workflows can’t load an incident, for example, because the ID doesn’t exist, the run fails before any steps run. This applies to both auto-loaded and explicitly declared incidents. If Workflows can’t load custom field values or key updates, the run continues. `fieldValues` is an empty object and `keyUpdates` is an empty array. ## Next steps - [Create workflows](/docs/grafana-cloud/platform/workflows/create-workflows) - [Load alert group data](/docs/grafana-cloud/platform/workflows/load-alert-group-data) - [Use CEL expressions](/docs/grafana-cloud/platform/workflows/use-expressions) - [Manage secrets](/docs/grafana-cloud/platform/workflows/manage-secrets) - [Step types reference](/docs/grafana-cloud/platform/workflows/reference)