Every Salesforce Marketing Cloud project we ship eventually runs into the same request: "Can you set up a welcome email series for new customers?" The ask sounds simple. The execution has two quiet traps that most first-time Journey Builder users walk straight into.
Here's how we handled it on a recent retail engagement, including the two pitfalls our team only learned the hard way.
The problem
Our client - a mid-size retail brand - wanted new customers who signed up for an account to receive a 3-email welcome sequence:
- A welcome email, sent immediately on signup.
- A product highlight email, 3 days later.
- A 10% coupon for their first order, 7 days after signup.
The twist: if the customer had already placed an order before email #3 was due, the coupon should not be sent. No point offering a first-order discount to someone who already converted.
On the surface, this is the textbook use case for Journey Builder: a conditional email sequence driven by customer behavior. But the "textbook" setup hides a handful of decisions that directly impact cost, deliverability, and how maintainable the Journey will be six months later.
How we built it
Step 1: Picking the right Entry Source
The Entry Source determines when and how a subscriber enters the Journey. SFMC gives you four main options:
- Data Extension Entry Source - Subscriber gets added to a Data Extension → Journey picks them up on the next schedule. Best when you already run an Automation Studio import to populate the DE on a schedule (hourly, daily).
- API Event Entry Source - An external system fires an API call into SFMC the moment an event happens (e.g., the customer submits the signup form on your website). This is the real-time path.
- CloudPages Entry Source - The customer fills a Smart Capture form hosted on a CloudPage.
- Salesforce Entry Source - A record in your Salesforce CRM meets a defined condition.
For a welcome series, two options make sense:
- API Event is the right call when you want the welcome email to land seconds after signup. The website calls SFMC's REST API the moment the form is submitted. Highest-intent, highest-impact path.
- Data Extension works fine when you're comfortable with a short delay (e.g., the website writes signups to a staging table, an hourly Automation imports them into the Journey's source DE).
We went with the API Event on this engagement - the retail brand had a strong "sign up and use immediately" UX, and we didn't want a cold one-hour gap between signup and first email.
Step 2: Configure Re-entry settings
This is the setting most teams forget to check, and it costs them customer complaints.
By default, Journey Builder allows a subscriber to re-enter the Journey. That means if the same customer leaves and then re-qualifies - even accidentally - they start receiving the welcome emails again.
For a welcome series, that's almost never what you want. A customer who unsubscribed and re-subscribed three months later should not be treated like a brand-new signup.
Go to Journey Settings → Contact Entry Mode → No Re-entry. Do this before you launch. Changing it after customers are already in the Journey is surgery.
Step 3: The canvas
The final Journey is straightforward:
Entry Source (API Event on signup)
└─ Send Email: "Welcome to [Brand]"
└─ Wait: 3 days
└─ Send Email: "Meet our bestsellers"
└─ Wait: 4 days (7 days total from entry)
└─ Decision Split: Has the subscriber placed an order?
├─ Yes → Exit (skip the coupon)
└─ No → Send Email: "10% off your first order"
Three emails, one conditional split, one clean exit. Ships in a couple of hours once the DE schema and templates are ready.
Two mistakes we fixed along the way
Mistake 1: Forgetting to set "No Re-entry"
On an earlier engagement, we skipped the Re-entry setting. Customers who unsubscribed and later re-subscribed re-entered the Journey from the beginning and received the entire welcome sequence again. We got complaints the same week.
Rule we adopted: for any welcome series, post-purchase series, or onboarding flow, always set No Re-entry before the Journey goes live. The exceptions (birthday campaigns, renewal nudges) re-enter on purpose - those are rare.
Mistake 2: Using Decision Split to check "Has the subscriber unsubscribed?"
Another team we reviewed had added a Decision Split before every Send Email to check whether the subscriber had unsubscribed, "just to be safe." The Journey ballooned into something with twice the blocks it needed and a maintenance headache for anyone else who opened it.
SFMC already blocks sends to unsubscribed contacts automatically. You don't need to check that manually.
If you want to remove a subscriber from a Journey based on a business condition (e.g., "they placed an order, don't keep nudging them"), the right tool is Exit Criteria in Journey Settings, not a Decision Split at every node. Set the criterion once, and every subscriber who meets it is exited on the next evaluation. One clean rule beats a forest of splits.
Takeaway
A working welcome series in Journey Builder takes less than a day of build time. What separates a welcome series that runs cleanly for two years from one that racks up complaints is the five minutes you spend on re-entry mode and exit criteria before go-live.
When you're evaluating a Salesforce Marketing Cloud partner, ask them how they handle re-entry. If they shrug, they'll ship you a Journey that quietly breaks a month after launch.
Stuck on a Journey Builder setup? Our Salesforce team ships production-grade Marketing Cloud engagements - from Journey design and segmentation to deliverability and Einstein reporting. Get in touch →
See our full platform services for the stack we cover.
Top comments (0)