09 — Workflows: Durable Multi-Step Orchestration

"A visual low-code builder, I think" was my Workflows guess, and it was wrong in the direction that mattered. The correction: a Workflow is not a drag-and-drop canvas — it's TypeScript code that defines a durable, multi-step process whose execution survives failures, with each step checkpointed so it can be retried or resumed without starting over. [1] The durability is the feature; the orchestration is the shape.

The framing that landed is the problem this category solves. A non-trivial backend process — "ingest this file, transform it, call three external APIs in order, write the result, send a notification" — is fragile when written as a single function. If step four fails after steps one through three succeeded, the function either retries from scratch (wasteful, possibly side-effecting) or gives up (work lost). A Workflow makes each step a checkpoint: succeed at step three, fail at step four, and the next run picks up at step four with the outputs of one through three intact [1][2].

Workflows is code, not a canvas

The first correction to my way of thinking: Workflows are authored in TypeScript, the same way a Worker is [1]. I define a class that extends WorkflowEntrypoint, and each step is a method call. There's no drag-and-drop UI in the authoring loop — the "visual" part, if any, is the diagram the platform renders from my code, not the other way around. The reference's "visual, no-code/low-code interface" framing is misleading; the actual authoring experience is typed code with a debugger.

That matters because it changes who Workflows is for. It's not a tool for non-developers to wire up integrations — it's a tool for developers to express long-running, fault-tolerant processes in code they already know how to write, with the platform handling the durability.

Durable execution: steps as checkpoints

The core abstraction is the step. A Workflow is a sequence of steps, and each step is checkpointed — its inputs and outputs are recorded by the platform so that:

• Retries are scoped to the failing step. If step four fails, only step four reruns. Steps one through three don't re-execute, which means their side effects don't either.
• Failures are resumable. A Workflow that fails can be resumed from the last successful checkpoint rather than restarted.
• Long-running is first-class. A Workflow can wait — sleep until a specific time, pause for hours or days — and the platform maintains the state across the wait without holding resources.

This is the category known as "durable execution." The same idea shows up in other ecosystems (Temporal, Airflow, Step Functions); Workflows is Cloudflare's edge-native version of it, with the runtime colocated with the rest of the Workers platform.

Triggers: HTTP, schedule, event

A Workflow instance is created by a trigger [1][2]. The common entry points:

• HTTP request. A Worker receives a request and creates a Workflow instance to handle it — useful when the work is too long or too multi-step for a single request/response.
• Scheduled (cron). A cron trigger fires periodically and kicks off a Workflow — useful for periodic batch jobs, rollups, data syncs.
• Event. A queue message or a webhook can trigger a Workflow — useful for "when this happens, run this multi-step process."

The decoupling between trigger and execution is the point. The trigger creates the instance quickly; the execution runs as long as it needs to, surviving failures and waits.

How Workflows fits alongside Queues and Durable Objects

This was the part I had to think through, because three products all touch "async, stateful, fault-tolerant":

• Queues — fire-and-forget message delivery with retry and DLQ. Best when the unit of work is a single message and the concern is decoupling producer from consumer.
• Durable Objects — single-actor coordination of live concurrent clients. Best when the concern is consistent coordination across clients that are connected _right now_.
• Workflows — durable multi-step orchestration across time. Best when the concern is "this process has many ordered steps, any of which can fail, and I need to survive that without re-running the whole thing."

The decision rule: one message, decouple it → Queues. Many clients, coordinate them now → Durable Objects. Many steps, survive failures across time → Workflows.

How I use this

I reach for Workflows when I have a process with three or more ordered steps where any step can fail and re-running the whole thing would be expensive or side-effecting. The pattern: each external call or meaningful transformation is its own step, so a retry resumes from exactly the boundary that makes sense. For shorter or simpler decoupling, Queues is lighter; for live coordination, Durable Objects is sharper. Workflows earns its complexity when "durable across many steps" is the actual requirement, and not before.

References

[1] Cloudflare, "Cloudflare Workflows," Cloudflare Docs, 2024. [Online]. Available: https://developers.cloudflare.com/workflows/

[2] Cloudflare, "Cloudflare Workflows starter," GitHub, 2024. [Online]. Available: https://github.com/cloudflare/workflows-starter