Forem: SapotaCorp

Building a 3-email welcome series in Salesforce Journey Builder

SapotaCorp — Sun, 24 May 2026 12:59:22 +0000

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.

Double Opt-In in SFMC: When It's Worth the Extra Step

SapotaCorp — Sun, 24 May 2026 12:59:01 +0000

A retail client we audited had bounce rates three times industry average and a decaying sender reputation nobody could explain. Tracking back, the source was in-store signups: cashiers manually keyed customer emails into the POS ("j.smit@gmai.com"), no validation, no confirmation. Half the list never existed.

Double Opt-In is the standard answer for this problem. It's friction users accept once in exchange for a list you can actually send to.

Single Opt-In vs Double Opt-In

Single Opt-In (SOI)

Subscriber submits form -> immediately added to the sendable list. Fast, low friction, list grows quickly. No verification that the email works or the submitter owns it.

Double Opt-In (DOI / Confirmed Opt-In)

Subscriber submits form -> receives a confirmation email -> must click a link in it to become an active subscriber. Two-step, slower, list grows slower. But:

Email address is verified (the confirmation link works only if the address actually receives email)
The submitter owns the address (can't add someone else's email maliciously)
Bots get filtered out (bots don't click confirmation links en masse)

Result: smaller list, much cleaner. Bounce rate collapses, open rate rises, complaint rate drops.

When we turn on DOI

Use DOI when:
- Emails are collected in-store by cashiers (typos rampant)
- The signup form has no CAPTCHA (bot risk)
- The client has EU subscribers (GDPR wants clear consent records)
- The client prioritizes list quality over list size

SOI is acceptable when:
- Form has CAPTCHA + strong validation
- Signups come from trusted flows (checkout, app registration)
- The client needs list volume growth and is willing to clean often

On any engagement with EU subscribers, we default to DOI regardless of other factors. GDPR's "active, affirmative consent" requirement is clearest when DOI is in place.

Setup in SFMC

Step 1: Subscriber submits form (CloudPages Smart Capture or API)
        -> Record written to Pending_Subscribers_DE with Status = "Pending"

Step 2: Triggered Send fires the confirmation email
        -> Email contains a unique confirmation link with subscriber token

Step 3: Subscriber clicks the confirmation link
        -> CloudPage receives the token
        -> Moves record to Confirmed_Subscribers_DE (or flips Status = "Confirmed")

Step 4: Only Confirmed subscribers receive marketing email
        -> Main Sendable DE reads from Confirmed_Subscribers_DE

Important: the confirmation email itself should be classified Transactional, not Commercial. It's a service email (confirming the subscriber's action), not marketing. Commercial classification would mean sending marketing to someone who hasn't opted in yet - a logical contradiction that also violates CAN-SPAM.

Three gotchas

Confirmation email lands in spam

Subscriber submits, never sees the confirmation, abandons. This is especially bad because the subscriber assumed something broke.

Mitigations:

Send confirmations from a dedicated IP with good reputation.
Subject line should be transactional-sounding: "Confirm your subscription to [Brand]"
Avoid spam trigger words, exclamation marks, all caps.
Monitor delivery rate on confirmation sends separately.

Token expiration too aggressive

Setting the confirmation token to expire in 1 hour fails for anyone who checks email next morning. We set tokens to expire after 48 to 72 hours by default. The security cost of a longer window is small; the abandonment cost of a short window is real.

Not capturing the consent record

GDPR audits (and CAN-SPAM best practice) want proof that consent was given. Capture in a dedicated Consent DE:

Consent_DE:
  - SubscriberKey
  - EmailAddress
  - ConsentDate (timestamp of confirmation click)
  - ConsentMethod ("Double Opt-In")
  - IPAddress (if captured)
  - ConfirmationTimestamp

Written at the moment of confirmation, kept for the retention period the client's legal team specifies.

The cost trade-off

DOI drops conversion at signup by 20-40% typically. The subscribers who don't confirm wouldn't have been real engagement anyway - they're not readers, they're friction at capture. Over 3-6 months, engagement metrics and deliverability on the DOI list materially beat the SOI list despite the smaller numbers.

If the client pushes back on "losing subscribers" to DOI, reframe: DOI filters out the subscribers who would have been silent anyway, and the deliverability improvement benefits the subscribers who do remain.

Takeaway

Double Opt-In is friction you add on purpose. It's worth it when the capture channel is unreliable (in-store, unverified forms) or when compliance (GDPR) demands explicit consent proof. Set reasonable token lifetimes, classify the confirmation email as Transactional, capture the consent record. List quality improvement is immediate; deliverability improvement compounds over months.

Building SFMC subscriber acquisition flows? Our Salesforce team implements CloudPages Smart Capture, DOI flows, and Consent DE architectures on production engagements. Get in touch ->

See our full platform services for the stack we cover.

SFMC Abuse Emails and Bounce Thresholds You Must Respect

SapotaCorp — Sun, 24 May 2026 12:53:31 +0000

Team wakes up one morning to an email from abuse@abuse.salesforce.com. Reads like something a spammer would send, gets deleted. Three days later the account can't send email.

This actually happens on SFMC engagements. The abuse team's email isn't spam - it's Salesforce warning you that something in the sending pattern tripped their monitoring. Ignoring it leads to account suspension. Here's how to recognize it and what to do.

Why Salesforce sends Abuse emails

Salesforce monitors every SFMC account's sending behavior. Unusual patterns flag for review:

Complaint rate above safe threshold
Bounce rate above safe threshold
Sudden large send to a cold list
Send to known purchased-list indicators
Reports from ISPs (Gmail, Outlook) about the sender

When flagged, the Salesforce Abuse team emails the account admin with a description of what they saw and expected response.

The sender address is abuse@abuse.salesforce.com. It looks odd. It's legitimate. Check the email headers if in doubt.

The thresholds that matter

Metric

Safe

Action required

Bounce rate per send

< 2%

Clean list immediately, investigate source

Bounce rate per send

