Event-driven triggers

Event-driven triggers let workflows react to events elsewhere in Kibana. Four trigger families are available:

• workflows.failed — Fires when another workflow's execution fails.
• Cases triggers — Fire when cases change (created, updated, status changed, attachments added, comments added).
• Alert episode lifecycle triggers — Fire when an alert episode changes state in the experimental alerting system, such as when it is activated, assigned, acknowledged, or snoozed.
• Experimental alerting system rule lifecycle triggers — Fire when rules are created, updated, deleted, enabled, or disabled in the experimental alerting system.

Schema convention. In each schema table on this page, the Location column indicates where each parameter sits in the YAML:

• top level: Alongside type and name, at the top of the step or trigger definition.
• `with`: Inside the step's with: block.
• `on`: Inside the trigger's on: block.

Fires when any workflow execution reaches the failed terminal state. Use this trigger to build handler workflows that react to failures in your production workflows, for example by paging on-call, opening a case, or logging to a dedicated index for observability.

triggers:
  - type: workflows.failed
		

Use on.condition to narrow which failed executions trigger the handler. The value is a KQL predicate evaluated against the event payload.

Fire only on failures from a specific workflow:

triggers:
  - type: workflows.failed
    on:
      condition: "event.workflow.name : 'ops--rollback-deployment'"
		

Ignore failures that came from another error handler:

triggers:
  - type: workflows.failed
    on:
      condition: "event.workflow.isErrorHandler : false"
		

Combine conditions with KQL's and to filter on multiple fields:

triggers:
  - type: workflows.failed
    on:
      condition: "event.workflow.isErrorHandler : false and event.workflow.spaceId : 'production'"
		

When a failed workflow triggers your handler, the handler runs with an event context that describes the failure. The payload has four groups: workflow, execution, error, and the top-level timestamp and spaceId.

Reference these fields with Liquid templating inside the handler:

- name: log_failure
  type: console
  with:
    message: |
      Workflow {{ event.workflow.name }} (id: {{ event.workflow.id }}) failed
      at step {{ event.error.stepName }}: {{ event.error.message }}
		

name: handle-critical-workflow-failures
description: Page on-call and open a case whenever a critical workflow fails.
enabled: true

triggers:
  - type: workflows.failed

steps:
  - name: skip_if_handler
    type: if
    condition: "event.workflow.isErrorHandler : true"
    steps:
      - name: no_op
        type: console
        with:
          message: "Skipping: the failure came from another error handler."

  - name: page_oncall
    if: "not event.workflow.isErrorHandler"
    type: pagerduty.triggerIncident
    connector-id: "platform-pagerduty"
    with:
      dedup_key: "{{ event.workflow.id }}-{{ event.execution.id }}"
      summary: "Workflow {{ event.workflow.name }} failed"
      severity: "critical"
      details:
        failed_step: "{{ event.error.stepName }}"
        error: "{{ event.error.message }}"
        workflow_id: "{{ event.workflow.id }}"
        execution_id: "{{ event.execution.id }}"

  - name: open_case
    if: "not event.workflow.isErrorHandler"
    type: cases.createCase
    with:
      title: "[Auto] Workflow failure: {{ event.workflow.name }}"
      description: |
        Step `{{ event.error.stepName }}` failed.

        Error: `{{ event.error.message }}`
      severity: "high"
      tags: ["workflow-failure", "auto-triage"]
		

Cases triggers fire when cases change. Use them to react to case lifecycle events without polling the Cases API.

Shared payload. Every cases trigger event includes:

• event.caseId — The case ID, the alphanumeric identifier that is unique to each case.
• event.owner — The solution that owns the case. It can be securitySolution for Elastic Security cases, observability for Observability cases, or cases for Stack cases.

Use event.owner in on.condition to filter by solution. For example, a workflow that only fires for Elastic Security cases:

triggers:
  - type: cases.caseCreated
    on:
      condition: 'event.owner: "securitySolution"'
		

Individual trigger sections below document any additional payload fields specific to that event.

Fires when a case is created.

Fire only for Elastic Security cases:

triggers:
  - type: cases.caseCreated
    on:
      condition: 'event.owner: "securitySolution"'
		

Fires when a case is updated. The event.updatedFields array lists which fields changed.

This trigger also fires when a case's status changes; the dedicated cases.caseStatusUpdated trigger fires alongside it and carries the previous status for easier filtering. For bulk updates, cases.caseUpdated fires once per case.

Fire when a Elastic Security case's title changes:

triggers:
  - type: cases.caseUpdated
    on:
      condition: 'event.owner: "securitySolution" and event.updatedFields: "title"'
		

Fires when a case's status changes.

Fire when a Elastic Security case is closed:

triggers:
  - type: cases.caseStatusUpdated
    on:
      condition: 'event.owner: "securitySolution" and event.status: "closed"'
		

Fires when attachments are added to a case. If attachments of multiple types are added in one operation (for example, three alerts and two comments), the trigger fires once per type, with one event for each type.

Adding a comment fires both this trigger (with event.attachmentType: "comment") and the dedicated cases.commentsAdded trigger. Both exist because users don't always think of comments as attachments.

Fire only for Elastic Security cases:

triggers:
  - type: cases.attachmentsAdded
    on:
      condition: 'event.owner: "securitySolution"'
		

Fire only when a comment-type attachment is added:

triggers:
  - type: cases.attachmentsAdded
    on:
      condition: 'event.attachmentType: "comment"'
		

Fires when comments are added to a case.

Fire only for Elastic Security cases:

triggers:
  - type: cases.commentsAdded
    on:
      condition: 'event.owner: "securitySolution"'
		

Alert episode lifecycle triggers fire when an alert episode changes state in the experimental alerting system. Unlike workflows.failed and cases triggers, they are not configured through a triggers block in your workflow YAML. They are emitted by the alerting system and automatically invoke any workflow attached to the matching trigger type. Each trigger fires exactly once per state change. There is no polling interval or frequency gate.

All lifecycle triggers include these common fields in the event payload.

Reference these fields with Liquid templating in workflow steps:

- name: log
  type: console
  with:
    message: |
      Episode {{ event.episodeId }} from rule {{ event.ruleId }} changed state.
		

Use these fields to write workflow conditions that scope the automation to specific rules or episodes. For example, use event.ruleId: "my-rule-id" to scope the workflow to alert episodes from a specific rule.

Experimental alerting system rule lifecycle triggers fire when rules are created, updated, deleted, enabled, or disabled in the experimental alerting system. Use them to automate responses to rule management actions, for example, auditing rule changes, syncing rule inventory with an external CMDB, or notifying a team channel when a new rule is added to a space.

Rule lifecycle triggers are part of the experimental alerting system and fire independently of alert episodes.

For bulk operations (bulk enable, bulk disable, bulk delete), one trigger event is emitted for each affected rule.

triggers:
  - type: alerting.ruleCreated
  - type: alerting.ruleUpdated
  - type: alerting.ruleDeleted
  - type: alerting.ruleEnabled
  - type: alerting.ruleDisabled
		

All rule lifecycle triggers share the same minimal payload.

Reference these fields with Liquid templating in workflow steps:

- name: log_rule_event
  type: console
  with:
    message: |
      Rule {{ event.rule.ruleId }} changed in space {{ event.rule.spaceId }}.
		

Use on.condition to scope the trigger to a specific rule or space:

triggers:
  - type: alerting.ruleCreated
    on:
      condition: 'event.rule.spaceId: "production"'
		

name: audit-rule-changes
description: Log rule lifecycle events across all spaces.
enabled: true

triggers:
  - type: alerting.ruleCreated
  - type: alerting.ruleUpdated
  - type: alerting.ruleDeleted
  - type: alerting.ruleEnabled
  - type: alerting.ruleDisabled

steps:
  - name: log_change
    type: console
    with:
      message: |
        Rule {{ event.rule.ruleId }} in space {{ event.rule.spaceId }} — trigger: {{ trigger.type }}
		

This section applies to workflows.failed handlers. Alert episode lifecycle triggers fire once per state change and do not re-trigger on workflow failure.

If a handler workflow itself fails, it can re-trigger itself. Two safeguards help you avoid infinite loops:

• Every event includes event.workflow.isErrorHandler, which is true when the failing workflow is itself a handler. Filter on this in your handler's logic to skip handling your own failures.
• The execution engine enforces a chain-depth limit on cascading event-driven triggers as a safety net.

In practice, keep handler workflows simpler than the workflows they monitor. A handler that only logs, opens a case, and notifies is less likely to fail than the automation it's handling.

• Triggers overview: All trigger types.
• Workflow authorization: Whose privileges event-driven workflows run with.
• Pass data and handle errors: Per-step on-failure strategies complement event-driven handlers.
• Cases steps: Open cases from your handler.
• Connect workflows to the experimental alerting system: Full reference for alert episode lifecycle triggers, including available trigger IDs, event payload fields, and when to use lifecycle triggers versus action policies.