Workflows Overview

A workflow is what happens when you run a canvas. The canvas is the editing surface — nodes and the edges between them. A workflow is the execution of a connected slice of that canvas: Builder Studio takes the node you run, walks the edges to gather everything it depends on, orders those nodes, and runs each one in turn, passing data along the connections.

What runs, and what does not

Not every node executes. Only nodes that have a registered executor participate in a run. Static layout nodes such as text labels, shapes, documents, and code blocks are never executed — they hold content but produce no workflow output.

• Generation nodes run their provider call: Image Generation, Video Generation, Text Generation, Text-to-Speech, Speech-to-Speech, and Sound Effects.
• Prompt nodes read prompt text from node data and pass it downstream.
• Media nodes (Image, Video, Audio) act as passthrough steps — they emit the stored media URL so downstream nodes can consume it.
• Webhook Call nodes make an outbound HTTP request, and Webhook Trigger nodes act as a graph entry point for incoming events.
• Nodes with no executor (text, shape, document, code) are skipped by the planner and never billed.

How a graph executes

When you run a node, the execution planner builds an immutable plan from the surrounding graph, and the runner walks that plan:

1. 1

   Resolve the subgraph

   The planner finds the relevant subgraph. Running a target node pulls in that node plus every upstream node it depends on. Running a trigger node pulls in the downstream graph that trigger can reach, plus any side inputs that reachable graph needs. Unrelated parts of the canvas are left out of the run.

2. 2

   Order the steps

   The subgraph is sorted topologically (Kahn's algorithm) so a node only runs after everything feeding it has produced output. Each step records the incoming edges that map upstream output ports to its own input ports.

3. 3

   Group parallel work

   Steps that do not depend on each other are grouped so they can run concurrently. Independent branches execute in parallel; the run only blocks where one step genuinely needs another's output.

4. 4

   Execute each step

   The runner executes each step (or parallel group), resolves its inputs from upstream port outputs, calls the step's executor, and writes the result back onto the node. Text Generation streams its output as it arrives.

5. 5

   Settle the run

   When all steps finish, the run is marked complete. If a step fails, downstream steps are skipped, and remaining work is resolved as skipped or cancelled depending on why the run ended.

1Prompt ──▶ Text Generation ──▶ Image Generation ──▶ (target)2   │                                  ▲3   └────────────── upstream ──────────┘4 5A workflow run resolves the subgraph that feeds the node you run,6sorts it topologically, then executes step by step. Independent7branches that share no dependency run concurrently.

Data flows along edges

Edges are typed connections between an output port on one node and an input port on another. During a run, each step reads the resolved values from its incoming edges and feeds them to its executor. A Prompt node can feed text into a Text Generation node, whose output can feed an Image Generation node, and so on. The shape of your edges is the shape of your workflow.

Retries, timeouts, and failure

• A step can carry a retry policy. On error it retries with exponential backoff before the step is considered failed.
• Runs have a global execution timeout, and each step has its own step timeout, after which the run is aborted.
• When a step fails, its downstream dependents are skipped. In a parallel group, a sibling failure skips the still-pending siblings.
• Long-running provider work (for example async video generation) can suspend the run at a waitpoint and resume when the provider result is ready, rather than holding the whole run open.