Marketing Cloud Config: Style Guide
The opinionated rules Cleon applies to every Marketing Cloud config decision — naming, documentation, runbook discipline, patterns to prefer, anti-patterns to refuse — distilled from the Config catalog into a single discipline document. Mirrors the SQL, SSJS, and AMPscript Style Guides; closes the catalog at 7 page-pairs.
This is the page where Cleon stops describing what MC configuration is and starts saying what we do with it. Salesforce defines what's possible. The reference pages in this catalog document the shape of each config surface. The gotchas document the bootstrap choices that compound. This Style Guide is the discipline that keeps a Marketing Cloud tenant operable a year after the rollout, when the people who configured it are no longer the people running it.
Use it as a checklist before merging any config change into production — a new BU, a new Send Classification, a new Data Extension, a SubscriberKey strategy update, a Sender Profile clone. The rules are short on purpose — when a rule needs an explanation, the explanation is in the page it links to.
Naming
Data Extensions follow the prefix convention from the SQL Style Guide
The DE prefix convention defined in SQL Style Guide — DE_, de_stg_, de_log_, de_log_<sdv>_, de_lookup_, TS_, J_, Auto_, CR_ — applies tenant-wide. Every BU. Every DE. Decided once at bootstrap; documented in the team runbook; enforced in code review.
The Cleon convention adds two more prefixes for Config-layer DEs:
| Prefix | Holds |
|---|---|
| de_log_audit_ | Audit Trail export DEs (see gotchas — #8) |
| shared_DE_ | Enterprise 2.0 Shared DEs (see BU architecture) |
Business Units are named with the axis + value
Per BU architecture. The BU name encodes the axis (Brand / Region / Product / Sandbox) and the specific value. Acme-Region-Americas not BU_2. Acme-Sandbox-Staging not Sandbox. The visible axis is the documentation the next person needs.
Send Classifications are named SC_<Classification>_<Purpose>
Per Send Classifications. The prefix marks the asset type, the classification flag spells out Commercial vs Transactional, the purpose names the kind of send.
| Pattern | Example |
|---|---|
| SC_Commercial_<purpose> | SC_Commercial_Newsletter, SC_Commercial_Marketing |
| SC_Transactional_<purpose> | SC_Transactional_PasswordReset, SC_Transactional_OrderConfirmation |
A tenant with more than ~10 Send Classifications is over-classified. Reuse before creating.
Sender Profiles named per brand persona, not per program
Per Send Classifications. The persona name reflects the recipient-visible identity ("Acme", "Acme Support", "Acme Newsletter"), not the program ("Q4 Promo", "Welcome Email").
SubscriberKey is opaque
Per SubscriberKey strategy. The value contains no PII, no encoded attributes, no decodable identity information. UUID, internal integer ID, or hash — never the email address, the phone number, or "firstname-lastname-1990".
Documentation discipline
The team runbook is the source of truth
Marketing Cloud's UI is one source. The runbook is the source. If the UI and the runbook disagree, the question is which one is wrong — not "let's just use whichever". Every config decision documented on the surfaces below is also documented in the runbook with a date, a rationale, and an owner.
Every BU has a documented owner
Per BU architecture. The owner is the team or individual responsible for the BU's config integrity. When a BU has no documented owner, it's an orphan-in-waiting.
Every Shared DE has a documented writer + readers
Per DE architecture — #8 and BU architecture. The writer is the BU that owns the schema; the readers are the BUs that consume. Without documentation, the second person to inherit the Shared DE doesn't know who to talk to about it.
Every Send Classification has a documented Commercial / Transactional rationale
Per Send Classifications. Commercial classifications need no special justification. Transactional classifications need legal sign-off documented in the runbook — the use case (password reset, receipt, account verification), the legal review date, the person who approved.
Every SubscriberKey decision is documented with the source-of-truth system
Per SubscriberKey strategy. The runbook entry includes the source system (CRM / app DB / identity service), the format (UUID / integer / hash), and the mapping to downstream identifiers.
Every config change is logged in the team runbook with date + rationale
The runbook has a "config changelog" section. Every change adds an entry: who made the change, when, what was changed, why, what was tested, what to monitor. The next person investigating an issue six months later reads the changelog to understand what happened.
Every Data Retention Policy is set at DE creation, documented in the DE description
Per DE architecture — #6. The retention period appears in the DE's description field in MC, and in the team runbook. Changing retention later is operationally expensive; documenting the choice prevents the change from becoming a debate.
Patterns to prefer
Default to single-BU; split on an unambiguous axis only
Per BU architecture. Single-BU is the cheapest to operate. Multi-BU is a multi-year commitment to operational overhead. Split only when at least one of the four criteria (regulatory boundary, sender reputation, audience disjointness, user access) is unambiguous.
Complete the SAP before the first production send fires
Per SAP setup. The default tracking domain *.exacttargetapps.com triggers corporate spam filters. SAP completion is a launch blocker, not a "we'll do it next week" item.
Mint SubscriberKey upstream, in a system you control
Per SubscriberKey strategy. The source-of-truth lives in your application database, your identity service, or a CDP that survives downstream re-platforming. MC consumes the value but doesn't own it.
Verify destination DE primary key at creation
Per DE architecture — #4. PK at creation, never retrofitted. The cost of "UpsertData duplicates" (see AMPscript debugging) compounds across every Cloud-write block in the tenant.
Set Data Retention Policy at DE creation
Per DE architecture — #6. Retention later is a mass-delete event. Retention at creation is a checkbox.
Default new BUs with Installed Package toggles OFF
Per BU architecture and gotchas — #6. Toggle ON explicitly per BU per package. Default-on is the path of least resistance and the most operational drift.
Run a real test send after every config change that affects sending
Per SAP setup — Step 6. New BU, new Sender Profile, new Send Classification, new SAP — every change runs through a test send to a real test subscriber in a staging BU before the next production send.
Default Send Classifications to Commercial; document Transactional carve-outs
Per Send Classifications and gotchas — #4. The Transactional flag is a privilege requiring legal sign-off, not a setting picked for "better deliverability".
Document SubscriberKey, BU axis, and SAP configuration in the runbook the first day
Per every page in this catalog. The runbook is the source of truth. Day-one documentation costs hours; six-month documentation costs days.
IP warming follows the gradual schedule, no exceptions
Per gotchas — #7. Warm gradually over 4-5 weeks. Reputation hits from a cold IP take months to recover. The launch team's urgency does not change the schedule.
Enable Audit Activities on every production tenant
Per gotchas — #8. The 6-month UI Audit Trail is not enough. Exporting to a DE makes audit data permanent, queryable, and joinable with other log DEs.
Patterns to refuse
"Just create another BU" as a band-aid
Per BU architecture. Naming collisions, "different team", "different campaign" — none are valid reasons to create a BU. The fix is naming the assets distinctly within the existing BU.
Sending without a complete SAP
Per SAP setup and gotchas — #9. The default tracking domain is a deliverability cliff. SAP is a launch blocker.
Email Address as SubscriberKey
Per SubscriberKey strategy and gotchas — #1. Emails change; SubscriberKeys don't. The cost of migrating later is rebuilding the All Subscribers list.
Tagging marketing sends as Transactional
Per Send Classifications and gotchas — #4. CAN-SPAM violation. Legal exposure. Catch-up cost when a regulator notices.
Sandbox BU without its own SAP
Per BU architecture. A Sandbox sending from the production domain — or from *.exacttargetapps.com — burns sender reputation when test sends accidentally land in production mailboxes.
Moving assets between BUs
There is no mv operation in MC. Per BU architecture. When the BU axis is wrong, pause, restate, and recreate. Cutting corners by "moving" is multi-week migration work disguised as a quick task.
Adding a Primary Key to a populated DE
Per DE architecture — #4. Fails on duplicates. PK at creation, while the DE is empty, or rebuild the DE.
Renaming a DE column with active downstream consumers
Per DE architecture — #10. Add the new column, migrate consumers, deprecate the old. Never silent rename.
Cloning a Sender Profile across BUs without verifying SAP
Per Send Classifications. The clone preserves visible settings but not SAP. The destination BU sends from *.exacttargetapps.com until its own SAP is complete.
IP warming skipped because "we're behind schedule"
Per gotchas — #7. The reputation hit from a cold IP doesn't unwind on schedule; it unwinds in months. The schedule slip is shorter than the reputation recovery.
Running production sends from a tenant without Audit Activities
Per gotchas — #8. Six months of UI Audit Trail is the only history; after that, nothing. Production tenants without Audit Activities are accepting that audit-questions older than six months are unanswerable.
Creating BUs, Send Classifications, or Sender Profiles without runbook entries
Per documentation discipline. The asset exists; the rationale doesn't. The next person inherits an asset they can't change because nobody knows what it's for.
The discipline check before any config change ships
Before any Marketing Cloud config change goes from draft into a published BU, activated Sender Profile, live Send Classification, or production DE, walk through this checklist:
- [ ] The change is documented in the team runbook with date, rationale, and owner
- [ ] The naming follows the convention for the asset type (
DE_*/de_stg_*/de_log_*/de_lookup_*/SC_<Class>_<Purpose>/ BU<Brand>-<Axis>-<Value>) - [ ] If creating a new BU: the axis is unambiguous; the 11-item BU architecture checklist is complete
- [ ] If creating a new DE: prefix, sendable-or-not, PK, column types, retention policy, nullability all set at creation
- [ ] If creating a Shared DE: writer + readers + migration plan documented in the runbook
- [ ] If activating a new SAP: DNS verified via
dig; quiet-window scheduled; test send across multiple mailbox providers - [ ] If creating a Sender Profile: bound to a Send Classification with the right Commercial / Transactional flag
- [ ] If marking a Send Classification as Transactional: legal sign-off documented in the runbook with date + approver
- [ ] If changing SubscriberKey: 12-item SubscriberKey checklist complete; All Subscribers configuration verified
- [ ] If launching a new IP: gradual warming schedule documented and started
- [ ] If installing or modifying an Installed Package:
Available in this Business Unittoggles explicitly set per BU - [ ] Data Retention Policy set at creation for any new DE
- [ ] Test send (real subscriber in staging BU) verifies end-to-end behavior before activation
- [ ] Audit Activities is enabled on the tenant (or a manual documentation alternative is in place)
- [ ] The change has a rollback procedure documented in case it needs to be undone
When all fifteen fire, the config change is ready to ship.
Related
- Marketing Cloud principles from production — the meta-rules above the Config specifics
- MC Config gotchas — the bootstrap choices this Style Guide is designed to prevent compounding
- Sender Authentication Package setup — the foundational rollout
- Business Unit architecture — when and how to split BUs
- Data Extension architecture — the schema choices that outlast every other decision
- Send Classifications — Commercial vs Transactional, the regulatory layer
- SubscriberKey strategy — the identifier strategy across the tenant
- MC SQL Style Guide — the sibling discipline page for SQL Activities; the DE prefix convention originates there
- MC SSJS Style Guide — the sibling discipline page for SSJS scripts
- MC AMPscript Style Guide — the sibling discipline page for AMPscript
Catalog progress: with this Style Guide, the Config subcategory closes at 7 page-pairs — 2 production-note (gotchas + DE architecture) + 3 decision-framework (BU architecture + SubscriberKey strategy + Style Guide) + 1 how-to (SAP setup) + 1 reference (Send Classifications). The Marketing Cloud documentation catalog is now complete at the subcategory level: SQL (19 pages), SSJS (13 pages), AMPscript (14 pages), Config (7 page-pairs).
If you spot a rule missing — or one of these rules being violated in our public work — write to hello@wearecleon.com. We add it, or we fix it and we say so.