The most common question in migration workshops right now is some version of: “does Flow replace Journey Builder?” The short answer is no — not in the way people mean. They operate at different altitudes, and confusing the two is what turns a hybrid setup into two systems arguing about who owns the customer.
Key takeaways
- Marketing Flow does not simply replace Journey Builder — the two operate at different altitudes.
- Flow orchestrates across systems, data and channels; Journey Builder runs the customer-facing sequence inside Engagement.
- In a hybrid setup, decide explicitly which layer owns the contact and which owns the message.
- Two orchestration layers without an ownership rule become two systems arguing about one customer.
- Document the boundary on one page before either team starts building.
Altitude, not replacement
Journey Builder was designed to answer one question well: given a person who entered here, what sequence of messages, waits and branches should they experience? It is a sequence engine for customer-facing communication, and it is good at it.
Marketing Flow answers a broader question: given something that happened, what should happen next — across data, systems, channels and people? A marketing flow can update a record, invoke an agent, call another system, post to a channel, decide an audience, and yes, send a message.
That difference in scope is the whole distinction. Flow is not a better Journey Builder. It is the layer above, with a wider set of things it can reach.
What belongs where
| Decision | Belongs to | Because |
|---|---|---|
| Who is eligible for this programme | Flow / data layer | Needs unified data and consent state that Engagement alone does not hold |
| What sequence of emails a person receives | Journey Builder (in hybrid) or marketing flow | Self-contained message sequencing — whichever layer owns the programme |
| Whether to involve an agent | Flow | Agentic steps live on the platform, not inside Engagement |
| Creating a task or changing an owner | Core Salesforce flow | CRM-side consequence, governed by the org |
| Global frequency cap and suppression | Flow / platform | Must apply across every programme, including ones Engagement cannot see |
| Send-time optimisation within a sequence | Whichever layer executes the send | Keep the decision next to the action |
The hybrid problem, stated plainly
In a hybrid estate, both platforms can message the same person. Nothing stops them. There is no shared frequency cap by default, no shared suppression, and no shared notion of “this customer is currently in a sales conversation.”
Left unmanaged, this produces the failure mode every marketing leader recognises: a customer receives a win-back email from a legacy journey on Tuesday and a new-customer onboarding email from a marketing flow on Wednesday, because two systems each believed they knew who that person was.
The rule you need before the second platform goes live
Every contact must have exactly one owning layer at any moment, and that ownership must be visible to both platforms. Not a convention, not a shared document — a field, a flag or a segment that both sides read before sending. Without it, coordination depends on people remembering, and people will not.
Three workable division patterns
Pattern A — by programme
Whole programmes stay where they are. Existing lifecycle journeys remain in Journey Builder; new programmes are built as marketing flows. A contact can be in a legacy journey or a new flow, never both, enforced by mutual suppression on entry.
Best for: teams with a stable legacy estate and a clear appetite for new use cases. It is the simplest to explain and the easiest to police.
Watch for: the boundary blurring when someone wants a new programme that overlaps a legacy one. That is the moment to migrate the legacy programme, not to run both.
Pattern B — by altitude
Flow owns eligibility, orchestration and cross-channel decisions. It decides who should enter what, then hands execution to Journey Builder for the message sequence. Journey Builder becomes an execution engine rather than a decision engine.
Best for: organisations with heavy Engagement investment who want unified decisioning without rebuilding every journey.
Watch for: the handoff. It has to carry enough context, and it has to report back when the sequence completes, or Flow loses track of where people are.
Pattern C — by domain
Split by business area. One brand, region or product line runs entirely on Marketing Cloud Next; the rest stays on Engagement. Each domain is internally coherent.
Best for: phased migrations with a multi-quarter runway, and for organisations where domains genuinely have separate audiences.
Watch for: customers who exist in more than one domain. If they do, you are back to needing a shared ownership rule.
Suppression: the mechanics that make hybrid survivable
Whichever pattern you choose, four controls do the actual work:
- A shared suppression source. One place both platforms read before sending: unsubscribed, bounced, in an active sales conversation, employee, test record. It must be readable from both sides, which usually means it lives in the CRM.
- An ownership flag. Which layer currently owns this contact’s marketing communication, set on entry and cleared on exit, with a timeout so a stuck flow does not silence someone forever.
- A global frequency cap counted across both platforms. If that is not technically possible in your setup, an agreed budget per platform is a workable second best — and better than no rule.
- A reconciliation report. Weekly: contacts who received messages from both platforms in the same period. The target is zero. Anything else names a gap in the first three controls.
The report is the control
Configuration expresses intent; the reconciliation report tells you whether the intent held. Teams that run a hybrid setup without one discover their overlap problem through a customer complaint, which is a slower and more expensive detector.
How long should hybrid last?
Long enough to learn, not long enough to institutionalise. Hybrid is a transitional state that carries real ongoing cost: two skill sets, two sets of governance, two places to look when something goes wrong, and the coordination overhead above.
The failure mode is not running hybrid — it is running hybrid without an end condition. Write down what would trigger consolidation: a proportion of programmes migrated, a legacy platform contract date, a team capability threshold, or simply a date to reassess. Then review it on a cadence, briefly, with the reconciliation report in the room.
Organisations that do this typically consolidate within a few quarters. Organisations that do not are still running both three years later, paying for the coordination every week and no longer able to say why.
The takeaway
Flow does not replace Journey Builder; it sits above it and can reach further. In a hybrid estate the thing that matters is not which tool you prefer but whether one contact has one owner at any moment — enforced by a flag both platforms read, and verified by a report somebody actually looks at.