Understanding How Parallel Steps Actually Run
Parallel and branching steps in Workflows compile to a nested tree of paths, not an arbitrary graph — and that shape is capped three levels deep.
If you've built automations in tools that let you draw a branch from anywhere to anywhere, it's worth knowing that Workflows doesn't work that way — and being upfront about it now saves confusion later.
A tree, not a graph
When you fan a workflow out into multiple branches and bring them back together, the engine isn't wiring up a free-form graph of edges and dependencies. It's compiling your steps into a tree of nested paths, rooted in a single sequence plan. Every branch is a child of the step that created it, and every step inside a branch runs in the order it appears — there's no way to point a branch at an arbitrary earlier or later step the way a dependency graph would allow.
The depth limit
That tree can nest three levels deep — a branch inside a branch inside a branch — and no further. In practice, most automations never get close to that limit. But if you're building something wide and deep, with parallel steps branching off other parallel steps, three levels is the ceiling, and the platform enforces it rather than letting a workflow silently misbehave past that point.
Why this matters before you build
Knowing the shape ahead of time changes how you design: instead of reaching for cross-branch references, structure your logic as clean, nested groups from the start. If a workflow's branching needs are already flat and three levels deep is plenty, you won't notice this constraint at all.
We're publishing this because the mental model matters more than a feature list — knowing you're building a tree, not a graph, is the difference between a workflow that behaves the way you expect and one that surprises you the first time two branches don't run in the order you assumed.