Business units

What it does

A business unit is a security boundary. Every Dataverse database has one root business unit, and you add child units below it in a single-parent tree. Every user belongs to exactly one, and that membership determines which business unit owns the rows they create.

Key facts

The root business unit is created with the environment and can't be deleted. Its name derives from the domain name used at provisioning and can only be changed through the Web API, not the business unit form.
Each business unit has one parent and can have many children. Users can't be added to a business unit directly — new users land in the root and you move them.
Security roles belong to a business unit too. A user can hold roles from any business unit regardless of where the user sits.
Every business unit gets a default team, automatically managed. You can't rename it, delete it, or add and remove members — membership follows the users in that business unit. Plug-ins and workflows can't intercept those membership changes.
You can assign a security role to a default team, which is a tidy way to give everyone in a business unit the same baseline access.
A team belongs to one business unit but can contain users from several.
Changing a user's business unit can remove all their security role assignments. They need at least one role in the new business unit afterwards.
Two environment database settings modify that behaviour once record ownership across business units is enabled: DoNotRemoveRolesOnChangeBusinessUnit (default false — roles are removed) and AlwaysMoveRecordToOwnerBusinessUnit (default true — user-owned rows move with the user).
Reassign business unit records moves all relevant rows from a source business unit to a target. It's sequential: if one table fails, nothing after it transfers until you fix the error.

When to use / skip

Create business units when you genuinely need users in one part of the organisation not to see data owned by another, and when that boundary is stable. Don't mirror the org chart. Every additional business unit multiplies the roles, the teams and the maintenance, and org charts get redrawn every eighteen months while your security model doesn't. Microsoft's own guidance is blunt about this: prefer fewer business units plus hierarchy security over a large tree. Start with the root only and add units when a specific access requirement forces you, not in anticipation.

Configuration decisions

Whether you need child business units at all, or whether teams and hierarchy security cover the requirement.
How deep the tree goes, given Parent: Child access levels reach every descendant and depth is what makes that dangerous.
Whether to map each business unit to an Entra security group with a group team, which is the cleanest way to automate user-to-business-unit assignment.
Whether to enable record ownership across business units, which changes the shape of the whole model.
What happens to a user's rows when they move: follow the user, or stay put.

Gotchas

Moving a user between business units strips their role assignments by default. Do it in bulk without planning and you've locked out a department.
Rows move with the user by default too, which means reorganising staff quietly reassigns ownership of their data to a different security boundary.
The default team is invisible in a lot of troubleshooting. A role assigned to a default team grants access to everyone in the business unit, and it doesn't show up when you look at the user's directly assigned roles.
Roles are business-unit scoped, so importing roles into an environment with a different business unit structure gives you roles pointing at the wrong place. Names look identical.
Reassigning business unit records is all-or-nothing and sequential. A failure partway through leaves you in a half-migrated state.
The root business unit's name is stuck with whatever the domain was at provisioning, which is often not the client's actual name.

Consultant notes

Push back hard on business unit proliferation. Ask what specific data one group must not see, and whether hierarchy security or teams solve it. Most requests dissolve under that question.
Map business units to Entra security groups from day one. Manual business unit assignment doesn't survive contact with a real HR process.
Warn the client that a reorganisation is a security project, not an admin task. Moving people between business units touches roles, ownership and every row they've created.
Document which roles belong to which business unit. It's the detail that makes solution deployment between environments go wrong in ways that take a day to diagnose.

Revisit if the modernised business unit model changes the guidance on tree depth, or if root business unit renaming reaches the UI.