10%

Urgent - IP may be blocklisted

Spam complaint rate

< 0.1%

Above: review list source + content

Unsubscribe rate per send

< 0.5%

Above: review frequency and relevance

Bounce rate above 10% on a single send is the serious threshold. ISPs may blocklist the sending IP, and once an IP is blocklisted, each ISP requires a separate delisting request. That process takes weeks, sometimes months.

Complaint rate above 0.5% on a recurring basis is similar - ISP-level reputation damage, expensive to repair.

Response playbook

When an Abuse email arrives:

Step 1: Read carefully

The email states the specific issue (complaint rate too high, hard bounce spike, purchased list suspicion). Extract the concrete data point - don't skim.

Step 2: Investigate same day

Pull tracking data for the last 7-14 days. Look at:

Which sends had the spike
Which segment / DE was the source
What the content was
Whether the list contained newly-imported subscribers

The root cause is almost always one of: list hygiene failure, purchased list import, aggressive new campaign, or a deliverability issue (auth misconfigured, content-filtered).

Step 3: Reply within 24-48 hours

Don't send "we'll investigate." Reply with:

Root cause identified
Specific remediation steps (what's being removed, what's being paused)
Timeline for implementation

Salesforce's abuse team wants to see you understand the issue and have a concrete fix, not an abstract promise. Replies like "we will clean the list and send better email" aren't sufficient.

Step 4: Execute the fix

Clean the list: remove hard bounces, suppress non-engagers.
Remove any purchased contacts entirely.
Pause sends to the affected segment until metrics normalize.
Turn on Double Opt-In if signup channels are suspect.

Step 5: Follow up

After remediation, email the abuse team with what was done and ask them to review. Open communication keeps the account in good standing.

Preventive monitoring

So you don't receive Abuse emails in the first place:

After every send:
  [ ] Complaint rate < 0.1%
  [ ] Bounce rate < 2%
  [ ] Unsubscribe rate < 0.5%

Monthly:
  [ ] Unengaged subscribers removed (6-month dormancy rule)
  [ ] Hard bounces cleaned from all sendable DEs
  [ ] All acquisition channels use DOI or CAPTCHA

During onboarding:
  [ ] status.salesforce.com in the team's bookmarks
  [ ] SPF / DKIM / DMARC configured
  [ ] Never import purchased lists

Most accounts that receive Abuse emails had 2-3 of these checks failing for months.

What to do if the account gets suspended

If you ignore the Abuse email and the account is suspended:

Open a Salesforce Support case immediately.
Provide the abuse email thread if one exists.
Explain root cause and remediation steps.
Expect the reinstatement process to take days to weeks.
Scheduled campaigns are blocked during the suspension.

Faster to respond when the warning arrives than to recover from suspension.

Takeaway

An email from abuse@abuse.salesforce.com is real and urgent. Bounce rate above 10% and complaint rate above 0.1% are the specific thresholds that trigger it. The response is measured investigation + specific fix + timely reply. Ignoring the warning gets accounts suspended, which is much harder to recover from than just replying in time.

Received an abuse notice on SFMC? Our Salesforce team runs deliverability audits, list hygiene remediation, and engagement recovery on production engagements. Get in touch ->

See our full platform services for the stack we cover.

SFMC Email Frequency and Spam Filters: Send Enough, Not Too Much

SapotaCorp — Sun, 24 May 2026 12:39:45 +0000

A retail client we advised decided to quadruple email frequency - from one send per week to four - believing more sends would mean more revenue. Within a month:

Unsubscribe rate tripled.
Complaint rate crossed the 0.1% threshold.
Open rate dropped 30%.
Revenue stayed flat.

The ISPs noticed too. Inbox placement on subsequent sends degraded. The account spent six weeks recovering deliverability after three weeks of over-sending.

Email frequency has rules, and they're not flexible.

The core rule

Send what the subscriber expected when they opted in. If the signup form said "weekly newsletter," weekly is the promise. Daily isn't aggressive growth; it's a broken contract that triggers unsubscribes and complaints.

Subscribers opt in with a mental model of what they'll receive and how often. Violating that model produces two outcomes:

Unsubscribe (best case).
Spam complaint (worst case - damages sender reputation).

Three questions before every additional send

1. Is this content genuinely relevant to the subscriber?
2. Does the subscriber expect to receive this category of email?
3. Is this the right time (not a bad moment, not too close to the last send)?

If any answer is "no," don't send. "The campaign deadline is tomorrow" isn't a good enough reason to break the frequency promise.

Einstein Engagement Frequency

If the client's account has Einstein, use Engagement Frequency instead of guessing. It analyzes each subscriber's historical engagement to predict:

The ideal email volume per week for this subscriber
Whether the subscriber is currently being over-contacted (at risk of unsubscribe)
Whether the subscriber could absorb one more email this week without harm

Output: per-subscriber recommended frequency. Use it to filter the audience on high-volume sends - skip anyone flagged "over-contacted" to protect retention.

Einstein Engagement Frequency is bundled with Marketing Cloud Advanced editions - check if the client has access before promising its use.

Spam filter content signals to avoid

Spam filters look at content patterns regardless of sender reputation. Avoid:

All-caps subject lines: "50% OFF TODAY ONLY!!!"
Excessive exclamation marks anywhere in the email
Spam trigger words: "Free," "Guaranteed," "No risk," "Click here," "Act now"
Image-heavy with little text: images without enough accompanying text read as spam camouflage
Missing text version: HTML-only emails are downgraded by many filters

Ironically, the content that's "most aggressive marketing" is also the content that triggers the most spam filters. Copy that reads naturally tends to deliver better.

Volume-based ISP flags

ISPs also watch sending behavior:

Sudden large volumes from a new IP (before IP warming completed) - flagged as suspicious sender.
High bounce rate on a send - flagged immediately by receiving ISPs.
High complaint rate - flagged; reputation damage persists.
Low engagement across many sends - gradual downgrade to Promotions / Spam.

