Workflows
48 step types cover triggers, AI, human decisions, data, logic and communication. Every run is durable: it waits for a decision, with a deadline of up to 365 days or none at all, and resumes exactly where it paused. Retries and error paths are set per step, and transactions span steps.
30-day trial with Pro capabilities · no card required
A run, step by step
A customer order arrives on a signed webhook. The order and its stock reservation are written in one transaction, a failing carrier call takes its error path, and the logistics coordinator decides how the order ships before the confirmation goes out.
Webhook trigger
An order arrives
The storefront calls the workflow's signed webhook. The signature is verified before the run starts.
Transaction
Order and stock are written together
Create the order, reserve stock and log the reservation in one atomic batch.
Integration action
The carrier API times out
Two retries, then the error branch hands the booking to logistics.
Interactive form (a person decides)
Logistics chooses the carrier
Only this order's run waits. Every other order keeps moving.
Assigned to Logistics coordinator (role)
Decision required
Why the run paused: The preferred carrier did not respond to two booking attempts.
Order 1187 · 3 pallets · Rotterdam → Lyon · requested delivery Thursday
Permitted decisions
The decision picks the next branch of this run.
No answer within 4 hours: the expired branch holds the order and notifies the account owner.
PDF · Email
Confirmation goes out
Generate the order confirmation from its document template and email it to the customer.
Run history
Every step is on the trace
Inputs, outputs, the error path taken and the decision stay inspectable in the run's history.
Diagram of a workflow built from shipped step types: a signed webhook trigger, a transaction scope, an integration action with retries and an error branch, a human decision, PDF generation and email. Names and values are sample data.
Want to see this on your own process? Our team will walk through it with you.
Walk through your process with usWhat it does
Start a run from a form submission, a schedule in its own timezone, a date field coming due, a record created, changed or deleted, an event in a connected system, a call from another workflow, or a launch from a screen button or the workflow's webhook.
A run pauses for a person or a timer, for days if needed, then resumes from the same step with its state intact. There is no scheduler, queue or worker for your team to keep alive.
Create, update and delete steps commit in atomic batches keyed to the run, so a retried step never writes the same records twice. Transaction steps group writes from several steps so they commit together or not at all, with business rules enforced inside the same write.
Set retries, continue-on-fail and a dedicated error branch on the steps that need them. When a call to another system fails, the process decides what happens next.
Call typed actions on connected systems or any internet-reachable HTTP endpoint, generate PDFs from document templates, send email and in-app notifications, and answer the caller of a webhook directly.
Each run keeps its trace: what started it, what every step received and returned, where a step failed or took its error path, and who decided what. Record changes the run's data steps make are audited in the same transaction as the write, under the workflow's identity, with the old and new value of each changed field.
Under the hood
The mechanisms behind the page, for the architects and security reviewers evaluating it.
Read the technical documentation7 triggers, 10 AI steps, 4 human-in-the-loop steps, 11 data steps and 16 logic, flow and output steps, including if, filter, switch, merge, wait, sub-workflows, respondToCaller, httpRequest, integrationAction, generatePdf, email and in-app notifications: 48 in all.
Runs execute on Cloudflare Workflows in the Production environment. Execution history is retained for 30 days, with step inputs and outputs stored as previews truncated at 10 KB by default. Schedules are timezone-aware with a five-minute minimum interval. On Pro, owners and admins can restore an earlier workflow version as a draft.
retryOnFail, maxRetries (up to 10), continueOnFail and an error output are configured per step. Step-level retries happen only where you configure them; inside a step, some provider calls retry transient rate-limit or server errors on their own. Each atomic batch holds up to 100 record writes, and a larger write step commits in consecutive batches. Transaction steps collect up to 100 writes across steps into one atomic batch.
Automation Runs = max(1, ceil(billable Actions / 20)). One step execution is one Action, and a step that runs once per item counts one Action per item. Retries that reach a provider and AI model or tool calls also count; triggers and skipped steps do not. Standard includes 2,500 Runs a month and Pro 15,000.
Designed boundaries
A transaction cannot span a pause for a person or a timer. Place the decision before or after the writes it governs.
Webhook traffic is rate-limited per workspace and per endpoint to protect the runs behind it.
Read the technical documentationWorkflows run in Production and are metered in published Automation Runs; AI steps also use AI credit. In Development you build and review changes without running them.
See how usage is meteredAvailability
Questions buyers ask
One Automation Run covers up to 20 billable Actions: Runs = max(1, ceil(billable Actions / 20)). Each step execution is an Action, and a step that runs once per item counts one per item; retries that reach a provider and AI model or tool calls also count. Triggers are not billed. Capacity packs and a Wallet cover growth; an empty Wallet stops new over-capacity runs rather than creating a surprise charge.
Step retries run only where you turn them on. Each step can retry up to the count you set, continue on failure or route to an error branch; a step with none of these stops the run and records the error. Create, update and delete steps are keyed to the run, so a retried write never lands twice. Some provider calls also retry transient rate-limit or server errors inside the step.
Yes. A human-task step assigns the decision to a user or role, shows them a form with the context you configure and suspends the run until they answer. You can set a deadline from one hour to 365 days, or none. A submitted answer continues the run on its submitted branch. If the expiry you set passes first, the run follows its expired branch, such as holding the order and notifying the account owner.
Yes: through a webhook on the workflow's launch trigger, which can require an HMAC signature, basic or header auth; through an event from a connected provider; or by creating or changing a record through the Data API, which fires a data-change trigger. A webhook caller can also get a synchronous reply from the run within 60 seconds.
Writes inside a transaction scope commit together or not at all. Create, update and delete steps are keyed to the run, so a retried step never writes the same records twice. Writes committed before the failure stay in place. If the failing step has an error branch, that branch decides what happens next; otherwise the run stops and records the error.
Next step
We'll walk through the triggers, the exceptions and the decisions, and show you where the run holds and where it asks a person.
