Overview
A trigger defines how a workflow is started. Every workflow has at least one trigger. Choose the type that matches how you want the workflow to run.
Manual
Started from the app using the Run button. You can provide optional trigger inputs when running. Useful for testing and one-off runs.
API
Exposes an HTTP endpoint that starts the workflow when called. Settings: method – one of GET, POST, PUT, or PATCH. Trigger inputs define request data; the workflow receives them when the endpoint is hit.
Webhook
An incoming webhook URL is generated; a webhook_secret is auto-generated for verification (e.g. for Slack or other services). Use the webhook URL and secret in the external system. When the service sends a request to the URL, the workflow runs with the payload.
Scheduled
Runs on a recurring schedule. All schedule times are in UTC (Coordinated Universal Time)—including interval ticks and specific-time presets (hour of day, day of month, and month). Settings: scheduled_cron with type (min, hour, day, week, month) and interval. Allowed intervals:
- min: 15, 30, 45
- hour: 1, 3, 6, 12, 23
- day: 1, 3, 7
- week: 1, 3, 7
- month: 1, 3, 7, 12
Workflow
Triggered when another workflow completes. Settings: workflow_id – the workflow that, on completion, starts this one. A workflow cannot trigger itself.
Form
Triggered when a form is submitted. Settings: form_id. Submission data is passed to the workflow as trigger inputs.
Version selection for triggers
For runtime automation, non-manual triggers execute the published version of the workflow. For testing, you can run the currently selected workflow version from the editor.
See Workflow Versioning and Publishing for detailed behavior.