How workflows start

Most of the value of an automation is that nobody is present when it runs. A workflow can start in four ways, and one workflow can use more than one: a schedule for the nightly run, and the Run button while you are changing it.

	Starts a run when	Good for
Run	someone presses the button	building, and workflows you supervise
Schedule	the clock says so	reports, syncs, clean-ups
Webhook	something posts to its URL	forms, payments, other systems' events
Incoming mail	new mail lands in a connected mailbox	inboxes that need sorting, attachments to process

Every run is the same kind of run, whatever started it: the same steps, the same log, the same credits.

Pressing Run

The Run button on the canvas starts the workflow once, now. It is how you test while you build, and how you run a workflow that should only go when a person decides.

Pressing Run needs the editor role or above on the workflow. See Teams and roles.

What a trigger hands the first step

A schedule and the Run button start with nothing in hand. A webhook and incoming mail start with what arrived: the request body, or the message. That payload is the first step's output, so the rest of the workflow reads it with variables like any other, for example {{webhook.data.body.orderId}}.

Many runs at once

Runs do not queue behind each other. A webhook that is called ten times in a second starts ten runs, side by side, each with its own payload and its own log. How many steps may run at once is set by your plan.

A schedule is the exception, on purpose: it starts one run per due time, so a slow run cannot pile up copies of itself. See Schedules.