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.

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.

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

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.episodeId in earlier versions), event.ruleId, and event.spaceId.
    • Rule lifecycle triggers in Kibana Universal Alerting provide event.rule.ruleId and event.rule.spaceId.

    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 }}"