Documentation Grafana Cloud Platform Workflows Load incident data

Load incident data

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

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.

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

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.<KEY>.<FIELD>}:

YAML Copy

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:

To match a severity in a condition, use a case-insensitive comparison, for example:

text Copy

resources.incident.event.severity.matches('(?i)^critical$')

Derived fields

Workflows adds these fields to the incident:

Custom field values

The fieldValues object contains the incident’s custom field 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

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

has(resources.incident.event.fieldValues.root_cause)

Key updates

The keyUpdates array contains the incident’s most recent key updates, newest first, limited to the 20 latest entries. Each entry includes these fields:

For example, to include the latest key update in a message:

YAML Copy

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

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

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
• Load alert group data
• Use CEL expressions
• Manage secrets
• Step types reference