Marketing Cloud Journey Builder

Journey Builder Implementation That Survives Its Own Success

Journey Builder is where a customer moves along a designed path: an entry source puts them in, splits and waits decide what happens next, messages go out, and a goal decides when they are done. Twopir Consulting designs journeys against a framework rather than one at a time — so entry criteria do not collide, journeys end when they should, and a change does not strand the customers already inside.

Discuss Your Journeys Marketing Cloud Consulting
  • 12+ Years of CRM and marketing platform delivery
  • 250+ Platform deployments delivered
  • 500+ Clients across six markets
Journey Anatomy
WHAT A JOURNEY IS MADE OF Entry source Who is admitted, and how often Decision 01 Splits Decision, engagement, random Decision 02 Waits Fixed, until a date, until a time Decision 03 Messages Email, SMS, push, in-app Decision 04 Goals and exits When the journey is finished Usually empty TWOPIR JOURNEY FRAMEWORK Admission Rules What may enter what, and when Suppression Layer Sits above every journey, not inside Version Control Change without stranding anyone 2πr WHAT THE FRAMEWORK PREVENTS A customer in three conflicting journeys at once Because admission is governed above the journey A change that strands the people already inside Versioning understood before it is discovered
Entry

Choosing an Entry Source, and What Each One Commits You To

The entry source is the most consequential decision in a journey and the one most often made by habit. It determines how often someone can enter, how quickly they enter after the triggering event, and what has to be true elsewhere in the platform for the journey to work at all.

Journey Builder entry sources compared
Entry sourceAdmits a contact whenTimingWhat it commits you to
Data extensionA record appears in, or is refreshed into, a nominated data extension.On the journey's configured schedule, so as fresh as the data step that fed it.An Automation Studio dependency. The journey is only as timely as the query behind it, which is where most "the journey is slow" complaints actually originate.
Contact event / API entryAn external system fires an event through the API.Near real time.An integration with its own failure handling. When the calling system is down, nobody enters and nothing tells you — unless you built that alert.
Salesforce data eventA CRM record is created or updated to match criteria.As fast as the connection between CRM and Marketing Cloud allows.A dependency on Marketing Cloud Connect and its poll cadence. A retention journey reacting to a cancellation needs a different cadence from a newsletter.
Audience / segmentA contact is a member of a defined audience at evaluation time.At evaluation.Discipline about what the audience means. Audiences that drift silently admit people nobody intended.
Event / interactionA tracked behavior occurs — an abandoned basket, a page view, an app action.Near real time, subject to the collecting system.Behavioral data arriving reliably. This is the entry source with the highest value and the most upstream dependencies.

Capabilities verified against Salesforce documentation Last reviewed 23 September 2026

Design

Four Decisions That Separate a Journey Program From a Pile of Journeys

A single well-built journey is not difficult. Forty journeys that coexist without contradicting each other is a design problem, and it is not solved inside any individual journey — which is why it never gets solved by building them one at a time.

Decision 01

What may enter what, and how often

Re-entry rules, overlap between journeys, and whether a customer can be in two at once. Configured per journey by default, which means nobody is looking at the combination — and the combination is what the customer experiences.

  • Re-entry policy decided per journey and recorded, not left at default
  • Overlap analysis: which journeys can legitimately run together
  • Mutual exclusion where two journeys must never coincide
  • Entry volume thresholds that halt an anomalous admission
  • A register of which journeys admit from which source
Decision 02

A suppression layer above everything

Suppression implemented inside each journey is suppression that will diverge. The rules that must always apply — an open complaint, a recent purchase, a frequency cap, a legal hold — belong in one place that every journey reads.

  • Global suppression maintained centrally and read by every journey
  • Frequency capping across journeys rather than within one
  • Service and operational suppressions — an open escalation, a dispute
  • Regional and consent-driven suppression applied consistently
  • One change updates every journey, because there is one rule
