Three SFMC traps the MC-202 prep made us re-document

One Sapota engineer just cleared the Salesforce Certified Marketing Cloud Email Specialist exam (MC-202) on April 18, 2026, finishing in 52 of the 90 minutes allowed after two weeks of focused prep.

The exam itself was straightforward. The unexpected part was that going back through the official documentation surfaced three traps even hands-on teams tend to misread, and we added all of them to the default SFMC engagement handover doc the day the cert came through.

Trap 1: Send Logging is off by default on every new BU

Most teams discover this when the compliance team requests an audit of who received what email and the export comes back empty.

The Send Log Data Extension is opt-in. It has to be created and explicitly turned on in the BU before the first send actually goes out. Anything sent before logging is enabled is gone for good, with no backfill path, no _SendLog shadow table to query, and no archive in Account Engagement. The architectural reason is that SFMC writes logs forward-only as part of the send pipeline; without a target DE configured, the writes are no-ops.

In production this becomes painful around month three, when a regulator or internal audit asks "show me the consent and content for these sends" and the platform responds with two months of nothing.

The Sapota playbook is to ship Send Log DE creation and the tracking job that populates it as part of the BU bootstrap checklist, not the first campaign.

Trap 2: AMPscript datetime functions follow account HQ time, not BU time

If the Marketing Cloud account is anchored in the United States but a BU serves customers in Singapore, NOW(), DateAdd(), and DateDiff() inside AMPscript return US time. The BU's local timezone setting does not reach the AMPscript runtime.

This breaks two things in subtle ways:

1. Hourly reporting and time-based segmentation end up off by 12 to 15 hours from what the local marketing team expects. Send-time optimization keyed off NOW() puts the email out at the wrong end of the customer's day.
2. Time-stamped fields stored back into Data Extensions carry HQ time, not BU time. Downstream reporting in Datorama, Snowflake, or BI tools then needs to know which timezone the value is actually in to convert correctly.

The workaround Sapota ships is to convert into the BU local timezone explicitly inside the template, or to read a pre-computed local timestamp from a DE field rather than reaching for AMPscript datetime helpers directly.

%%[ /* NOW() here returns HQ time, not BU time. */ var @hqNow, @sgNow set @hqNow = Now() set @sgNow = DateAdd(SystemDateToLocalDate(@hqNow), 8, "h") ]%% `` This email was prepared at %%=Format(@sgNow, "yyyy-MM-dd HH:mm")=%% Singapore time.

The exact offset depends on the account setup and DST handling for the local market. Validate against a test send before relying on the value in production.

Trap 3: Triggered Sends bypass the Suppression List by default

A customer unsubscribes from the brand. They keep getting order confirmations and password reset emails. Marketing ops gets a complaint. The team digs in and finds the unsubscribe was honored on the publication and the All Subscribers status flipped to Unsubscribed cleanly. Yet the Triggered Sends went out anyway.

The reason is that SFMC does not apply Suppression Lists to Triggered Send Definitions automatically. The suppression has to be configured explicitly on each Triggered Send Definition's properties tab, with no global toggle to flip it on for all transactional sends in a BU.

In practice this means teams have to:

1. Audit every Triggered Send Definition currently active.
2. Add the relevant Suppression Lists under Properties on each one.
3. Bake the suppression check into a deployment template so new Triggered Sends inherit it.

Sapota has seen this trap force two clients into incident-response mode after compliance teams flagged inbound complaints. It is one of the easier configuration misses to make and one of the harder ones to retrofit cleanly across a portfolio of dozens of Triggered Sends.

Why these three are now day-one items

The cert prep forced the team to re-read documentation that hands-on time tends to skim, and the gap between "read it once" and "actually checked it on a live BU" is where these traps live. All three are now on the day-one audit checklist for every new SFMC engagement Sapota onboards.

If your team is preparing for MC-202, the official Salesforce documentation on Send Logging, AMPscript datetime behavior, and Triggered Send setup are all worth a slow second pass, even if you have shipped SFMC for years.

---

Looking at an SFMC build, migration, or cleanup? Sapota's Salesforce team works with B2B SaaS startups in Singapore and Australia on staff-augmentation engagements with a 2-week paid trial. Get in touch →

See our full Salesforce service for the stack we cover.