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.

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

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).

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