Decision 03

Goals and exits, configured rather than skipped

A journey without a goal has no definition of success and no reason to end, so customers travel the whole path whether or not they did the thing it was built for. This is the most common configuration gap we find, and the easiest to close.

  • A stated goal per journey, configured in the platform
  • Exit criteria so a converted customer stops receiving the nurture
  • Performance measured against the goal, not against click rate
  • Journeys with no defensible goal identified as retirement candidates
  • Goal data feeding reporting rather than message metrics
Decision 04

How a journey gets changed

Journeys are versioned, and the behavior surprises nearly every team the first time it matters. Deciding the change process before the first urgent edit is what prevents the failure described in the next section.

  • A documented change procedure, agreed before it is needed urgently
  • Who may publish a new version, and who reviews it
  • What happens to contacts on the previous version
  • Testing on real records before a version is published
  • A retirement process, so old versions stop running deliberately
Versioning

The Journey Versioning Trap, and How to Stay Out of It

Journey Builder versions journeys. When you modify a running journey and publish, you create a new version — and the contacts already travelling the previous version keep travelling the previous version, on the old path, receiving the old messages.

That is correct behavior. Interrupting people mid-journey would be worse. But it surprises teams who assumed an edit applies to everyone, and it is why old messaging keeps arriving weeks after a campaign was supposedly changed.

Four practices keep it manageable. None require tooling; all require deciding before the first urgent change rather than during it.

Know what is still running, not just what is published

The current version is what everyone looks at. The previous versions with contacts still inside are what customers are actually experiencing. Any journey inventory that lists only current versions is describing the intended program rather than the live one — and the gap between those two is where the surprises live.

Decide what happens to in-flight contacts, every time

Before publishing a change: do the people on the old version finish it, get stopped, or get moved? Each is legitimate and each has a consequence. What causes incidents is not choosing — publishing and discovering the answer afterwards, usually from someone who received the retired message.

Design for change where change is likely

A journey whose content lives in reusable blocks and whose logic reads from data rather than from hard-coded values can often be updated without a new version at all. That is a design decision made at build time, and it is worth taking deliberately for any journey you expect to iterate on.

Retire old versions on purpose

Versions with contacts still inside do not clean themselves up. Part of the change process should be deciding when the previous version stops — otherwise an org accumulates running versions nobody is monitoring, each still sending, indefinitely.

12+
Years delivering CRM and marketing platform transformation
250+
Platform deployments delivered
500+
Clients served across global markets
98%
Client retention rate
Failure Modes

Four Ways a Journey Program Turns Against You

Every one of these is the result of building journeys individually, each of which was sensible on its own. None is visible from inside a single journey, which is why nobody catches them until a customer does.

An audit inventories all four, including the running versions that no dashboard shows.

The contradictory week — A customer receives a win-back offer on Monday, an upsell on Wednesday and a satisfaction survey on Friday, because three journeys admitted them independently and nothing sits above all three. Each journey is performing well by its own metrics.

The journey that never ends — No goal, no exit criteria, so customers travel the full path regardless of whether they converted on day two. The nurture keeps arriving after the purchase, which is the single most reliable way to make a brand look like it is not paying attention.

The orphaned version — A journey was edited and republished months ago. Contacts on the previous version are still moving through it, still receiving messaging that was retired, and no report shows them because the dashboard tracks the current version.

The journey nobody can explain — Eleven splits, four waits and a branch structure whose author has left. It runs, it is not obviously broken, and nobody will touch it — so every new requirement gets built as an additional journey alongside it, which is how the pile grows.

When to Look

Signs Your Journeys Need a Framework

Individual journeys rarely fail. What fails is the combination, and the combination is nobody's job until it is a complaint. These five signals are what that looks like before it gets there.

