Every Dataverse environment has at least one business unit (the root BU, usually named after the organization) and can have more arranged in a strict hierarchy — a BU can have child BUs, forming a tree. Every user and every user/team-owned record belongs to exactly one business unit.

Why business units exist

Business units are the structural backbone that security roles reference when granting “Business Unit” level access. If your organization has genuinely separate divisions that shouldn’t normally see each other’s records (e.g. separate regional sales teams, or separate legal entities under one tenant), modeling them as business units lets you grant access scoped to “my BU and below” rather than having to list specific users or teams everywhere.

When not to over-model this

A common mistake is creating a complex BU tree that mirrors the full org chart (every department, every team) just because the org chart exists. BUs are a security boundary, not a reporting structure — if two teams should see each other’s data most of the time with only occasional restrictions, BUs are usually the wrong tool; a single BU plus well-designed security roles and teams is simpler and easier to maintain.

BUs are hard to reorganize later. Moving a user or team between business units, or restructuring the BU hierarchy, can have wide-reaching effects on record visibility and is disruptive once there’s real data and real users in the system. Get the structure right — or deliberately minimal — before go-live rather than treating it as something to easily adjust afterward.

Record ownership and business units

A user/team-owned record is implicitly associated with its owner’s business unit. This is exactly what “Business Unit” level security role access checks against: “can this user see records owned by anyone in their own business unit” (or, with “Parent: Child Business Units,” anyone in their BU or any BU beneath it).