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
• Scheduled triggers
• Alert triggers
• Event-driven triggers

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.
• 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 in the experimental alerting system are created, updated, deleted, or have their status changed. 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 the experimental alerting system

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).
  • Alert episode lifecycle triggers provide event.episodeId, event.ruleId, and event.spaceId.
  • Experimental alerting system rule lifecycle triggers 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 }}"