A workflow editor needs a separate answer to “what happens after failure?”

Consider a workflow that prepares a customer message, waits for approval and sends it. Drawing those three steps is straightforward. The harder decisions appear when the approver returns tomorrow, the sender times out, or someone edits the draft while an earlier run is waiting. A workflow editor lets people express a process. A runtime needs rules for carrying out a particular version of that process through interruptions. Evaluate those responsibilities separately, including when one starter project supplies code for both.

By world of creator · Reviewed 2026-10-04

Keep the draft, the published definition and the run distinct

A useful design exercise starts with three records. The draft stores what someone is editing. A published definition records the version permitted to run. A run records what happened when that version received particular input. This is a proposed application model, not a requirement imposed by every library.

The separation answers a concrete question: if an editor changes a branch condition while yesterday's run waits for approval, which condition should that run use? Decide the policy before connecting the editor's save event directly to execution. Also decide who can publish, who can trigger a run, and which service checks those permissions.

Positions, zoom and collapsed panels help a person understand a diagram. They should not accidentally determine business outcomes. Give the execution definition explicit step types, inputs, transitions and failure rules so the server can validate meaning independently of the current browser view.

Three similarly discussed tools start at different places

React Flow provides node-and-edge editing primitives. It supports custom React nodes and connection validation callbacks, which are useful places to express your rules. An allowed connection does not by itself establish that an entire process is executable, authorized or recoverable. Custom nodes, connection validation.

Workflow Builder at workflowbuilder.io packages an editor SDK around React Flow. Its architecture documentation separates that package from optional backend, execution-core and worker applications. The SDK emits workflow definitions; the consuming application chooses what executes them. Its optional Flow Runner can execute node functions in the editor, so saying it “cannot execute” would also be inaccurate. The question is which execution guarantees your chosen integration provides. Workflow Builder architecture, Flow Runner.

Vercel Labs' Workflow Builder is a different product: an application template whose documented stack includes a React Flow canvas and Workflow SDK. Its source and setup instructions let you inspect that assembly. It should not be compared with workflowbuilder.io as though the two names described editions of one SDK. Vercel template, template repository.

Trace one interrupted run before adding more nodes

Use the customer-message example as a review fixture. Start a run, close the browser during approval, then return. Require the application to identify the same run and show the stored state. Next, change the draft while the run waits. Verify that the displayed definition and execution follow your chosen version policy.

Then simulate a sender that accepts a request but loses its response. The application sees failure, while the external service may already have done the work. Retrying safely requires coordination with that service's duplicate-handling mechanism. A green node animation cannot resolve the uncertainty.

Workflow SDK documents persisted step results and resumable orchestration. Its retry guidance also explicitly warns that external effects need idempotency: repeated attempts should not create repeated intended effects. Durability helps preserve progress; the application still has to use the receiving system's guarantees correctly. Workflows and steps, retry guidance, idempotency.

Keep these exercises small. One approval, one external action and one deliberate failure will tell you more about the execution boundary than a demonstration containing dozens of successful integrations.

Make the results panel accountable

For the proposed model, attach results to a run identifier and definition version. Show which step is waiting, which failed, and which path was not selected. Distinguish an attempted action from a confirmed result when the external system leaves that uncertain.

Decide what Stop means. It might prevent future steps, request cancellation from an active operation, or simply stop displaying progress. Those are different user promises. Describe the implemented one in the interface and retain enough evidence to explain it later.

Likewise, Retry needs a scope. A user may intend to repeat only a failed message, while a naive implementation starts the entire process again. A retry action should make that choice visible before it creates another side effect. These are product acceptance criteria, not features established merely by choosing a graph library.

Use PODIE's local workflow for the right job

PODIE WORKFLOW includes editable branches, validation, JSON import/export, browser persistence, local execution and step results. Its transform step can call an optional executor. The default execution is local and does not contact external services. These boundaries are visible in the template and its source. PODIE WORKFLOW.

That makes it useful for trying a configuration flow, tracing a branch or connecting your own adapter. It does not supply a durable remote job service. If a workflow must continue after the browser closes, treat runtime selection and server integration as separate work before promising that behavior to users.

The editor decision is about helping people define and inspect a process. The runtime decision is about preserving the meaning of a run when normal execution stops. A useful prototype makes both decisions visible early.