Six SFMC Features That Solve Problems Most Teams Don't Know About

SFMC has a long tail of features that appear in certification exams but rarely in production implementations. Six that solve common problems but get overlooked. Reference post to close out the series.

1. Subscriber Key vs Primary Key

Two distinct concepts often conflated:

• Subscriber Key: unique identifier across the entire SFMC account. One person = one Subscriber Key. Used by All Subscribers list.
• Primary Key: unique identifier within a specific Data Extension. Defines how rows dedupe within that DE.

Common pattern in sendable DEs: Primary Key = Subscriber Key. Same column does both jobs.

But they don't have to match. A customer DE might have Primary Key = CustomerID; Subscriber Key column could be EmailAddress or a separate BusinessID. The distinction matters when:

• One person has multiple DE rows (e.g., multiple accounts, one per product)
• Different DEs identify subscribers by different identifiers
• You're migrating between identifier schemes

Rule of thumb: pick a BusinessID / CustomerID as Subscriber Key, not EmailAddress. Covered in depth in an earlier subscription management post.

2. Is Testable on Data Extensions

DE Properties has an Is Testable flag. If false (default), the DE does not appear in the "Recipient Test Data Extension" dropdown during Test Send.

Happens constantly: team builds a DE, tries to Test Send, DE isn't in the dropdown, confused. Solution: DE > Properties > check Is Testable > save.

No error message when it's missing - just a silent absence from the picker. Easy to miss during debugging.

3. Send Log DE and Test Send

Test Sends do not write to Send Log DE. Only production sends do.

Implication: verifying Send Log configuration works requires running an actual production send, not just a Test. For verification, do a small production send (50 subscribers) to an internal-only DE, confirm Send Log populates.

Catches surprise in UAT when Send Log expected to have data and doesn't - Test Sends weren't logging.

4. Multilingual Content Blocks

Global brand with subscribers in multiple countries. Email templates need to render in subscriber's preferred language.

Multilingual Content Blocks store multiple language versions of the same content. SFMC picks the right version based on the subscriber's locale attribute.

Benefits over separate emails per language:

• One email asset, many languages
• Translations can be uploaded by agency translation team without developer involvement
• New languages added to existing emails without rebuilding

Setup:

1. Subscribers have a Locale or Language attribute in their DE
2. Create a Multilingual Content Block with versions per language
3. Insert into email; SFMC picks the matching version at render time

Use when: 3+ languages in the audience, recurring emails, translation workflow is separate from development.

5. Data Retention Policy on DEs

Every DE can have a Data Retention Policy setting - automatically delete rows older than X days/weeks/months.

No custom automation needed for cleanup. SFMC auto-expires rows.

Use cases:

• Event signups: delete registration rows 30 days after event
• OTP tokens: delete after 24 hours
• Session tracking: delete after relevant window
• Temporary segmentation DEs: delete weekly

Saves space, simplifies compliance (GDPR "minimal retention"), removes the need for cleanup automations.

Not used much because most teams don't know it exists. Worth checking if your client has any DEs that should self-expire.

6. Random Data Extension

Split a DE into N equal random groups. Built-in feature.

Use cases:

• A/B/N testing setup: split audience before Journey Builder, each group enters a different journey variant
• Rolling rollout: split audience into 7 groups, send to one per day across a week
• Training data splits: separate train/test sets for any analysis

Point-and-click alternative to writing SQL for random sampling.

Bonus: Send Classification and Commercial/Transactional

Every send has a Send Classification controlling who receives:

• Commercial - respects all unsubscribes including marketing opt-outs
• Transactional - respects hard-bounced and spam-complained only; sends to unsubscribed subscribers

Critical distinction: sending a promotional email with Transactional classification is a compliance violation. Transactional classification is reserved for order confirmations, account notifications, security alerts.

On every new account, audit Send Classifications - commercial sends should never use Transactional classification to bypass opt-outs.

Takeaway

SFMC has dozens of features beyond the 20 or so everyone uses. Multilingual Content Blocks, Data Retention Policy, and Random DE each solve specific problems cleanly. Is Testable and Send Log + Test Send are gotchas that cost hours when missed. Subscriber Key vs Primary Key is foundational. Worth a team reference wiki entry covering these - the kind of institutional knowledge that saves new engineers weeks of confusion.

---

Running SFMC certification prep or onboarding engineers? Our Salesforce team runs knowledge transfer sessions and builds reference docs tailored to client teams on production engagements. Get in touch ->

See our full platform services for the stack we cover.