Triggers Overview
A trigger is a node that starts a flow. Nothing else in the editor does — a flow with no trigger only ever runs when you press Test or call it by hand. Whatever the trigger receives becomes the run’s$.trigger. Every later step reads from there.
A trigger node is never executed. It carries configuration, not behaviour, so nothing is ever stored under its step ID —
$.trigger.<trigger_id>.field resolves to nothing. Read the trigger payload at $.trigger.<field> and nowhere else.Choosing a trigger
The Add Node panel lists triggers alphabetically. Two more sit under Advanced Features.The Record trigger has no page of its own yet. It fires on record events for a record configuration you select, optionally narrowed to particular event types.
A short way to decide
1
Does a caller need the flow's answer back?
Use HTTP Request or Webhook. Everything else runs detached and returns nothing to whatever set it off.
2
Is the sender a person on your website?
Use an Embed trigger — button, form or chat.
3
Is it a clock?
Use Schedule.
4
Is it mail, a file, or a record change?
Use Email, Upload or Record.
5
Is it another system inside the platform?
Use Stream Message or Message Subject.
What a step can read
Two things that catch everyone
Save is not Publish
The editor has Save, which keeps your edits on the draft, and Publish, which makes them live. They are different flows with different subjects, and a trigger belongs to whichever one was open when you created it. The consequences differ per trigger and are covered on each page. The short version: after you publish, check the trigger is attached to the published flow, not the draft you built it on.Edges are decoration
What runs after the trigger is decided by each step’s outcome, not by the arrows in the editor. A Condition step’s outcome names the step IDs to run next — one, several (they start at the same time), or the reservedRESOLVE_SUCCESS / RESOLVE_ERROR to end the run. A line drawn between two steps that no outcome names does nothing, and an outcome naming a step that is not in the flow fails the run with next step not found.
Delivery
Triggers split into two groups, and the difference matters more than any other property. Request-shaped — HTTP Request, Webhook, and the embeds (which post to an HTTP Request trigger’s URL). The caller holds an open connection, gets a status code and a body, and can retry. Use these where every event has to be accounted for. Fire-and-forget — Schedule, Email, Upload, Record, Stream Message and Message Subject. These arrive as a published message that the platform picks up if it is listening. There is no queue of failed events, no redelivery, and no way to replay one that was missed. A run that errors is not retried either.Several triggers on one flow
A flow can carry more than one trigger node, and each works independently — an HTTP Request trigger and a Schedule trigger on the same flow both start it. Every trigger delivers a different$.trigger shape, so a flow with mixed triggers needs a first step that copes with all of them. A Condition that branches on which keys are present is the usual approach.
Testing
The flow editor’s Test control opens a JSON payload editor and runs the draft flow with whatever you type. It does not simulate a trigger and it does not create a URL — it stands in for$.trigger so you can exercise the steps before wiring anything up.
Runs, whether tested or triggered, appear under Monitoring.
Next Steps
HTTP Request Trigger
Define your own endpoint on a gateway
Webhook Trigger
Take callbacks from an outside service
Schedule Trigger
Run a flow on an interval
Variable Mapping
Reading trigger data in later steps