If you manage multiple brands, you’re likely familiar with this challenge. 

Suppose a customer has been one of Brand A’s best customers for years. She then makes her first purchase from Brand B, another brand in the same retail group. Brand B sees a first-time buyer and sends her a new-customer discount. Brand A knows she is already a loyal customer. 

Neither brand’s data is wrong, of course. The problem is that the two brands may not have a way to use the same customer identity across their separate data environments. 

It’s an architectural issue. 

Salesforce Marketing Cloud Business Units help you decide where a customer’s identity is unified and where it stays separate, and that starts with how you structure each unit’s data space.

What are Business Units in Salesforce Marketing Cloud Next?

A Business Unit in Salesforce Marketing Cloud Next is a division of your org with its own campaigns, audiences, content and reporting. Each unit maps to exactly one data space, and that data space can’t be linked to any other Business Unit. 

As of October 2026, an org can create up to 150 Business Units.

A few structural details shape everything else:

Element	How it behaves in Marketing Cloud Next
Data	One data space per Business Unit, kept separate from other Business Units
Campaigns	Assigned to a Business Unit at creation; the assignment can’t be changed later
Users	Members can access their unit’s segments, flows, personalization and Marketing Performance Intelligence
Subscriptions	Can apply to one Business Unit or all of them, depending on configuration
Identity resolution	A ruleset is configured for each Business Unit’s data space
Deactivation	A deactivated Business Unit can’t be reactivated

The first unit is built from your existing marketing configuration, and Salesforce has you create the first two together. 

How do Business Units support multi-brand marketing?

Business Units give each brand its own wall. Its own campaigns, audiences and reporting, with customer data kept separate from other Business Units. If your legal team requires Brand A’s customer data to remain separate from Brand B’s, this architecture provides that separation. Regional brand managers can also run their own campaigns and measure results independently.

The tension appears when the same retail group wants to understand and activate customers across brands.

The customer who buys homeware from one banner and clothing from another has one relationship with the retail group. But if those brands sit in separate Business Units, their data and identity resolution remain separate too.

Salesforce identity resolution operates within a data space rather than merging customer identities across Business Units. Each unit has its own identity resolution ruleset, producing separate unified customer profiles when the same customer appears in different data spaces. Hold that thought when deciding if brand separation should be structural or managed through permissions and operating rules.

Flagship and discount brand: one data space or two?

Suppose a retail group runs a flagship brand and a discount sub-brand. 

Some customers shop both, and the group wants discount shoppers to trade up to the flagship without flooding full-price customers with outlet promotions. 

There are two ways to build this, and each has different implications for customer identity and campaign activation.

Question	Two Business Units, two data spaces	One Business Unit, one data space
Customer who shops both brands	Two separate unified profiles, one per data space	One unified profile, provided the source records are matched
Cross-brand trade-up campaign	Requires the relevant data to be made available in the target data space or a shared data space for the use case	Possible in one segment, with appropriate brand filters
Opt-out in one brand	It depends on whether each subscription is set to apply to one business unit or all of them (the article’s own table earlier says this). Use an all-units subscription for opt-outs that must apply group-wide. Also suggest the brands confirm with counsel whether one legal entity means an opt-out must apply to both.	Give each brand its own subscriptions. An opt-out from the discount brand’s newsletter then doesn’t touch the flagship’s. A channel-level email opt-out still applies to both
Brand separation	Structural; each team operates within its own data space	Managed through processes, permissions, sender identities and access policies
Risk	Duplicated records and separate identity resolution work. The same customer data may need to be ingested and stored twice, each data space requires its own identity ruleset that consumes Data 360 credits, and the additional Business Unit requires a licence.	A segment can include the other brand’s customers if the brand filter is missing
Reporting	Per brand by design; group reporting needs deliberate setup	Group view can be easier to assemble; brand reporting needs scoping

The trade-up row is where the architecture becomes operational. In a two-Business-Unit setup, a segment built for Brand A can’t simply query Brand B’s separate data space. The required customer and transaction data must first be made available in the target data space through an appropriate data-sharing or ingestion approach. Another option is to design the use case around a shared data space, where the relevant data can be accessed under agreed governance rules. Because each data space belongs to exactly one Business Unit, this approach requires a third Business Unit to run campaigns from the shared data space. That unit needs its own licence and identity ruleset, and its identity resolution consumes Data 360 credits. 

