Business Unit architecture decisions | Cleon

Business Units are Marketing Cloud's mechanism for dividing a tenant into independent sub-tenants — separate audiences, separate Send Definitions, separate Automations, separate API users. The decision to use multi-BU (or stay single-BU) is one of the largest architectural choices in an MC implementation. It's made once at bootstrap and difficult to unwind, because every asset created lives at a specific BU and there is no operation to move it to another BU — only recreate it. See gotchas — #2.

This page is the decision framework for that choice. It walks through the four common BU patterns and when each fits, the table of what propagates from parent BUs vs what each BU controls independently, plus the checklist Cleon walks through before creating any new BU.

The decision tree

Start here ─→ Is the tenant sending to disjoint audiences
              that should never see each other's data?
              ├── Yes ─→ Multi-BU candidate. Continue.
              └── No  ─→ Single BU. Stop here.
                          
Multi-BU candidate ─→ Choose the axis of separation:
                       ├── Per brand     (Acme + Acme Pro + Acme International)
                       ├── Per region    (Americas + EMEA + APAC)
                       ├── Per product   (Newsletter + Promo + Support)
                       └── Parent + sandbox (Production + Staging)
                       
Per-axis BU ─→ For each BU you'd create, ask:
               ├── Do users in this BU need access ONLY to its data?
               ├── Are the Sender Profiles + From Names different here?
               ├── Are the Send Classifications regulatory-different?
               └── Will this BU send at least monthly?
               
If all 4 are yes ─→ Create the BU.
If any are no    ─→ Reconsider; the work may not justify the operational overhead.

The four common patterns

