Journey Builder is the part of Salesforce Marketing Cloud (SFMC) where good intentions go to become spaghetti. It’s approachable enough that anyone can build a journey, and powerful enough that a badly built one can quietly damage your sending reputation and your data. After reviewing a lot of implementations, the same architecture mistakes come up again and again. Here are seven, and how I design around them.
1. Using one giant journey for everything
The instinct is to model the whole customer lifecycle in one enormous canvas. It becomes impossible to change, test, or reason about. Fix: decompose into smaller, single-purpose journeys (welcome, nurture, win-back, transactional) that share data through Data Extensions. Small journeys are testable journeys.
2. Injecting on the wrong entry source
Entering contacts via an API or a Data Extension that updates in place, without controlling re-entry, leads to duplicate entries and people getting the same email twice. Fix: design the entry source deliberately, set re-entry mode consciously, and use a clean “injection” Data Extension whose only job is to feed the journey.
3. No re-entry policy (or the wrong one)
“Re-entry allowed” vs “no re-entry” vs “re-entry after exit” is not a checkbox to click past — it’s a business rule. Getting it wrong means either people stuck out of a journey they should re-enter, or being spammed. Fix: decide the re-entry rule from the marketing requirement, then configure to match, and document why.
4. Hard-coding logic that belongs in data
Decision splits stacked ten deep, with literal values baked into the journey, mean every rule change is a journey redeploy. Fix: push logic into the data. Pre-compute a segment, a flag, or a score in a SQL Query or an upstream system, and let the journey read a simple field. Journeys should route on data, not compute it.
5. Ignoring wait/send-time behavior at scale
Wait activities, send-time windows, and time zones behave differently at volume than they do in a test with three contacts. Journeys that “worked in QA” pile up or fire at 3 a.m. for half the audience. Fix: reason explicitly about time zones and throughput, and test with realistic volumes before go-live.
6. No exit criteria
Contacts that should leave a journey when they convert, unsubscribe, or bounce — but don’t — keep receiving irrelevant (or non-compliant) messages. Fix: define exit criteria for every journey. “What makes someone no longer belong here?” is a required design question, not an afterthought.
7. Building with no monitoring or documentation
A journey with no naming convention, no version note, and nobody watching its stats is a time bomb. Six months later nobody knows what it does or whether it’s still running. Fix: adopt naming conventions, keep a simple journey inventory, and monitor entry/exit counts and send health. Treat journeys as production systems, because they are.
The pattern underneath all seven
Every one of these mistakes is the same root cause: treating Journey Builder as a drawing tool instead of an architecture. A journey is a distributed, stateful, time-based system that touches live customer data and your sender reputation. Design it like one — small, data-driven, with explicit entry/exit rules and monitoring — and it stays maintainable. Draw it like a flowchart and it will eventually surprise you, usually in production.
If you’re inheriting an SFMC org full of tangled journeys, start with mistakes 6 and 1: add exit criteria and break the monoliths apart. That alone buys back most of the control.