Ramping a new dedicated IP requires a warming plan - a few thousand sends on day 1, gradually doubling, across weeks. Going from 0 to 500k overnight on a new IP is instantly suspicious.

Content Detective in SFMC

Before sending, run the email through Content Detective. It scans for spam-filter patterns and flags potential issues:

Trigger words
Excessive punctuation
Image-to-text imbalance
Bad HTML patterns
Broken links

Content Detective isn't perfect - some filtered content will still deliver, some clean content gets filtered - but running it is a five-minute safety check that catches the worst offenders.

What "good frequency" looks like

Mid-market B2C retail, healthy setup:

1 newsletter per week
2-4 promotional sends per month (seasonal / sale events)
Triggered emails (welcome, cart abandon, post-purchase) on event
Total: 4-8 emails per month

Subscribers who want more can be offered higher-frequency segments (daily deals, VIP tier) via Publication Lists. Subscribers who want less can downshift the same way. Granular preferences reduce unsubscribes.

Takeaway

Frequency isn't a lever to pull for more revenue; it's a contract with subscribers. Violate it and short-term revenue gains are wiped out by long-term deliverability damage. Use Einstein Engagement Frequency if available, Content Detective every send, and publication-level preferences for granular opt-in. Respect the promise you made at signup.

Balancing revenue goals with deliverability constraints? Our Salesforce team advises on send cadence, Einstein features, and content optimization on production SFMC engagements. Get in touch ->

See our full platform services for the stack we cover.

Sender Profile vs Delivery Profile vs Send Classification

SapotaCorp — Sun, 24 May 2026 12:39:24 +0000

New client onboarding, typical request: "Make sure emails send from orders@company.com, show From as Company Store, use a separate IP for transactional email, and follow CAN-SPAM Transactional rules."

Four requirements. Three different SFMC settings in three different screens to satisfy them. It's the single most confusing area for engineers new to Marketing Cloud.

Here's what each setting controls and where it lives.

Sender Profile - what the subscriber sees

Sender Profile defines the From Name and From Email Address - the identity the subscriber sees in their inbox.

From Name:  Company Store
From Email: orders@company.com
Reply-To:   support@company.com (can differ from From Email)

An account can have multiple Sender Profiles:

One for marketing (newsletter@company.com)
One for transactional (orders@company.com)
One per brand, if the client operates multiple brands

