Triggers

Triggers determine when your workflows start executing. Every workflow must have at least one trigger defined.

A trigger is an event or condition that initiates a workflow. Without a trigger, a workflow remains dormant. Triggers connect workflows to real-world signals, schedules, or user actions.

Triggers also provide initial context to the workflow. For example, a workflow triggered by an alert carries the alert's metadata, entities, and source events. This context shapes how the workflow executes.

To understand whose privileges authorize a triggered run, refer to Workflow authorization.

The following types of triggers are available:

Manual triggers run workflows on-demand through the UI or API. They require explicit user action to start the workflow.

Use manual triggers for:

  • Testing and development
  • One-off data processing tasks
  • Administrative actions
  • Workflows that require a human decision to start

Manual trigger example:

triggers:
  - type: manual

Refer to Manual triggers for more information.

Scheduled triggers run workflows automatically at specific times or intervals. You can configure schedules using:

  • Intervals: Run every x minutes, hours, or days
  • RRule expressions: Run at specific times (for example, daily at 2 AM)

Use scheduled triggers for:

  • Daily reports
  • Regular data cleanup
  • Periodic health checks
  • Scheduled data synchronization

Scheduled trigger example:

triggers:
  - type: scheduled
    with:
      every: 5m

Refer to Scheduled triggers for more information.

Alert triggers run workflows automatically when a detection or alerting rule generates an alert. The workflow receives the full alert context, including all fields and values.

Use alert triggers for:

  • Alert enrichment and triage
  • Automated incident response
  • Case creation and assignment
  • Notification routing based on alert severity

Alert trigger example:

triggers:
  - type: alert

Refer to Alert triggers for more information.

Event-driven triggers run workflows when a platform event occurs:

  • workflows.failed fires when another workflow's execution fails.
  • Cases triggers fire when cases change. The family includes cases.caseCreated, cases.caseUpdated, cases.caseStatusUpdated, cases.attachmentsAdded, and cases.commentsAdded.
  • Entity store triggers fire when an entity's asset criticality or risk score changes in the entity store. The family includes entityStore.entityAssetCriticalityUpdated and entityStore.entityRiskScoreChanged.
  • Alert lifecycle triggers in Kibana Universal Alerting fire when a user takes a triage action on an alert, such as resolving, assigning, acknowledging, or snoozing it.
  • Rule lifecycle triggers in Kibana Universal Alerting fire when someone creates, updates, deletes, enables, or disables a rule. The family includes alerting.ruleCreated, alerting.ruleUpdated, alerting.ruleDeleted, alerting.ruleEnabled, and alerting.ruleDisabled.
  • Elastic Agent Builder triggers fire when a conversation attachment is added, updated, or deleted, or when conversation metadata changes. ai.conversation.updated also fires for other conversation changes, but only for conversation templates that have it turned on. The family includes ai.attachmentAdded, ai.attachmentUpdated, ai.attachmentDeleted, ai.conversation.metadataUpdated, and ai.conversation.updated.

Use event-driven triggers for:

  • Central error-handler workflows that react to failures across your automation
  • Reacting to case lifecycle changes (case opened, status changed, attachments or comments added)
  • Paging on-call, opening cases, or logging when a production workflow fails
  • Auditing rule management actions, syncing rule inventory with external systems, or notifying a channel when rules change in Kibana Universal Alerting
  • Reacting to Elastic Agent Builder conversation attachments, metadata changes, and, for supported conversation templates, new messages and other conversation changes

Event-driven trigger example:

triggers:
  - type: workflows.failed

Refer to Event-driven triggers for more information.

Each trigger type provides different data to the workflow context through the event field:

  • Manual: User information and any parameters passed.

  • Scheduled: Execution time and schedule information.

  • Alert: Complete alert data including fields, severity, and rule information.

  • Event-driven:

    • workflows.failed provides metadata about the failed workflow, its execution, and the step that failed.
    • Cases triggers provide event.caseId, event.owner, and event-specific fields (status changes carry previousStatus and status; attachment events carry IDs and type; comment events carry IDs).
    • Entity store triggers provide event.entityId, event.entityType, and event-specific fields (asset criticality changes carry criticalityLevel; risk score changes carry score, previousScore, delta, and direction).
    • Alert lifecycle triggers in Kibana Universal Alerting provide event.alertId, event.ruleId, and event.spaceId.
    • Rule lifecycle triggers in Kibana Universal Alerting provide event.rule.ruleId and event.rule.spaceId.
    • Elastic Agent Builder triggers provide event.conversationId and event-specific fields. Attachment triggers also provide event.attachmentId, event.attachmentType, and event.source.

    Refer to Event-driven triggers for the full payload shapes.

Access trigger data in your workflow using template variables:

steps:
  - name: logTriggerInfo
    type: console
    with:
      message: "Workflow started at {{ execution.startedAt }}"
      details: "Event data: {{ event | json:2 }}"