Scaling Audience Management Across Business Units

‍

A segmentation process that works for one brand rarely survives contact with five.

The query logic is usually fine. What breaks is everything around it: where the data lives, who is allowed to read it, and which account the query is actually running in.

‍

Salesforce Marketing Cloud handles multi-brand and multi-region setups with business units, a hierarchical structure available in Enterprise and Enterprise 2.0 accounts that controls access to information and how it is shared.

That structure is genuinely useful. It keeps brands separate, protects sending reputation, and gives regional teams room to work.

It is also the reason audience management tends to get slower, not faster, as an organisation grows.

‍

This post covers what actually changes when audience work moves from one business unit to many, which SFMC rules bite hardest, and the governance patterns that hold up at scale.

‍

Why business units fragment audience work

‍

Isolation is the default, not the exception

Each business unit carries its own subscribers, its own data extensions, and its own sending configuration.

That isolation is the point. It is what stops the German team from accidentally mailing the Spanish list, and what keeps one brand's complaint rate from dragging down another's.

‍

The side effect is that an audience definition is not portable. It is a local object with local dependencies: a specific data extension name, a specific field, a specific folder path.

Copy the query into a sibling unit and it fails, usually with an error that points at the symptom rather than the cause.

‍

The same question gets asked five times

Take a normal request: customers who purchased in the last 90 days and have not opened an email in 60.

That is one business question. Across five business units it becomes five queries, each referencing differently named data extensions, each maintained by whoever happened to build it.

‍

When the definition of "active customer" changes, all five have to change with it. In practice, three of them do.

Nobody planned this. It is the natural result of capable teams solving the same problem independently, with no shared vocabulary between them.

‍

What shared data extensions actually share

‍

The mechanics

Marketing Cloud lets you share data extensions with other business units by placing them in shared data extension folders in the parent account.

Sharing is not limited to data. Emails, templates, portfolio assets, and content areas can all be placed in shared folders and accessed by users outside the owning business unit, provided they have the right role and permissions.

‍

This is the mechanism most enterprise SFMC architectures are built on, and it works well when it is designed deliberately rather than accumulated by accident.

‍

Permissions are more granular than most teams use

In Enterprise 2.0 accounts, Data Extension Permissions controls which business units can reach a shared data extension in Email Studio, and which actions each unit is allowed to perform on it.

You can allow or deny individual actions per business unit rather than granting blanket access.

‍

You can also set a Start Sharing and an End Sharing date. That is genuinely useful for campaign-specific datasets, seasonal audiences, or a dataset shared with an agency for a fixed window.

Very few teams use it. Most configure sharing once during implementation and never revisit it.

‍

A shared folder with permissive defaults, three years in, becomes a folder nobody fully understands and nobody wants to be the one to clean up.

‍

The SQL rules that change across business units

‍

Only SELECT, only your account or the parent

A SQL Query Activity in Automation Studio can run SELECT statements only, and only against data extensions or data views in the current account or its parent account.

There is no sideways access. A child business unit cannot read a sibling unit's data directly, no matter how the query is written.

‍

This single constraint determines a lot of architecture. Any dataset that needs to be readable across the org has to be promoted upward into the parent account and shared down, not passed between peers.

‍

The ent. prefix

To query a data extension that lives in the parent account's shared folder, you prefix its name with ent. inside the query.

It is a small detail that consumes a surprising amount of debugging time. A query that runs perfectly in the parent account fails in a child unit purely because the prefix was never added, and the resulting error rarely says so plainly.

‍

It also creates an onboarding cost. Every new person who writes SQL in a multi-unit org has to learn which objects are local, which are inherited, and how to tell the difference by looking at the name.

‍

Where data views stop helping

‍

The six month wall

Engagement data views such as _Sent and _Open generally hold only the previous six months of activity.

Salesforce updated its retention policy in June 2025 so that subscriber and journey engagement data is retained and accessible for 730 days, but that change did not extend the six month window most data views expose.

‍

If your reactivation logic looks back twelve or eighteen months, the data view alone will not answer the question. You need a rolling snapshot data extension that captures engagement before it ages out.

Building that snapshot once per business unit is manageable. Building and monitoring it in fifteen is a small internal product.

‍

Scope, timeouts, and nightly capacity

Query activities time out at 30 minutes, and SELECT * across a large data extension is a reliable way to reach that limit.

Salesforce's own guidance is direct: narrow the scope as much as possible, split queries that return large volumes, and keep lookbacks to roughly the previous six months.

‍

At single-brand scale that reads as a performance tip. Across fifteen business units running overlapping nightly automations, it becomes a capacity constraint that shapes when campaigns can be built at all.

‍

Three habits reduce the pressure noticeably:

• Name every column you need instead of selecting everything
• Filter on dates before joining, not after
• Stagger automation schedules so units do not compete for the same window

‍

Governance patterns that hold up

‍

Centralise the data, distribute the queries

The pattern that scales best is a thin shared layer. Canonical customer, product, and consent data sits in the parent account, and each business unit builds its own audiences on top of it.

Local teams keep full autonomy over segmentation logic, which is the part they actually need to own. They stop owning the plumbing, which is the part that breaks.

‍

The alternative, where every unit maintains its own copy of customer data, feels faster in month one and becomes unmaintainable by month twelve.

‍

Name things so a stranger can read them

Naming conventions sound like a trivial concern until someone in another region has to work out whether DE_Cust_Act_v2 is still maintained, and by whom.

A workable minimum for shared objects:

• A prefix identifying the owning business unit or the shared layer
• A term describing what the object contains, not how it was built
• A suffix for refresh cadence: daily, weekly, or static

‍

The test is simple. Someone joining next month should be able to read the name and know whether they can trust the contents.

‍

Review sharing on a schedule

Shared folders accumulate quietly. Put a quarterly review in the calendar, list every shared data extension, and remove anything without a named owner or a current use.

Where sharing is genuinely temporary, use the End Sharing date instead of relying on someone remembering.

‍

What this changes day to day

‍

The real bottleneck in a multi-brand org is rarely SQL skill. It is translation: converting one business question into the correct query for each business unit's schema, permissions, and prefixes.

That work is repetitive and mechanical. It is also where most of the delay lives.

‍

When a marketer can describe an audience in plain language, such as "buyers from the last quarter who have not opened anything in 60 days", and get a query that already accounts for the local schema and the ent. prefix, the five-queries problem stops consuming five people's afternoons.

‍

See QAiry in action

‍

QAiry generates production-ready SFMC SQL from a plain language description, and it reads the structure of the business unit it is working in rather than assuming a generic schema.

You can see how it handles multi-unit setups at qairy.com/product-demos, or try it against your own org at qairy.com/try-it-free.