The modern equivalent of a business unit is an environment. Building one app for several customers? Give each customer its own environment. Stick to one business unit per environment, and add child business units only when people inside the same environment genuinely need different access to the same data.
Where business units came from
Business units date from on-premises CRM, when servers were expensive and storage was scarce. A conglomerate could run one CRM server for very different businesses, say a razor brand, a cough syrup and a toothpaste under one parent. Each brand’s staff and records stayed apart, and head office still got common SQL reports. Sharing one database between separate businesses was a sensible efficiency then. It reflects constraints and design decisions from the 100GB HDD era, not a modern set-up.
Training material and old projects still show business units as the way to split an organisation, and customers moving big old systems to the cloud keep the structures they already have.
What an environment gives you that a business unit can’t
Microsoft’s own guidance says you need multiple environments when “segregation is required of data, plugins, workflows, or admin resources that cannot be easily isolated by using business units”. Every business unit in an environment shares:
- One schema and one set of solutions. A customisation, plug-in or flow for one business ships to all of them, and they all test and release together.
- One set of administrators. A System Administrator sees every business unit.
- One region, backup and restore. Restoring the environment rolls back every business’s data, including the ones that broke nothing.
- One update schedule and one set of environment settings.
Separate environments give each business its own copy of all of that. A business that leaves takes its environment with it, instead of being unpicked from a shared database.
Govern environments as a set
- Managed Environments add sharing limits, usage insights, solution checker enforcement and a per-environment view of data policies.
- Environment groups put managed environments in a folder and apply rules to all of them at once.
- Solutions and pipelines move the same app into each environment, so a shared schema doesn’t mean a shared database.
- Reporting across businesses doesn’t need a shared database either. Power BI can read several environments, and Azure Synapse Link for Dataverse copies each one to a data lake.
Each environment with a database needs at least 1 GB of free database capacity to create, so count that in the cost.
What business units are still for
Inside one environment, business units are the security boundary for records. They work with security roles to decide who reads and edits what: regional sales teams who shouldn’t see each other’s pipeline, or a service team that only handles its own cases.
They’re more flexible than they used to be. Turn on “Record ownership across business units” (modernised business units) and a record’s owning business unit no longer has to be its owner’s, and a user can hold security roles from several business units. A regional manager who covers three divisions no longer needs to be moved between them or added to an owner team in each. Teams, sharing and hierarchy security cover most of the rest.