Nobody can say how many journeys are live, and the answer changes depending on whether old versions with contacts inside are counted.
A customer has complained about receiving contradictory messages in the same week, and the investigation found three journeys that each behaved correctly.
Journeys are reported on open and click rates because most of them have no goal configured to report against.
Suppression logic is implemented separately inside several journeys, and the implementations have quietly diverged.
Changing a journey is avoided because nobody is certain what happens to the people already in it.
Related

Automation

The scheduled half: the SQL, imports and extracts that build the audiences journeys consume.

Email Marketing

The content inside the messages — template system, personalization and deliverability.

SMS & WhatsApp

Adding conversational channels to a journey, and the consent design that has to come first.

Personalization

Real-time behavior from web and app, and how it feeds journey decisions.

Marketing Cloud Implementation

Where the journey framework is designed, alongside the contact model it depends on.

Marketing Cloud Case Study

A worked example of the architecture-first approach on a real client engagement.

Common Questions

Questions About Journey Builder

They stay on the version they entered. Journey Builder versions journeys, so publishing a modified journey creates a new version and the contacts already travelling the previous one continue along the old path, receiving the old messages, until they reach its end.

That is deliberate — interrupting people mid-journey would be worse — but it means a change is not retrospective. The practice that prevents surprises is deciding before each publish whether in-flight contacts should finish, be stopped, or be moved, and recording which was chosen.

If a customer is progressing through an experience, it is a journey. If a system is producing or moving data on a schedule, it is Automation Studio. The test is whether a person is doing anything.

Most real programs use both together, with Automation Studio maintaining the data and audiences that journeys read at entry. Getting the split wrong — building audience logic inside journeys, or trying to orchestrate customer experience from a schedule — is expensive to unpick later.

With a suppression layer that sits above every journey rather than inside each one, and with explicit rules about which journeys may admit a contact at the same time. Suppression implemented separately in several journeys will diverge; it always does.

Frequency capping belongs in the same place. A cap applied within a journey caps that journey; what a customer experiences is the total across all of them, which is only controllable above the journey layer.

Usually the entry source rather than the journey. A data extension entry source is only as timely as the query that populates it, so if the audience is built by an overnight automation, entry is overnight regardless of how the journey is configured.

Where the requirement is genuinely real time, an API-driven contact event or a Salesforce data event is the right entry source — and then the timeliness depends on the integration rather than on a schedule.

Fewer than you have. Almost every estate we audit is running journeys that duplicate each other, journeys whose campaign ended, and journeys that could be one journey with a split.

The useful question is not a number but whether each journey has a goal it can be measured against. A journey with no defensible goal is a retirement candidate, and retiring it usually improves the program twice — once by removing the messages, once by removing the overlap.

Yes. Journey Builder orchestrates across channels, and SMS and WhatsApp are message activities like any other. Marketing Cloud Advanced Edition and Marketing Cloud Next add Unified Conversations, which turns SMS and WhatsApp from one-way promotion into two-way conversation.

The design work that matters is upstream of the journey: consent per channel, per market, captured and honoured. Adding a channel to a journey is straightforward; adding a channel to your consent model is the actual project.

Next Step

Start With What Is Running, Not With What You Want to Build

Tell us roughly how many journeys are live and whether anyone has counted the older versions with contacts still inside. That answer usually says more about the program than the journey map does.

Discuss Your Journeys Audit What You Have

Serving: US | Canada | UK | UAE | Australia | New Zealand

Relatable? We should definitely talk.

What we'll cover:

From CRM and integrations to custom apps and complex system architecture — we help you scale without chaos.
  • Identify revenue leaks across CRM, integrations, and GTM
  • Design and optimize complex systems (CRM to Custom Apps)
  • Apply practical AI to improve operations and pipeline conversion
  • Eliminate silos and build a unified revenue system
  • Assess GTM performance and key bottlenecks
  • Align teams with clear processes and ownership
  • Define a scalable RevOps model
  • Improve forecasting and reporting
  • Review your HubSpot/Salesforce setup for scale