Advanced pattern: if the client wants From Name to vary per subscriber (show the assigned sales rep's name), the Sender Profile can be configured as dynamic and populated by AMPscript at send time.

Lives at: Email Studio > Admin > Sender Profiles

Delivery Profile - what the ISP sees

Delivery Profile defines the IP address and sending domain used for the send - the infrastructure underneath that the subscriber doesn't see but every ISP does.

IP Pool:        Dedicated IP #2 (for transactional)
Sending Domain: orders.company.com
Header/Footer:  Custom per-email footer

Why multiple Delivery Profiles? Because most clients have at least two classes of email with different reputation profiles:

Commercial (newsletters, promotions): high volume, variable engagement, uses one IP
Transactional (order confirmations, password resets): high open rate, near-zero complaints, deserves a separate IP

Separating IPs prevents commercial reputation problems from dragging down transactional deliverability. If commercial gets throttled, transactional still lands inboxes.

Lives at: Email Studio > Admin > Delivery Profiles

Send Classification - the combined bundle

Send Classification packages a Sender Profile + Delivery Profile + a CAN-SPAM classification into a single selectable unit used at send time.

CAN-SPAM classification is either:

Commercial

Transactional

Purpose

Marketing, promotion

Confirm transaction, service communication

Unsubscribe link

Required

Not required

Can send to unsubscribed subscribers

Yes (if genuinely transactional)

Example

Newsletter, flash sale

Order confirmation, password reset

When setting up a Send Classification for order confirmations, choose Transactional. SFMC will then deliver to contacts who have previously unsubscribed - which is what you want for receipts and service notifications.

The mental model

Sender Profile    -> From Name, From Email (subscriber-facing)
Delivery Profile  -> IP, Sending Domain (ISP-facing)
Send Classification -> wraps both + CAN-SPAM type

At actual send time, you only pick a Send Classification. It pulls in the Sender + Delivery automatically.

Three mistakes we still see

Mistake 1: Trying to change the IP from Sender Profile

Team wants a different IP for a specific send, opens Sender Profile looking for an IP field. There isn't one. IP lives in Delivery Profile. Took most of a morning for one engineer to find this the first time.

Mistake 2: Commercial classification on order confirmations

Order confirmation email goes out with Commercial classification. Unsubscribed customers don't receive their receipts. Client's customer service team fields complaints for two days before the root cause is found.

Transactional emails - receipts, shipping notifications, password resets, OTPs - need a Send Classification marked Transactional. Create one during onboarding; don't reuse the default Commercial classification for anything service-related.

Mistake 3: Unverified From Address

Team builds a campaign sending from orders@company.com. The send fails because the domain hasn't been verified in From Address Management. SFMC requires domain verification before any new From address can be used.

Setup: Email Studio > Admin > From Address Management. Verify domains early in onboarding so this doesn't block go-live.

Takeaway

Three settings, three purposes, three screens. Sender Profile is what the subscriber sees; Delivery Profile is what the ISP sees; Send Classification is what you actually pick at send time. Get them right during onboarding - retrofitting transactional/commercial separation after volume is live is harder than setting it up day one.

Setting up SFMC sending infrastructure? Our Salesforce team configures Sender Profiles, Delivery Profiles, and classification strategy on production engagements. Get in touch ->

See our full platform services for the stack we cover.

IP Warming in SFMC: The Four-Week Ramp That Protects Reputation

SapotaCorp — Sun, 24 May 2026 12:33:58 +0000

A retail client wanted to separate their transactional email onto a dedicated IP for better reputation isolation. They bought the IP on Monday and on Tuesday wanted to blast 500,000 emails through it.

Don't do this.

ISPs (Gmail, Outlook, Yahoo) track every sending IP they see. A new IP has zero history and zero reputation. Blasting high volume from it immediately makes the IP look like a spammer's throwaway server. Result: heavy filtering, spam folder placement, possible blocklisting.

The fix is IP warming - ramping volume gradually over weeks while ISPs learn the IP is a legitimate sender.

The four-week ramp we use

Starting point is the engaged cohort - the 20% of subscribers who open consistently. These sends get high engagement signals, which is exactly what ISPs are using to judge the new IP.

Week

Volume per day

Week 1

500 - 1,000

Week 2

2,000 - 5,000

Week 3

10,000 - 20,000

Week 4

50,000+

By week 4 the IP has enough engagement history that full-list sends can run safely.

Rules during warming

Only send to engaged subscribers. The first 2-3 weeks are the most important moment in the IP's life - every bounce and complaint goes straight into the reputation model. Use the cleanest segment you have: subscribers who opened in the last 30 days.

Avoid low-engagement cohorts. Warming the IP with a list that hasn't been cleaned in two years is self-sabotage. High bounce rate on week 1 permanently damages the IP's starting position.

Monitor daily. Track bounce rate and complaint rate every day. If either spikes, pause the ramp and investigate before continuing.

Use Email Performance by Domain in Email Studio. Delivery rate varies by ISP - Gmail might be 98% while Yahoo is 70%. Per-domain visibility tells you which ISP is the problem.

When a dedicated IP is worth it

Dedicated IPs are not free and not always the right choice. Our rule:

Under 250,000 emails/month: shared IP (cheaper, SFMC manages reputation across clients).
250,000 - 500,000/month: either, depends on complexity.
Over 500,000/month, or high reputation sensitivity: dedicated IP.

Shared IP means the client's reputation is partially influenced by other SFMC customers sharing that IP pool. For most volumes that's fine. For high-volume or high-sensitivity senders, dedicated isolates the reputation.

Two mistakes we've seen

Blasting full volume on day one

IP gets blocklisted by Yahoo and Outlook in the first week. Takes 2-3 weeks to request delisting from each ISP and complete the warming from scratch. Every campaign scheduled in that window misses.

Cost of doing it right the first time: 4 weeks of ramp. Cost of doing it wrong: 4 weeks of ramp plus 2-3 weeks of delisting plus reputation damage.

Warming with an inactive list

Using a 2-year-old uncleaned list to warm a new IP. Bounce rate on week 1 is 8%. ISPs immediately flag the new IP as suspicious. The warming completes, but the IP carries below-average reputation permanently.

Always warm with the engaged, recently-active segment. If the engaged segment is small, the ramp starts smaller - that's fine. Don't pad volume with dormant subscribers.

Send Throttling helps during warming

Send Throttling (covered separately) limits per-hour send volume. Use it during warming to avoid dumping the daily allocation in the first five minutes. A smooth hourly rate looks more natural to ISPs than a burst.

Example: week 3 allocation of 20,000 emails, throttle to 2,000/hour. Send runs 10 hours. Looks like a legitimate large sender, not a blast.

When warming fails

If bounce or complaint rate spikes mid-warming:

Stop the ramp at current volume. Don't escalate further.
Investigate - was the data source bad? Was content off-brand?
Fix the root cause.
Resume at current volume for a few more days before continuing to ramp.

Do not repeat the original mistake of going fast. ISPs remember the first few weeks of an IP's life for months.

Takeaway

IP warming is a four-week commitment that protects reputation for the life of the IP. Start with your most engaged subscribers, ramp volume gradually, monitor per-ISP delivery daily, and use Send Throttling to avoid bursts. The alternative - going fast and recovering from blocklists - is always slower and more expensive.

Standing up a new dedicated IP in SFMC? Our Salesforce team runs IP warming programs and deliverability optimization on production Marketing Cloud engagements. Get in touch ->

See our full platform services for the stack we cover.

Send Throttling in SFMC: Protect the Website from Your Own Email

SapotaCorp — Sun, 24 May 2026 12:33:37 +0000

A retail client's flash-sale email was their best-performing campaign of the quarter. 500,000 customers, 38% open rate, 12% click rate. First time they ran it, their website's checkout service crashed.

Half a million emails landed in inboxes within four minutes. Fifty thousand customers clicked the link within the next two. The checkout service hadn't been sized for that kind of traffic spike. Conversion crashed with the checkout.

The IT team asked for "some way to stop the email from creating these spikes." SFMC Send Throttling is exactly that.

How Send Throttling works

In the Send Definition (or Guided Send), set a per-hour send rate. SFMC will pace the send at that rate instead of dispatching everything at once.

Total audience: 500,000
Throttle:       50,000 per hour
Send duration:  10 hours

Same 500k customers receive the email, but spread across ten hours instead of four minutes. The website traffic is smoothed, the checkout service handles it, and the conversion rate actually comes in higher because nothing's breaking.

Where to configure

Guided Send wizard (Email Studio > Interactions > Send)
Send Definition inside an Automation or Journey (Send Email Activity settings)

The UI lets you specify either:

Maximum emails per hour (explicit rate), or
Total time window (SFMC computes the rate)

Both produce the same result; pick whichever the stakeholder is more comfortable thinking about.

Use cases beyond flash sales

Flash sales, limited-stock promotions

Covered above. Protects the checkout and inventory systems from their own marketing success.

Time-zone respect

Send scheduled for 9am local time, but your subscribers span four time zones. Without throttling, everyone receives the email at once - which means 9am for some, 6am for others, noon for others. Throttling combined with per-subscriber timezone data can approximate a "9am their time" delivery.

IP warming

Covered in the warming post. When ramping a new IP, throttling spreads the daily allocation across hours instead of dumping it in the first minute. Looks natural to ISPs.

Reducing reply volume spikes

Some automated replies generate customer service load (people hitting "reply" to newsletters even though the From is no-reply). Throttling spreads those replies over more hours, giving the CS team time to triage.

Capacity-constrained downstream systems

Any downstream system that processes a spike poorly benefits from throttled upstream sends. CRM sync, loyalty point crediting, chatbot handoffs - all can get overwhelmed by 500k simultaneous triggers.

Side effects to consider

Open rate distribution changes

Subscribers opening early in the throttled window see the email fresh; subscribers opening late in the window see an email that's been waiting in their inbox for hours. Competition from subsequent emails in the inbox can reduce open rate for the later subscribers.

Trade-off: smoother downstream load vs. potentially lower open rate on the tail end. For flash sales where the offer is time-boxed, a throttled send is usually still the right call because the alternative is a broken checkout.

Latency for transactional

Don't throttle transactional emails (password reset, OTP, order confirmation). Those need to arrive immediately. Throttling them introduces delay customers notice and complain about.

Delay in closing the campaign

A 10-hour send won't finish at 9am. If you need the full send completed by a specific time, backward-calculate: start time minus total-window = required launch time.

Typical throttle rates

Per-hour rates we use on different send types:

Flash sale / high-CTR campaign: 25k-50k/hour (protects web infra)
Newsletter: usually no throttle (engagement is spread naturally)
IP warming: 500-2,000/hour on the new IP during week 1-2
Low-risk promotional: 100k+/hour if infra can handle it

Start conservative on a new campaign type and loosen once you have evidence the downstream can absorb the volume.

Takeaway

Send Throttling is an often-skipped feature that prevents an entirely self-inflicted class of outage. Any send that drives concentrated downstream traffic - flash sales, stock launches, checkout-heavy promotions - should have throttling configured. Five minutes of setup saves the day the email over-performs.

Sizing an SFMC campaign with downstream infra limits? Our Salesforce team configures throttling, schedule windows, and infrastructure coordination on production engagements. Get in touch ->

See our full platform services for the stack we cover.

SFMC Reply Mail Management: Auto-Handle Unsubscribe Replies

SapotaCorp — Sun, 24 May 2026 12:28:11 +0000

Mid-market client we worked with sent a Friday newsletter to 200k subscribers. Monday morning, their marketing team would spend 2-3 hours each week sorting through the replies that had accumulated over the weekend:

Hundreds of out-of-office autoreplies
Dozens of "please unsubscribe me" manual requests
Occasional product questions
Spam replies from compromised subscriber accounts

The manual unsubscribe requests were the critical ones. Miss one and you're out of CAN-SPAM compliance. Reply Mail Management (RMM) is SFMC's automated handler for this.

What RMM does

RMM is enabled at the account level. When enabled, it can:

Auto-reply to incoming replies with a standard message ("Thank you for your email. This inbox is not monitored. For support, please contact support@company.com.")
Keyword-based unsubscribe detection - if the reply subject or body contains terms like "unsubscribe," "opt out," "remove me," RMM automatically unsubscribes the subscriber and records the event.
Forward replies to a monitored team inbox when the reply doesn't match auto-handling rules.

Configure at: Email Studio > Admin > Reply Mail Management.

The "RMM" unsubscribe reason in tracking

When a subscriber's unsubscribe comes through RMM's keyword detection, the unsubscribe is recorded with reason "RMM" in the tracking data.

Confusing case: the account doesn't have RMM enabled, but "RMM" still shows up as a reason in unsubscribe tracking. This happens because some email clients (Gmail, Apple Mail) auto-include a List-Unsubscribe header in every message. When a subscriber clicks the client's built-in unsubscribe UI (one-click, no landing page), SFMC receives the request via this header and logs it as "RMM."

If you see RMM reasons but haven't configured RMM, it's the List-Unsubscribe header doing its job. Don't panic; it's a legitimate unsubscribe channel.

Configuration patterns

Auto-reply on

Useful when From addresses are noreply@ style but clients still want to acknowledge replies gracefully. Message should:

Confirm receipt
Route to the right support channel
Not promise a human response if none will come

Keyword detection on

Default keyword list covers "unsubscribe," "stop," "opt out," "remove," and variations. Can be extended.

Keep in mind: aggressive keyword detection can trigger on legitimate conversation. "Please don't stop sending me these, they're great!" contains "stop." Review tracking occasionally for false-positive unsubscribes.

Forward on

Replies that don't match auto-handling rules forward to a monitored team inbox. Set this to a distribution list (marketing-replies@company.com) rather than an individual's inbox.

List-Unsubscribe header

Modern email clients add a one-click unsubscribe at the top of emails (outside the message body). SFMC supports the List-Unsubscribe header automatically for commercial sends.

When a subscriber uses the client's built-in unsubscribe:

SFMC receives an email-based unsubscribe request on a reserved address
RMM processes it (even without a configured RMM profile)
Subscriber is unsubscribed, logged as "RMM"

This header has become a deliverability signal. Gmail specifically favors senders who support it cleanly. If for some reason a client wants to disable it, deliverability may suffer. Don't disable it without a strong reason.

Common issues

Hundreds of autoreply bounces filling the Reply folder

"Out of office" replies from thousands of subscribers clog the reply processing. RMM can auto-delete these based on subject patterns like "Out of Office" or "Auto Reply."

Unsubscribe keyword triggers on support questions

Customer emails: "Can you stop sending me weekly? I only want monthly." The word "stop" triggers RMM unsubscribe, customer intended to downgrade frequency, not unsubscribe entirely.

Mitigation:

Offer a Preference Center in the email footer (many will use it instead of replying)
Periodically review unsubscribes in tracking for false positives
Consider disabling the most ambiguous keywords if false positives become common

Reply-To on a no-reply address

If Reply-To is set to noreply@company.com and that address isn't monitored, genuine customer questions vanish. Even if RMM auto-replies, the original question isn't answered.

Use a monitored Reply-To (e.g. support@company.com) separate from the From Name. Subscriber experience improves without marketing having to field every reply.

Takeaway

RMM saves marketing teams from manually processing hundreds of weekly email replies and ensures manual unsubscribe requests are honored within the 10-day CAN-SPAM window. Turn it on during onboarding, configure keyword detection with a sanity-check pass for false positives, and forward ambiguous replies to a monitored distribution list. The "RMM" entries in tracking might come from RMM itself or from the List-Unsubscribe header; both are legitimate.

Setting up SFMC reply handling workflows? Our Salesforce team configures RMM, List-Unsubscribe headers, and reply triage on production Marketing Cloud engagements. Get in touch ->

See our full platform services for the stack we cover.

Three Unsubscribe Levels in SFMC: Global, Account, Publication

SapotaCorp — Sun, 24 May 2026 12:27:50 +0000

Client reports: "I can't get email to send to subscriber X. Their record in the DE is there, Active status, email address correct. What's wrong?"

You check the DE - subscriber is there. You check the sendable setting - correct. You check the email address - valid. Nothing obviously wrong, yet email doesn't arrive.

The cause is almost always one of SFMC's three unsubscribe levels, and knowing which one saves you the hour we wasted the first time we hit this.

Level 1: Global Unsubscribe

The subscriber has opted out of every Marketing Cloud account that uses SFMC. Not just this brand - every brand.

Example: Subscriber A globally unsubscribed from Cloud Kicks's emails a year ago. Cloud Kicks uses SFMC. Later, Northern Trail Outfitters (different company, different SFMC account) imports Subscriber A and tries to send. SFMC blocks the send.

This is the most confusing case because the subscriber is "Active" in your account's records - but Global Unsubscribe is platform-level and overrides the account-level view.

How to check: there's no direct UI for "is this subscriber globally unsubscribed." You can verify via tracking records - if Sent count is 0 and the subscriber is Active, Global Unsubscribe is a strong candidate. Open a support case with Salesforce to confirm.

Global Unsubscribe is rare. If it turns out to be the cause, there's no override - it's the subscriber's platform-level decision.

Level 2: Primary (Account-level) Unsubscribe

The subscriber has opted out of every email from this brand/account, but may still receive email from other brands using SFMC.

This is the most common unsubscribe, triggered when a subscriber clicks "Unsubscribe from all" in a Preference Center or the email footer.

Status in All Subscribers flips to Unsubscribed. Future marketing sends skip this subscriber entirely. Transactional sends can still reach them if they're in a Send Classification marked Transactional.

How to check: Email Studio > Subscribers > All Subscribers > search by Subscriber Key or email. If Status shows Unsubscribed, you found it.

Level 3: List Unsubscribe (Publication List)

The subscriber has opted out of one specific communication category but still receives others from the same brand.

Example: unsubscribed from "Weekly Promotions" Publication List, but still receives "Monthly Newsletter" and "Order Confirmations."

Set up via Publication Lists (Email Studio > Subscribers > Publication Lists). Each send is associated with a specific Publication List, and the subscriber's opt-out per-list is honored automatically.

How to check: look at the Publication List associated with the send, see if the subscriber is unsubscribed from it. Can also check tracking - _ListSubscribers or the Publication List detail UI.

Diagnosis flow

When a subscriber should be receiving email but isn't:

Is the DE sendable? Check Is Sendable flag and Send Relationship.
Is the subscriber status Active in All Subscribers? If not, Primary Unsubscribe - they unsubscribed from the account.
Is the send's Publication List excluding them? Check Publication List memberships.
Is it possibly a Global Unsubscribe? Rare, but check via Salesforce support if the first three check out.

90% of cases resolve at step 2 or 3.

Reference summary

Level

Scope

Where it's tracked

Global

Every SFMC platform account

Global Unsubscribe list (platform-level)

Primary

This entire account / brand

All Subscribers - status: Unsubscribed

List

One Publication List

Publication List membership

When to set up Publication Lists

If the client wants granular unsubscribe (subscribers opt out of weekly promos but keep monthly newsletter), Publication Lists are required. Without them, every unsubscribe is an all-or-nothing Primary Unsubscribe.

For B2C with multiple communication categories, set up Publication Lists early:

Weekly Newsletter
Promotional Offers
Product Updates
Birthday Campaigns
Survey Invitations

Each send gets assigned to a Publication List at send time. Subscribers who opt out of one still receive the others.

The CAN-SPAM compliance note

All three unsubscribe levels must process requests within 10 business days per CAN-SPAM. SFMC processes near-instantly by default; custom Preference Centers that stage requests asynchronously need to respect this window.

Test before production: submit a test unsubscribe, verify the subscriber's status changes in All Subscribers within minutes, and confirm the next test send skips them.

Takeaway

When a subscriber isn't receiving email they should, SFMC is almost always respecting an unsubscribe somewhere - just not the level you looked at. Walk through Primary (All Subscribers status) first, then Publication List membership, then Global as a last resort. Five minutes of checklist work versus an afternoon of random hypothesizing.

Debugging SFMC send failures on specific subscribers? Our Salesforce team runs audits, consent tracing, and Preference Center implementations on production engagements. Get in touch ->

See our full platform services for the stack we cover.

Marketing Cloud Connect: When You Need It, When You Don't

SapotaCorp — Sun, 24 May 2026 12:22:24 +0000

On new engagements where the client runs both Salesforce CRM and Marketing Cloud, one of the first architecture decisions is: install Marketing Cloud Connect (MC Connect) or build a custom integration?

MC Connect is the official bridge - data flows from CRM to SFMC as Synchronized Data Extensions, actions in SFMC can update CRM records. It's the "correct" path for most cases, but not all. Here's how we decide.

What MC Connect actually does

Once installed in the Salesforce CRM and configured in SFMC:

CRM data flows into SFMC as Synchronized Data Extensions - readable by Journey Builder, Automation Studio, and AMPscript.
SFMC actions can update CRM records - a Salesforce Activity in a Journey can flip a Contact field, create a Task, or log an event.
Journeys can be triggered from CRM events - "Opportunity closed won" kicks off an onboarding sequence.
Distributed Marketing lets sales reps send SFMC templates from within the CRM UI.

No custom code, no webhooks, no external integration layer.

When MC Connect is the right call

Requirement

MC Connect?

Client uses Salesforce CRM and wants Contact/Lead data in email personalization

Yes

Trigger Journey from CRM events (Opportunity stage change, Case created)

Yes

Update CRM records when a subscriber takes action in email

Yes

Sales reps sending branded templates from within the CRM

Yes

If any of these are in scope, MC Connect is almost always cheaper than building a custom integration.

When you don't need MC Connect

Scenario

MC Connect?

Client uses SFMC standalone, no Salesforce CRM

Client has a CRM but syncs data via existing file drops or a custom API

No - don't replace a working integration

Client wants only one-way data flow with real-time requirements beyond MC Connect's sync cycles

No - API pattern is better

Client uses a non-Salesforce CRM (HubSpot, Dynamics)

No - MC Connect is Salesforce-CRM-specific

For clients on other CRMs, the integration is either custom (REST API against SFMC's Fuel REST API), file-based (nightly exports from the CRM, SFTP to SFMC), or through a middleware platform (MuleSoft, Boomi, Workato).

Discovery questions to ask

Before deciding, we ask the client:

[ ] Do you currently use Salesforce Sales/Service/Experience Cloud?
[ ] If yes, is MC Connect already installed and configured?
[ ] Is integration with CRM in scope for this project?
[ ] What's the expected frequency of CRM-to-SFMC data sync?
    - Near real-time (minutes)?
    - Hourly?
    - Daily is enough?
[ ] Any requirement to trigger SFMC actions from CRM events?
[ ] Any requirement to push data from SFMC back into CRM?

Answers determine both whether to use MC Connect and how to configure it.

What MC Connect doesn't solve

Real-time requirements below the sync cycle. Synchronized DEs typically refresh every 15 minutes to a few hours. If the email needs current-account-balance data that can't be stale by 10 minutes, use a direct API lookup at send time, not Synchronized DE.
Non-Salesforce data. If the client's loyalty data lives in a third-party loyalty platform, MC Connect doesn't help. That data arrives via file or API, not through the MC Connect bridge.
Complex transformations. MC Connect maps CRM object fields 1:1 into Synchronized DEs. Complex joins or reshaping happen downstream via SQL Query Activity on SFMC's side.

Cost consideration

MC Connect itself is a feature of Marketing Cloud licensing - no separate cost for most editions. The cost is time:

Install the MC Connect package in Salesforce CRM (straightforward).
Configure the Integration User with the right permissions (most setup time).
Set up the Object and Field syncs for each CRM object in scope.
Test the sync in a sandbox before production.

Typical setup: 1-3 days of configuration + testing for a straightforward case (Contact + Lead sync). More if there are many custom objects or permissions take multiple iterations to get right.

Takeaway

MC Connect is the default choice when Salesforce CRM is in the picture and any of the integration use cases apply. Skip it only when the client's CRM isn't Salesforce, when an existing integration is working fine, or when requirements exceed what MC Connect can do. Answer the discovery questions early so this decision doesn't get remade mid-build.

Scoping an SFMC + Salesforce CRM integration? Our Salesforce team sets up MC Connect, Synchronized Data Extensions, and hybrid integrations on production engagements. Get in touch ->

See our full platform services for the stack we cover.

Synchronized Data Extensions: Reading Salesforce CRM Data in SFMC

SapotaCorp — Sun, 24 May 2026 12:22:03 +0000

On a typical engagement with Marketing Cloud Connect installed, the most common need is: send an email that personalizes with the customer's name, their assigned sales rep, and their account information. That data all lives in Salesforce CRM Contact and Account objects. Without MC Connect you'd export and re-import it daily. With MC Connect, it flows automatically into a Synchronized Data Extension.

Here's how to configure it and the mistakes we still fix on audits.

Configuration: Contact Builder > Data Sources > Salesforce Objects

Once MC Connect is installed, go to Contact Builder > Data Sources > Salesforce Objects in SFMC. Pick which CRM objects to sync and which fields to include:

Salesforce Contact Object
  Fields synced:
  - Id              -> ContactID
  - FirstName       -> FirstName
  - LastName        -> LastName
  - Email           -> EmailAddress
  - AccountName     -> CompanyName
  - Owner.Name      -> SalesRepName
  - Contract_Type__c -> ContractType  (custom field)

SFMC creates a Synchronized Data Extension for each object you enable. The DE name is usually the object name prefixed with an underscore.

Reading Synchronized DE data in an email

AMPscript reads values from Synchronized DEs just like any other DE:

%%[
SET @repName = AttributeValue("SalesRepName")
SET @company = AttributeValue("CompanyName")
]%%

Hi %%FirstName%%,

Your account manager at %%=v(@company)=%% is %%=v(@repName)=%%.

If the Synchronized DE is used as the Journey's entry source or the Send's audience, the subscriber's CRM data is available via Personalization Strings or AMPscript at send time.

Three mistakes we still see

Mistake 1: Trying to edit the Synchronized DE manually

Synchronized DEs are read-only from SFMC's perspective. You can't add fields, change data types, or manually edit rows. Any change attempts either fail silently or get overwritten on the next sync cycle.

The change path is always:

Add the field to the CRM object (or enable an existing field).
Update the Synchronized DE sync config in Contact Builder to include the new field.
Wait for the next sync cycle.

Teams that try to shortcut by adding a column directly to the Synchronized DE are surprised when it vanishes. Not a bug - expected behavior.

Mistake 2: Field needed but sync not enabled

Journey Builder or Email personalization shows the field empty. Check the sync configuration - is the field checked in Contact Builder? Just because it exists on the CRM object doesn't mean it syncs. Fields must be explicitly selected.

Rule of thumb on new setup: sync only the fields you actually need, not "sync everything just in case." Too-wide syncs clutter the schema and slow cycles.

Mistake 3: Relying on sync cycles for real-time data

Synchronized DE sync runs on a cycle - typically 15 minutes to a few hours depending on configuration and volume. Not real-time.

Use cases that need true real-time data:

Account balance lookups (bank apps).
Order status at send time (confirmation email for an order placed 2 minutes ago).
Loyalty point balance at send time.

For these, don't use Synchronized DE - do an API lookup at send time or have upstream systems push to a non-synchronized DE via REST API.

The data flow direction

Synchronized DE is CRM -> SFMC only. Changes in the Synchronized DE don't flow back to the CRM. If you need bidirectional updates (email unsubscribe -> update CRM Contact's Email_Opt_Out field), that's a separate mechanism using Salesforce Activity inside a Journey (covered in a separate post).

Which objects are most commonly synced

CRM Object

Why sync

Contact

Primary subscriber data: name, email, company, rep

Lead

Pre-conversion prospects who should receive nurture emails

Account

Company-level data for account-based personalization

Opportunity

Deal-stage triggers for onboarding / upsell campaigns

Case (Service Cloud)

Customer service follow-up emails

Custom objects

Loyalty tiers, product preferences, industry-specific data

Start small - Contact + Lead - on a new engagement. Add more objects as campaigns require them.

Planning sync frequency

Contact Builder lets you configure sync frequency per object. Trade-offs:

More frequent: fresher data, higher API call consumption, more background load.
Less frequent: staler data, lower load.

Default for most Contact syncs: 15 minutes. Enough for daily campaigns and most triggered sends. Adjust down only if latency matters.

Takeaway

Synchronized DEs are the main value prop of MC Connect. Configure with the minimum field set you need, never edit them manually in SFMC, and pair with direct API lookups if you need true real-time freshness. Everything else in your Journey and email personalization just works once this is in place.

Configuring an SFMC + Salesforce CRM sync? Our Salesforce team sets up Synchronized Data Extensions and field mapping strategies on production engagements. Get in touch ->

See our full platform services for the stack we cover.

Triggering SFMC Journeys from Salesforce CRM Events

SapotaCorp — Sun, 24 May 2026 12:16:36 +0000

When Sales Cloud marks an Opportunity as "Closed Won," the customer should immediately receive the first email in an onboarding series. No marketing team middleman. No nightly export job.

That's exactly what Salesforce Entry Source in Journey Builder is for - trigger the Journey when a CRM record matches a filter.

Configuration

In Journey Builder, create a new Journey, choose Salesforce as the Entry Source:

Journey Builder -> New Journey -> Entry Source: Salesforce
  Object: Opportunity
  Filter: Stage = "Closed Won"
  Related Contact: Opportunity -> Contact (lookup)

When any Opportunity's Stage changes to Closed Won, SFMC receives the event via MC Connect, resolves the associated Contact via the lookup, and adds the Contact to the Journey.

That Contact then flows through the Journey's Send Email, Wait, and Decision Split steps like any other subscriber.

Common triggers by Salesforce Cloud

Sales Cloud

Opportunity Stage = "Closed Won"   -> Onboarding series for new customer
Lead Status = "Qualified"          -> Nurture sequence
Contract signed                    -> Activation series

Service Cloud

Case created                       -> Confirmation email with case number
Case Status = "Resolved"           -> Closure email + satisfaction survey
Case escalated                     -> Apology + update email

Experience Cloud (Community)

User registers in portal           -> Welcome series
Post without reply after 48h       -> Reminder to moderator
Member inactive 30 days            -> Re-engagement

Each of these is a standard pattern we've shipped on engagements. The trigger object and filter change; the Journey structure is roughly the same.

Two mistakes that bite first-time builders

Mistake 1: Forgetting the Contact lookup path

The trigger object might be Opportunity or Lead - not always Contact directly. Journey Builder needs to resolve the subscriber's email, so there must be a path from the trigger object to a Contact with an Email field.

Opportunity -> Primary Contact -> Email. Lead -> Email is direct. Case -> Contact -> Email.

Forgetting to configure the lookup leaves the Journey with no target subscriber. Behavior varies: sometimes Journey sends nothing, sometimes it errors, rarely is the message obvious.

Mistake 2: Re-entry on CRM state churn

Opportunity flips between Closed Won and Reopened multiple times (common during contract negotiations). Each time it hits Closed Won, the Contact re-enters the Journey and receives the onboarding series again.

Fix: Journey Settings > Contact Entry Mode > No Re-entry. Set this before launch. Once the Contact has entered this Journey, re-triggering doesn't add them again.

Exception: if the Journey is designed to repeat (annual renewal reminder), you want Re-entry on - but that's a deliberate choice, not a default.

What the CRM user sees

Salesforce CRM users don't interact with Journey Builder directly. The flow looks like:

Sales rep marks the Opportunity as Closed Won.
MC Connect fires the event to SFMC.
Journey Builder adds the Contact.
Customer receives the first onboarding email within minutes.

From the sales rep's perspective, it "just happens" - no additional action required.

Testing before going live

Always test in a Salesforce sandbox connected to an SFMC sandbox/non-production BU:

[ ] Create a test Opportunity with a Contact that has a deliverable email.
[ ] Change the Opportunity Stage to the trigger condition.
[ ] Verify in Journey Builder: the Contact appears in the Journey.
[ ] Verify the email arrives.
[ ] Repeat with edge cases: Opportunity without Primary Contact, Contact with missing Email field, Contact that's already unsubscribed.

Only after the full sandbox cycle passes is it safe to flip to production.

Takeaway

Triggering from CRM events is the key integration pattern MC Connect unlocks. Configure the trigger object + filter + Contact lookup carefully, set No Re-entry unless repetition is intentional, and test every edge case in sandbox before production. Once wired, Sales and Service teams get automated customer communication without any new process to learn.

Building CRM-triggered Journeys? Our Salesforce team configures Salesforce Entry Sources, Journey logic, and sandbox testing on production engagements. Get in touch ->

See our full platform services for the stack we cover.