Building a 3-email welcome series in Salesforce Journey Builder

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:

1. A welcome email, sent immediately on signup.
2. A product highlight email, 3 days later.
3. 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:

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.