3.1 Business Units, Ownership Models & Modern BU Matrix
Key Takeaways
- The Root Business Unit is automatically created upon Dataverse environment provisioning, takes the environment's name, cannot be deleted or re-parented, and sits at the pinnacle of the structural hierarchy.
- Child Business Units represent organizational divisions, subsidiaries, or geographical branches and can be nested, renamed, disabled, and re-parented to reflect corporate reorganizations.
- Classic Dataverse security restricts user data ownership strictly to their assigned Home Business Unit, requiring records to reside in that same BU and enforcing strict vertical boundaries.
- Modern Business Units (Record Ownership across BUs / Matrix Data Access) decouple user membership from record ownership, allowing users to own records in external BUs and hold security roles from different BUs simultaneously.
- Moving a user to a different Business Unit in Classic security automatically strips all directly assigned security roles from the previous BU, whereas re-parenting a Child BU moves all child branches, users, and teams while preserving inherited role mappings.
3.1 Business Units, Ownership Models & Modern BU Matrix
In Microsoft Dataverse, security is not merely an authentication boundary; it is an enterprise authorization engine designed to mirror complex organizational structures, regulatory silos, and cross-functional collaborative workflows. At the foundational tier of this security architecture sits the Business Unit (BU).
Understanding how Business Units structure data boundaries, how table ownership dictates security options, and how the Modern Business Unit (Matrix Data Access) paradigm transforms legacy security constraints is critical for any Power Platform Functional Consultant preparing for the PL-200 certification.
1. Foundations of Dataverse Business Units
A Business Unit is a logical container that partitions users, teams, security roles, and data records. Every Dataverse environment contains a formal tree structure of Business Units that establishes the security perimeter for record-level authorization.
+-----------------------------------------------------------------------------------+
| DATAVERSE BUSINESS UNIT HIERARCHY TREE |
| |
| +---------------------------+ |
| | ROOT BUSINESS UNIT | |
| | (Created with Environment)| |
| | (Cannot be Deleted/Moved) | |
| +---------------------------+ |
| | |
| +-------------------+-------------------+ |
| | | |
| v v |
| +---------------------------+ +---------------------------+ |
| | Child BU: North America | | Child BU: Europe | |
| +---------------------------+ +---------------------------+ |
| | | |
| +---------+---------+ v |
| | | +---------------------------+ |
| v v | Child BU: UK & Nordics | |
| +-----------+ +-----------+ +---------------------------+ |
| | BU: US East| |BU: US West| |
| +-----------+ +-----------+ |
+-----------------------------------------------------------------------------------+
The Root Business Unit
- Automatic Lifecycle: When a new Dataverse environment is created, the system automatically instantiates exactly one Root Business Unit.
- Immutable Identity: The Root BU is permanently bound to the environment. It cannot be deleted, cannot be disabled, and cannot be re-parented under any other business unit.
- Naming Conventions: By default, the Root BU inherits the name of the Dataverse environment, but administrators can rename it if necessary.
- Root Security Roles: All standard out-of-the-box (OOB) security roles reside at the Root BU level and automatically propagate down to all child business units as inherited roles.
Child Business Units
- Hierarchical Nesting: Administrators can create multiple levels of Child Business Units beneath the Root BU or beneath other Child BUs to model subsidiaries, operational departments, or regional branches.
- Parent-Child Linkages: Every child BU must have exactly one immediate parent BU. Modifying this relationship is known as re-parenting.
- Disabling Business Units: A child BU can be disabled. Disabling a BU immediately revokes application access for all users assigned to that BU and prevents any user from creating or modifying records within that BU's scope. All descendant child BUs under the disabled unit are also automatically disabled.
- Deletion Constraints: A child BU can only be deleted if it is first disabled, contains zero active users, contains zero active teams, has zero child BUs beneath it, and all its records have been reassigned.
2. Record Ownership & Dataverse Table Ownership Types
Before configuring business unit boundaries, a functional consultant must recognize how table-level architecture controls security behavior. When a custom table is defined in Dataverse, the creator must specify its Ownership Type, which is permanently fixed upon table creation and cannot be changed later.
| Table Ownership Type | Owner Field Present | Security Role Scope Options | Typical Business Use Cases |
|---|---|---|---|
| User or Team Owned | Yes (ownerid lookup to systemuser or team) | Basic (User), Local (BU), Deep (Parent-Child BU), Global (Organization), None | Accounts, Contacts, Leads, Opportunities, Work Orders, Custom Invoices |
| Organization Owned | No (organizationid lookup to the environment) | Global (Organization) or None | Product Catalogs, Currency Exchange Rates, Postal Codes, Tax Tables |
| None | No (System-managed only) | System Internal Only | Internal metadata tables, background tracking records |
[!IMPORTANT] If a table is configured as Organization-owned, Dataverse provides only two privilege levels in Security Roles: None or Organization (Global). You cannot restrict access to Organization-owned tables by User, Business Unit, or Parent-Child hierarchy. Always select User or Team ownership when designing custom tables that require granular departmental or individual access restrictions.
3. Classic Security Model vs. Modern Business Unit Matrix
For nearly two decades, Dataverse (and legacy Dynamics CRM) enforced a rigid, one-to-one relationship between users, business units, and record ownership. In modern enterprise environments, Microsoft introduced Matrix Data Access (also known as Record Ownership Across Business Units).
+-----------------------------------------------------------------------------------+
| CLASSIC VS MODERN BUSINESS UNIT COMPARISON |
| |
| CLASSIC BU SECURITY MODEL (Rigid Silos) |
| +--------------------------+ +--------------------------+ |
| | Business Unit A | | Business Unit B | |
| | +--------------------+ | | +--------------------+ | |
| | | User: Sarah | | | | Records Owned by B | | |
| | | Home BU: BU-A | | | +--------------------+ | |
| | | Security Role: BU-A| | | | |
| | | Can ONLY own BU-A | | | Sarah CANNOT own records| |
| | | records | | | in BU-B without moving! | |
| | +--------------------+ | | | |
| +--------------------------+ +--------------------------+ |
| |
| MODERN BU MATRIX MODEL (Matrix Data Access / Record Ownership Across BUs) |
| +--------------------------+ +--------------------------+ |
| | Business Unit A | | Business Unit B | |
| | +--------------------+ | | +--------------------+ | |
| | | User: Sarah | | | | Records Owned by | | |
| | | Home BU: BU-A | | | | Sarah in BU-B! | | |
| | +--------------------+ | | +--------------------+ | |
| | | | | ^ | |
| | | | | | | |
| | +-------------+---------+------------+ | |
| | Sarah is assigned a Security Role directly from BU-B!| |
| +---------------------------------------------------------------+ |
+-----------------------------------------------------------------------------------+
Classic Business Unit Security Mechanics
- Strict Home BU Binding: A user is assigned to exactly one Home BU. The user can only be assigned security roles that belong directly to their Home BU.
- Ownership Lock: A user can only create and own records that reside in their own Home BU. If Sarah belongs to the "North America" BU, any Account record Sarah creates or owns is permanently cataloged under the "North America" BU.
- Cross-BU Collaboration Friction: If Sarah temporarily works on a European project, the European team must either grant Organization-wide read/write permissions (violating least privilege) or manually share individual records with Sarah via the
PrincipalObjectAccess(POA) table, causing severe performance degradation.
Modern Business Unit Security (Matrix Data Access)
- Decoupled Security Role Assignment: When the "Record ownership across business units" feature is enabled in Power Platform Admin Center, a user's security roles are no longer confined to their Home BU. A user whose Home BU is "North America" can be assigned security roles belonging to "Europe", "Asia-Pacific", or any other Child BU.
- Cross-BU Record Ownership: Users can create and own records residing in external Business Units without changing their primary Home BU membership.
- Owning Business Unit Field (
owningbusinessunit): In modern BU security, the record's owning business unit does not have to match the record owner's Home BU. If Sarah is assigned a Sales Manager role in "Europe", she can own an Opportunity record whoseowningbusinessunitis set directly to "Europe".
Feature Comparison: Classic vs. Modern Matrix BU
| Architectural Capability | Classic BU Model | Modern Matrix BU Model |
|---|---|---|
| User Home BU Assignment | Mandatory (1 Home BU per user) | Mandatory (1 Home BU per user) |
| Security Role Assignment Source | Exclusively from user's Home BU | Any BU in the environment hierarchy |
Record Owning BU (owningbusinessunit) | Strictly equals Owner's Home BU | Can differ from Owner's Home BU |
| Cross-BU Project Support | Requires manual sharing or broad Global roles | Assign localized Security Role from Target BU |
| Admin Overhead for Matrix Workers | High (constant sharing & reassignment) | Low (role assignment in target BU) |
| Activation Method | Default legacy setting | Enabled via Power Platform Admin Center Settings |
4. Structural Reorganizations: Moving Users & Re-Parenting Business Units
Corporate restructuring, mergers, acquisitions, and employee transfers frequently require modifications to Dataverse business unit hierarchies. Functional consultants must understand the downstream authorization impacts of these administrative operations.
+-----------------------------------------------------------------------------------+
| RE-PARENTING A BUSINESS UNIT |
| |
| BEFORE RE-PARENTING: AFTER RE-PARENTING: |
| [Root BU] [Root BU] |
| / \ / \ |
| [BU-East] [BU-West] [BU-East] [BU-West] |
| | | | |
| [Branch-A] (Sub-unit of East) | [Branch-A] (Moved to West!)|
| | | |
| +-----------+ |
| * Branch-A and all its users/teams move under BU-West. |
| * Inherited roles from BU-East are replaced by inherited roles from BU-West. |
| * Deep (Parent-Child) privileges of BU-West now encompass Branch-A records! |
+-----------------------------------------------------------------------------------+
Moving a User Between Business Units
When an administrator changes a user's Home BU:
- Security Role Stripping (Classic Mode): In classic mode, all security roles previously assigned to the user are completely removed. The administrator must immediately assign new security roles belonging to the destination BU before the user can access Dataverse again.
- Modern Matrix Mode Behavior: If modern BU matrix security is active, roles assigned directly from other business units can be retained, but inherited roles derived from the former Home BU are revoked.
- Record Ownership Retention: Records previously owned by the user do not automatically move to the new BU unless explicitly updated. In classic mode, this can create orphaned data relationships where a user owns records in a BU to which they no longer belong, potentially hiding those records from the user's own views if their new role depth is only Basic/User.
Re-Parenting a Child Business Unit
When a Child BU's parent is changed (e.g., shifting "Branch-A" from "BU-East" to "BU-West"):
- Sub-tree Cascade: The target BU and all its descendant child BUs, users, and teams move as a unified sub-tree under the new parent BU.
- Inherited Role Re-binding: Any security roles inherited from the old parent BU are detached and replaced with inherited security roles from the new parent BU.
- Parent-Child (Deep) Privilege Realignment: Managers in the old parent BU immediately lose access to Branch-A records if their security roles rely on Deep (Parent-Child BU) depth. Managers in the new parent BU immediately gain access to Branch-A records under their Deep privilege scope.
[!TIP] Always plan user transitions and BU re-parenting during scheduled maintenance windows. In large enterprise environments with millions of records, changing a BU parent triggers asynchronous background recalculations of inherited access rights and role cascading.
A multinational enterprise uses Dataverse with a Root Business Unit and multiple regional Child Business Units. A sales representative whose Home Business Unit is 'North America' needs to be assigned ownership of several new customer accounts located in the 'Europe' Business Unit without changing their primary department membership. How should the functional consultant configure the system?
An administrator needs to move a regional sales manager from the 'Midwest BU' to the 'West Coast BU' in an environment operating under Classic Business Unit security rules. What is the immediate consequence of changing the user's Business Unit field?
A system customizer is designing a new custom table to store national postal codes and standard tax rates. Every user in the organization requires read access to this reference data, and departmental partitioning is strictly forbidden. Which Table Ownership type must be selected during table creation?
During a corporate restructuring, an organization re-parents 'Division East BU' (which has 3 child branches and 50 users) from 'Regional Hub A' to 'Regional Hub B'. What happens to the security and structural hierarchy of 'Division East BU'?