The implementation choice depends on where the data originates, which records need to be shared and how access should be controlled.

The one-unit risk is straightforward: a segment can pull in the other brand’s customers if the marketer doesn’t add the appropriate brand filter. Salesforce states that row-level security policies aren’t enforced during segment creation, so all records within the object are considered when a segment is created, even though object- and field-level enforcement is in effect.

Our view: If the two brands share customers and no legal or structural requirement forces separation, start without Business Units, using the default single data space, and design the governance inside it. Enable Business Units when separation is a mandate, such as for separate legal entities, regional data rules or brands that must never share a customer file. Enabling Business Units creates the first two together, and a deactivated Business Unit can’t be brought back. Business Units may require the Advanced edition, so the two-unit option carries an additional licensing cost. 

Why does customer identity resolution matter across Business Units?

Salesforce identity resolution decides who counts as one person within each Business Unit’s data space. A unified profile links source records rather than replacing them with a master record.

Your Business Unit and data space architecture therefore determines whether customers who shop across brands can be represented by one unified profile or remain separate.

Each Business Unit gets its own identity resolution ruleset. The generated ruleset for individuals uses normalized email, lead-to-contact and device-to-known match rules. Salesforce recommends one active ruleset per data space for the Individual object because rulesets consume Data 360 credits and additional rulesets increase billing.

Choosing one data space or several has different consequences.

Unified customer profile vs. siloed profiles

• Unified customer profile: Supports cross-brand lifecycle campaigns, such as trade-up, win-back and frequency control across banners. It requires agreement on shared consent, data access and ownership.
• Siloed profiles: Give each brand greater autonomy and a simpler separation model, but the group loses a unified view of the customer. Rebuilding that view later may require ingesting data again.
• Anonymous visitors: An anonymous profile becomes known inside the data space where it already lives, not across data spaces. If two brands share a website or app, decide which Business Unit and data space will receive that activity before traffic flows.

Real-time matching matters when anonymous interactions need to become known quickly. Built on a real-time data graph, it can link users to unified profiles in milliseconds as identity data is collected, but only with exact or exact normalized match methods.

For a shared website or app, the key decision is where activity enters the architecture. If both brands’ activity enters the same data space, real-time matching can resolve a visitor against the unified profiles available there. If activity enters separate data spaces, the visitor is resolved within each environment. Real-time matching makes identity resolution faster; it doesn’t remove the boundary between data spaces.

What should you decide before building Business Units?

Settle these six questions with marketing, data, legal and the brand owners first.

1. What customer data is shared across brands?

Identity, purchase history, loyalty status and web activity can each have a different answer. Name the owner of each category, and confirm the consent basis for one brand using another brand’s data.

2. Who owns cross-brand reporting?

Business Unit members get their own unit’s performance reporting, so someone needs to own the group-level view. Decide who should have group-level visibility and how brand-level reporting should be scoped. Check how your marketing data objects are filtered by unit before assuming a dashboard is brand-scoped.

3. How will suppression and opt-outs work across brands?

Marketing Cloud Next treats a contact with no consent value as opted out, and consent held in Salesforce CRM isn’t recognized automatically. Existing CRM consent must therefore be imported into Marketing Cloud Next. You also need to define whether the relevant subscriptions apply to one Business Unit or all of them.

4. Who can work in more than one unit?

Users in several Business Units can work with records across those units. Define roles and approvals before granting access so a marketer doesn’t accidentally build or send a segment using the wrong brand’s customers.

5. Which decisions can’t be undone?

Campaign assignments are fixed, and a deactivated Business Unit can’t be reactivated. Map brands to data spaces on paper before creating anything. 

6. Who signs off on separation versus unification?

Legal may need a documented requirement, not a preference. Get agreement from legal, marketing, data and brand leadership before choosing the architecture.

What happens if you get this wrong early?

You will inherit a structure that can be very costly to modify. Business Unit mappings and campaign assignments can’t simply be changed after creation, and deactivation is permanent. Identity rulesets and consent records sit on top of those architectural choices. Decisions made during setup can shape how teams manage customer identity and cross-brand campaigns for years.

Treat Business Units as the last step of an identity and governance decision, not the first step of a build.

If you’re deciding how to structure a multi-brand retail group in Marketing Cloud Next, Mavlers’ Salesforce Marketing Cloud specialists can help you. Get in touch with us.