Trigger Nodes
All built-in trigger types, the starting point of every workflow
Every workflow starts with exactly one trigger node. The trigger defines when and how the workflow runs, and what data it passes to downstream nodes.
You can only have one trigger per workflow. To accept input from multiple sources, create separate workflows and call a shared subworkflow from each.
Manual Trigger
Starts the workflow when a user clicks the Run button. Useful during development and for workflows that should run on demand rather than automatically.
No configuration required.
| Output | Type | Description |
|---|---|---|
triggered | boolean | Always true |
triggeredAt | string | ISO 8601 timestamp of when the run started |
Webhook Trigger
Starts the workflow when an external system sends an HTTP POST request to the workflow's webhook URL. The request body is passed as the payload output.
| Input | Required | Description |
|---|---|---|
| Webhook Secret | No | If set, incoming requests must include X-Webhook-Secret: <secret> header. Requests without a matching secret are rejected. |
| Output | Type | Description |
|---|---|---|
payload | object | The parsed JSON body of the incoming POST request |
triggeredAt | string | ISO 8601 timestamp |
The webhook URL is shown in the trigger's configuration panel after you save the workflow. There are separate URLs for Test and Production environments.
Form Trigger
Exposes a public web form that collects structured input from users. When a user submits the form, the workflow runs with the submitted data.
| Input | Required | Description |
|---|---|---|
| Title | Yes | The form's title shown to users |
| Description | No | Subtitle or instruction text displayed below the title |
| Fields | Yes | List of form fields: each has a name, label, type (text, textarea, number, select, checkbox, file), and whether it is required |
| Access | No | Restrict access to signed-in workspace members, or leave open for anyone with the link |
| Output | Type | Description |
|---|---|---|
formData | object | An object containing the values of all submitted form fields, keyed by field name |
submittedAt | string | ISO 8601 timestamp |
submittedBy | string | User ID of the submitter (if access is restricted to workspace members) |
The public form URL is displayed in the trigger configuration after deployment.
Scheduled Trigger
Runs the workflow automatically on a cron schedule. The schedule is defined using standard cron syntax, evaluated in the Europe/Berlin timezone.
| Input | Required | Description |
|---|---|---|
| Cron Expression | Yes | Standard 5-field cron expression, e.g. 0 9 * * 1-5 for weekdays at 09:00 Berlin time |
| Output | Type | Description |
|---|---|---|
triggered | boolean | Always true |
triggeredAt | string | ISO 8601 timestamp of actual execution time |
scheduledTime | string | ISO 8601 timestamp of the scheduled (intended) execution time |
Common cron expressions:
| Schedule | Expression |
|---|---|
| Every hour | 0 * * * * |
| Daily at 08:00 | 0 8 * * * |
| Weekdays at 09:00 | 0 9 * * 1-5 |
| Every Monday at 06:00 | 0 6 * * 1 |
| 1st of month at 00:00 | 0 0 1 * * |
Subworkflow Trigger
Marks this workflow as a callable subworkflow. It can be invoked by a Subworkflow Call node in another workflow. The trigger defines the input parameters the caller must supply, and the outputs that are returned.
| Input | Required | Description |
|---|---|---|
| Input Parameters | No | Define named input fields (with types and descriptions) that the calling workflow must provide |
Outputs are dynamic and defined by the caller via the subworkflow call node's return mapping.
A subworkflow's trigger outputs are the parameters passed in by the parent workflow. They are not visible until the subworkflow is called from another workflow with actual values.