The Business Unit structure is the SFMC decision teams most often make casually and most often regret, because it is one of the hardest things to change once the account is in use. Reorganising Business Units after data, assets, users, and sending reputation are spread across them is painful in a way that reorganising folders never is, so the hierarchy deserves real thought at the start. And the mistakes go both ways. Some teams split into Business Units they did not need and spend years paying the overhead. Others try to run separate brands or regions out of one Business Unit using folders and filters, and discover too late that those tools cannot actually keep the data and access apart. Getting this right is mostly about understanding what a Business Unit is for and being honest about whether the organisation needs that.
The model to design within is Enterprise 2.0: a top-level enterprise account with child Business Units beneath it. The enterprise account gives you central oversight, and each Business Unit is a unit of isolation. The whole decision comes down to how many units of isolation the organisation genuinely requires.
What a Business Unit actually isolates
A Business Unit isolates four things: data, assets, permissions, and sending identity. Contacts and data extensions, content and journeys, who can see and do what, and the sender profiles and reputation a BU sends under, all of these can be kept separate per Business Unit. That isolation is the entire reason BUs exist, and it is the thing nothing else in the platform provides.
This is the point teams miss when they try to avoid creating Business Units: folders, filters, and lists organise but do not isolate. A folder structure keeps content tidy, a filter narrows an audience, a list groups subscribers, but none of them enforces access control or true data separation. A user with access to the BU can, in general, get to what is in it; folders do not wall off one team's data from another's, and filters are a query convenience, not a security boundary. So the moment a requirement is genuinely about separation, one brand must not see another's data, one region's contacts must be governed apart, one department's campaigns must be isolated, that is a Business Unit requirement, and trying to meet it with folders is building a wall out of labels. Recognising that distinction is most of getting the architecture right.
When to split into multiple Business Units
Separate Business Units are justified by genuine isolation needs, and there are a few that come up repeatedly. Distinct brands that operate independently are the clearest case: if each brand has its own team, its own assets, and its own sending identity, each brand belongs in its own BU so they can run without colliding. Regions with data-governance or legal separation are another: when regulation requires that a region's customer data be governed and access-controlled separately, often the case for GDPR-style requirements, regional Business Units provide the isolation that folders and filters cannot. And subsidiaries or departments that must not see each other's data, for internal-control or confidentiality reasons, are the same pattern: real separation requires real Business Units.
For global organisations, the common and effective pattern is a shared global Business Unit plus local ones. The global BU holds brand-standard assets and templates that everyone should use, while country or regional BUs run local campaigns with their own data and permissions. That gives you global consistency and local autonomy at once, which a single BU cannot do and fully separate accounts would make harder to govern centrally. When a client wants both brand control from the centre and freedom for local teams, this is usually the answer.
When to stay in one Business Unit
The opposite mistake, over-splitting, is just as costly and easier to fall into because more BUs can feel more organised. Every Business Unit you add is administrative overhead: users and permissions to manage per BU, sending reputation to maintain per BU, and friction on the things that are easier within a single unit, like reusing content and reporting across the whole program. Split without a real isolation need and you have bought all that overhead for nothing.
So a single team working on one brand belongs in one Business Unit, organised with folders, not fragmented into BUs it does not need. And a small organisation that might grow later is usually best starting with a single Business Unit under an enterprise account: simple to run today, and positioned to add BUs when a genuine isolation need actually appears, rather than guessing at a complex structure up front. The enterprise account is the part that keeps that future option open; you do not need the child BUs until you need them.
Making the call
The decision is one honest question asked per axis of the organisation: is there a genuine need to isolate data, assets, permissions, or sending identity between these groups? If yes, between brands, between regions, between subsidiaries, that axis becomes Business Units, with a shared global BU added when central brand control and local autonomy both matter. If the need is only to keep things organised, that is folders within one BU, not new Business Units. And when in doubt for a smaller or growing organisation, start with one BU under an enterprise account and split later, because adding a Business Unit when a real need arises is far easier than untangling Business Units you created on speculation.
The structure is hard to change once it is live, so the goal is to match it to the isolation the organisation genuinely requires, no more and no less. Folders for organisation, Business Units for isolation, and the enterprise account holding it all together.
Designing or restructuring an SFMC account hierarchy? Our Salesforce team plans Business Unit and Enterprise 2.0 structures for multi-brand and multi-region programs on production engagements. Get in touch ->
See our full platform services for the stack we cover.