| Pattern | When it fits | Cost | |---|---|---| | Per brand | Acme + Acme Pro + Acme International — truly independent brand identities, different legal entities, different Privacy policies | High operational overhead (separate Sender Profiles, separate SAPs); medium audience-sharing cost (very rare) | | Per region | Americas + EMEA + APAC — different data-residency requirements (GDPR vs CCPA vs LGPD), different locale defaults | Medium operational overhead (regional teams + audit); low audience-sharing cost (regional sends don't overlap) | | Per product | Newsletter + Promo + Transactional — different volume profiles (transactional needs separate sender reputation from marketing) | Low operational overhead if products share most config; high audience-sharing cost if the same subscriber gets every product's emails | | Parent + sandbox | Production + Staging within the same tenant (if your MC edition allows) | Low ongoing cost; high one-time SAP cost (each BU gets its own SAP); valuable for safely-testing config changes before they hit prod |

Pick the primary axis first, then add more BUs only when the second axis is independently justified. A tenant with Acme-Americas-Newsletter, Acme-Americas-Promo, Acme-EMEA-Newsletter, Acme-EMEA-Promo is four BUs on two axes — operationally expensive, justified only when both axes are truly disjoint.

What propagates from the parent BU

This is the table you need before deciding whether a BU split helps:

| Item | Behavior | |---|---| | Subscriber Attributes (All Subscribers profile) | Shared across all BUs — defined once at the enterprise level | | Master Subscriber List (_Subscribers) | Shared across all BUs by default; sub-BUs see all subscribers | | Data Extensions | Created at a specific BU; not automatically shared. To share, use Enterprise 2.0 Shared DEs explicitly | | Sender Profiles | Created at a specific BU; can be cloned across BUs but not auto-propagated | | Sender Authentication Package | Per-BU; each BU has its own sending domain + DKIM + DMARC alignment | | From Address / Reply Address defaults | Per-BU; the BU-level setting overrides any account-level default | | Send Classifications | Defined at the enterprise level; available to all BUs unless restricted | | Installed Packages | Installed at the parent BU; per-BU Available in this Business Unit toggle (see gotchas — #6) | | User permissions | Per-BU; a user can have different roles in different BUs | | API credentials | Tied to specific BUs via the Installed Package's BU-level scope | | Automations | Per-BU; cannot reference assets from another BU directly | | Journeys | Per-BU; can read DEs from sibling BUs only via explicit Shared DE configuration | | Audit Trail | Per-BU; audit events show the BU context but logs are tenant-wide |

The take-away: most assets are per-BU (DEs, Sender Profiles, Automations, Journeys), while identity is shared (Subscriber Attributes, Master Subscriber List). The hand-off failure happens when teams assume DEs propagate down from a parent — they don't. A DE created at the parent is invisible to child BUs unless explicitly shared.

Patterns to prefer

Start with one BU; split when an axis is unambiguous

The single-BU tenant is the cheapest to operate. Multi-BU adds operational overhead at every layer: every Sender Profile is per-BU, every API credential is per-BU, every Automation lives in one BU, every report is filtered by BU. Defer the split until at least one of: regulatory boundary, sender-reputation requirement, or audience disjointness is unambiguous.

Document the BU axis explicitly

Name every BU with a convention that encodes its axis. Acme-Brand-Newsletter or Acme-Region-EMEA reads correctly six months after the rollout. BU_2 or Acme Sub does not. The Cleon convention: BU name includes the axis label and the value (e.g. Acme-Region-Americas not just Acme-Americas).

Default new BUs with explicit Installed Package toggles

After creating a BU, immediately walk the Installed Packages list and explicitly toggle Available in this Business Unit ON or OFF for each. Default-on (the path of least resistance) means every API credential the parent has is now usable in the new BU; default-off and you have to deliberately add each one. The Cleon convention: default-off, explicitly add each package per BU.

Run a "first send" smoke test from each new BU before opening it to users

The smoke test catches misconfigured Sender Profiles, SAP propagation failures, and missing Installed Package toggles before real production work starts in the new BU. The test send pattern from SAP setup — Step 6 applies to every new BU.

Use Enterprise 2.0 Shared DEs sparingly and document each one

Shared DEs are the legitimate mechanism for cross-BU data access. They're also a vector for confusion (which BU writes? which BU reads?). Every Shared DE should have a documented owner (the BU that writes), documented readers (the BUs that read), and a schema review at creation. Without documentation, the second person to inherit the Shared DE doesn't know who they can talk to about it.

Plan SAP per-BU before activating any production sends

Each BU needs its own complete SAP (see SAP setup). Running production sends from a BU with the default tracking domain is the deliverability disaster covered in gotchas — #9. The Cleon convention: a BU is not "active for sending" until its SAP is complete and a test send verifies it.

Patterns to refuse

"Just create another BU" as a band-aid for naming collisions

If two teams want to use the same DE name with different schemas, creating a separate BU per team doesn't solve the problem — it just moves it. The real fix is naming the two DEs differently and keeping them in the same BU where they can be operated together.

A BU per campaign

Campaign-level BUs are operationally catastrophic. Each campaign needs its own Sender Profile, its own SAP work, its own audit trail. Campaigns are Send Definitions or Journeys; they should live within a BU, not be a BU.

Cross-BU reads via "everyone has access to everything"

If you give every user access to every BU, you've negated the separation. Either commit to BU separation with the per-BU access model that comes with it, or stay single-BU and use Folders + DE naming for organization.

Sandbox-without-SAP

A "Sandbox" BU that uses the parent BU's SAP (or no SAP at all) is sending from the wrong domain — confusing recipients and burning sender reputation when test sends accidentally reach real subscribers. Either the Sandbox BU has its own SAP using a dedicated subdomain (e.g. sandbox-mail.yourbrand.com), or it doesn't send externally at all.

Moving assets between BUs

There is no mv operation. If you find yourself wanting to move assets between BUs, the BU architecture is wrong — pause the work, restate the BU axis, recreate in the correct location. Doing this once during bootstrap costs days; doing it later costs weeks.

Per-product BU when products share the audience

If the same subscriber gets emails from Acme-Newsletter, Acme-Promo, and Acme-Support, splitting them across BUs duplicates the subscriber maintenance burden — every list change has to be applied three times. Stay single-BU and use Send Classifications + Folders to separate the products operationally.

The decision checklist before creating a new BU

Before creating any new BU, walk through this checklist:

[ ] The axis of separation is unambiguous (brand, region, product, sandbox)
[ ] At least one of the four "regulatory / sender reputation / audience disjointness / user-access" criteria justifies the new BU
[ ] The BU's expected send volume is at least monthly (low-volume BUs don't earn their overhead)
[ ] The Sender Authentication Package will be configured per-BU before any production send fires
[ ] The Installed Packages list has been audited; each one is explicitly toggled for the new BU
[ ] A Sender Profile is configured for the new BU with the brand-correct From Name + Reply Address
[ ] At least one test send has verified the BU's SAP end-to-end (see SAP setup — Step 6)
[ ] User access is per-BU; nobody has access by default; access is granted explicitly
[ ] The BU name follows the naming convention (axis label + value)
[ ] A documented "first month after creation" review is scheduled to catch any drift before it compounds
[ ] The decision is documented in the team's infrastructure runbook (which axis, which BUs, who owns each)

When all eleven fire, the BU is ready to create. If any are unclear, the answer is "don't create the BU yet" — the cost of an unjustified BU is years of operational drag.

MC Config gotchas — see #2 (BU hierarchy is one-way), #6 (Installed Package per-BU toggle), and #9 (SAP needed per-BU)
SAP setup — every new BU needs its own SAP completed before sending
SQL Style Guide — the DE naming convention applies at every BU
SSJS — Debugging WSProxy auth — see step 5 for cross-BU setClientId scenarios that depend on Installed Package per-BU configuration
AMPscript — Cloud-write functions — Cloud-writes from a BU depend on the BU's MC Connect configuration

Catalog progress: with this page, Config has 3 page-pairs (gotchas + SAP setup + BU architecture). Following the SQL/SSJS/AMPscript shape, next pieces target Send Classifications (reference), Data Extension architecture (production-note), Subscriber Key strategy (decision-framework), and the Config Style Guide.