Branches in Action Flows can now meet back up

Branches in an Action Flow can now share a follow-on step, so the same closing logic doesn't have to live on every path.

—

Imagine an Action Flow that branches based on a condition: customers who've opted into marketing go down one path, those who haven't go down the other. Each branch sends a different card. Both branches end with the same Track Goal step and the same Send Request to your data warehouse. Until now, those closing steps lived twice in the flow, once per branch, and you kept them in sync by hand.

Branches in an Action Flow can now converge to a single follow-on step. The conditional logic still does its work; the shared steps live in one place.

What's new

A Branch Flow step routes customers down different paths based on criteria: a simple comparison, a script, anything you can express as a condition. That part of the model hasn't moved. What's new is what happens after the branches. Instead of each one running its own tail, they can come back together at a shared step and continue from there.

There's a new example in the Workbench that shows the pattern set up. It's the quickest way to see it before refactoring something of your own.

Two kinds of branches, two behaviours

Action Flows have two distinct branching mechanisms, and they interact with merging differently.

A Branch Flow step evaluates a condition and routes the customer down one of several paths. Only one branch runs. The opt-in example at the top of this post is conditional branching, and it's the kind most people think of first.

The other kind is parallel branching: any step can have multiple children, and when it completes, all of those children run for the customer. The classic case is a Send Card step with two child Wait steps, one listening for "card completed" and one for "card dismissed". The customer doesn't pick. Both branches are live, and whichever event fires runs its respective branch.

Merging behaves accordingly. Converging two conditional branches into a shared step means that step runs once, because the customer was only ever on one path. Converging two parallel branches into a shared step means that step can run more than once: once per branch that completes for that customer. Sometimes that's exactly what you want. Sometimes it isn't.

Where parallel-branch merging is usually the right call:

A Send Card step with two Wait branches — one for "completed", one for "dismissed" — converging into a shared Track Goal step. The goal fires on whichever event happens, and you don't need to write it twice.
Two parallel Send Request branches that push to different systems concurrently, then converge into a shared cleanup or logging step.

Where it tends to surprise people:

A merged step that has an external side effect — sending another card, firing a webhook to your CRM — will fire on each parallel branch that reaches it. If both branches complete, it fires twice.
A merged Track Goal placed downstream of parallel branches will record duplicates, which can quietly inflate a metric.

The shorthand: with a Branch Flow step, merging is a normalisation. With parallel branches, merging is a multiplication. Decide which one you want before you draw the line back to a shared step.

Where merging fits

A few patterns that come up often:

Personalisation that converges. A flow branches by cohort, segment, or customer state and sends a different card on each path: first-time users see a different intro than returning users, high-value customers get a richer message than the standard one. The closing actions don't differ by cohort — Track Goal, Send Request to your data warehouse, log to Notion — so they live once, after the merge.
Error or recovery branch rejoining the happy path. A Send Request fails, or returns a status code that means "try again." A short branch handles the recovery, retries with a different payload or falls back to a default, then merges back into the main flow. The flow continues from a single point whether the original or the fallback succeeded.
Optional steps inserted on a condition. Some customers need an extra step on the path: a confirmation card, an additional consent prompt, a wait for an event. Others skip it. The conditional branches on the "needs the extra step" criterion, the longer branch does its work, and both paths converge into the same continuation. Without merging, you'd duplicate every downstream step on the longer branch just to keep the flow whole.

In all three the pattern is the same: the decision differs by branch, the consequence doesn't.

When merging isn't the right call

Not every branch should meet back up. A few cases where keeping the tails separate is better:

The branches end with different downstream destinations. One cohort's outcome should go to your CRM, another's to your data warehouse, a third's to a partner webhook. Merging into a single step that has to re-branch internally doesn't help; keep the tails distinct.
The branches have meaningfully different timing. If one branch needs an immediate Send Request and another should wait three days, forcing them through a shared tail compromises both. Two clean paths with their own pacing read better than a fused one with an awkward schedule.
Each branch needs to send different inputs to the "shared" step. If the closing step is nominally the same — Track Goal, say — but each branch wants to set different goal values or different payload fields, you've just moved the conditional logic inside the merged step. Two specific tails are easier to reason about than one tail wrapped in conditions.

The test is whether the content of the closing step is genuinely identical across branches. If it is, merge. If the step is "the same step" only by name, separate tails are doing real work.

Lower cost of change over time

Without merging, the cost of changing a shared downstream step grows with the number of branches. Every edit means finding and updating each copy. With merging, that cost is constant. You change the step once.

A flow with a single converged tail is also easier for someone else to read. The intent is in one place, rather than implied by three or four near-identical step copies at the end of separate paths.

Branch context still flows the same way

Each step continues to see context only from the steps above it on its own path, not from adjacent branches. Merging gives two paths a shared successor; it doesn't merge their data. If you need both branches to surface their own values into the merged step, plan for that in the payload and variable shape upstream of the merge, not after it.