For years, the missing Business Units feature kept large organizations from fully committing to Marketing Cloud Next. That blocker is gone. With the Spring '26 release, Business Units are generally available, so you can finally partition data, audiences, and campaigns by brand, region, or legal entity while keeping a single, central admin. This guide cuts through the marketing language and shows how the feature actually works: its strict 1:1 link to Data Spaces, how to scope channels and users, what it means for Einstein and Agentforce, and the traps to avoid if you are moving over from Marketing Cloud Engagement.

What is a Business Unit in Marketing Cloud Next?

A Business Unit (BU) is an isolated workspace with its own campaigns, audiences, content, and reporting. In practice, each team only sees what belongs to it: a German subsidiary cannot accidentally send to the French list, and one brand's analysts never muddy another brand's dashboards. Marketing Cloud Next supports up to 50 Business Units per org, which comfortably covers most multi-brand or multi-country setups.

This is a real departure from the "classic" Business Units in Marketing Cloud Engagement, which relied on a parent/child hierarchy and sometimes fuzzy data sharing. In Next, the separation is structural rather than cosmetic, because it is anchored in Data Spaces.

Business Units and Data Spaces: a strict 1:1 relationship

This is the single most important concept to internalize. In Marketing Cloud Next, every Business Unit is tied to exactly one Data Space, and vice versa. A Data Space cannot feed more than one BU. That 1:1 rule is what keeps one entity's data physically separated from the rest.

So before you create any BU, map your Data Spaces. Ask a simple question: which populations should never mix? Each answer usually maps to one Data Space plus one Business Unit.

Business Unit        Data Space           Active channels
-------------------  -------------------  ----------------------
BU-France            DS-France-CRM        Email, SMS
BU-Germany           DS-Germany-CRM       Email, WhatsApp
BU-Retail-Global     DS-Retail-Events     Email, Mobile Push

Setting up your Business Units step by step

1. Create the Data Space first

Always start with the Data Space, since it holds the data. Ingest your objects — contacts, consent, events — into that space before you wire up the BU.

2. Create the Business Unit and link it

Next, create the Business Unit and connect it to the matching Data Space. The API call looks something like this (illustrative example):

POST /marketing/v1/business-units
{
  "name": "BU-Germany",
  "dataSpaceId": "0Sp5f000000GmZ1CAK",
  "defaultTimeZone": "Europe/Berlin",
  "defaultLocale": "de-DE"
}

3. Verify the isolation

Send a test from the new BU and confirm that no other entity's audience is reachable. It is far cheaper to catch a leak in staging than in production.

Scoping channels and users

Each channel — Email, SMS, WhatsApp, Mobile App Messaging — is scoped either to a single Business Unit or to all of them. That lets you keep WhatsApp inside the one BU that has cleared its Meta account, without exposing it to every team.

On the access side, a user can belong to one or several BUs. Apply least privilege: grant multi-BU access only to admins and truly cross-functional roles. Local teams should live in a single BU, which reduces the odds of a costly mistake.

Einstein and Agentforce at the Business Unit level

Good news for data quality: Einstein features such as Send Time Optimization and Engagement Scoring are now business-unit aware. The models learn from the data in that specific BU, so a premium brand's behavior is not diluted by a discount banner's.

Likewise, Agentforce can operate within a defined BU boundary for campaign creation. The agent only draws on the audiences and content it is allowed to touch, which keeps compliance teams comfortable while preserving the productivity of generative AI.

The golden rule: one Data Space per Business Unit, decided before you create anything. Reworking that 1:1 relationship after the fact is painful — model it correctly from day one.

Migrating from classic (MCE) Business Units

If you are coming from Marketing Cloud Engagement, do not clone your old tree one-for-one. The MCE parent/child model often blended data inheritance with isolation; Next enforces a clean split through Data Spaces. Use the migration as a chance to simplify: merge BUs that only existed for historical reasons, and create new ones only where isolation is genuinely required.

Plan your consent governance too: Email, SMS, and WhatsApp consent mapping is rolling out gradually through 2026 and needs to line up with how you carve your BUs.

Rolling out Marketing Cloud Next across multiple brands? Let's talk through your data model before you spin up that first Business Unit.

Key takeaways

1. Generally available. Business Units are GA in Marketing Cloud Next as of Spring '26, with up to 50 BUs per org.

2. Strict 1:1. Every Business Unit maps to exactly one Data Space — the most structural architecture decision you will make.

3. Granular scoping. Channels and users scope to one BU or all of them: apply least privilege throughout.

4. AI stays contained. Einstein STO, Engagement Scoring, and Agentforce all respect BU boundaries.

5. Migration is rationalization. Don't copy the MCE tree; rethink your structure around Data Spaces.