Overview
A workflow consists of:- Trigger — What starts the workflow (event, schedule, manual, or webhook)
- Steps — An ordered list of operations with branching and control flow
- Instances — Each execution creates a trackable instance with step-by-step logs
Key Features
- Four Trigger Types: Event, schedule, manual, and webhook
- Seven Step Types: Action, condition, wait_delay, wait_condition, wait_event, loop, parallel
- Instance Tracking: Monitor running workflows with status, step logs, and error details
- Cancel and Resume: Cancel running workflows or resume failed ones
- Template Variables: Access trigger data and previous step outputs in any step
Trigger Types
Event Triggers
Fire when a record or auth event occurs:records.create, records.update, records.delete, auth.login, auth.register
Schedule Triggers
Fire on a cron schedule:Manual Triggers
Fire only via explicit API call:Webhook Triggers
Fire via an unauthenticated HTTP POST with a secret token:Step Types
Steps are defined as an ordered list. Each step has a uniquename and a type.
Action
Execute an operation (same action types as API-Defined Hooks):send_webhook, send_email, create_record, update_record, delete_record, enqueue_job.
Condition
Branch based on a rule expression:{"result": true, "branch": "true"} or {"result": false, "branch": "false"}
Wait Delay
Pause execution for a specified duration:<number><unit> where unit is s (seconds), m (minutes), h (hours), or d (days).
The workflow instance transitions to waiting status. A background job resumes it after the delay.
Loop
Iterate over a list, executing a step for each item:{"items_count": 3, "outputs": [...]}
Parallel
Execute multiple branches concurrently:{"branch_results": [[...], [...], [...]]}
If any branch fails, the entire parallel step fails.
Wait Condition / Wait Event
wait_condition and wait_event step types are defined in the schema but not yet implemented. They are skipped during execution.