Understanding Role‑Based Security and Business Units in Microsoft Dataverse

Dataverse’s key feature is its rich security model, which only becomes active when a Dataverse database exists in the environment. Administrators typically manage users, ensure correct configurations, and resolve security‑related access issues.

Tip Watch the video "Microsoft Dataverse – Security Concepts Shown In Demos".

Role‑Based Security

Dataverse groups privileges into security roles. Roles can be assigned directly to users or to Dataverse teams and business units. Users inherit the role through team membership. All privileges are cumulative, so granting broad organization‑level read access to contacts prevents hiding individual records.

Business Units

Tip Watch the video "Modernize business units".

Business units use security roles to determine effective security. Each unit defines a security boundary; every Dataverse database has a root business unit. Sub‑business units can be created to further segment users and data. Every user belongs to one business unit, which determines which unit owns the records they create.

Example: a root unit "Woodgrove" with two child units A and B. Users are assigned to one of these units, and security roles can be customized to allow users to view all records within their unit.

Hierarchical Data Access Structure

Customers can organize data and users in a tree‑like hierarchy. When a user creates a record, the associated business unit becomes the owner of that record, and security roles can be tailored to allow the user to view records within that unit.

Illustration:

Matrix Data Access Structure Example

In a matrix structure, data is still hierarchical, but users can work with and access data from any business unit regardless of their own assignment.

When a user needs access to multiple units, the corresponding security roles from each unit are assigned, and the user can set the owning business unit for newly created records.

Enabling Matrix Data Access Structure

Note Before enabling this feature, publish all customizations so that new unpublished tables become available. If unpublished tables cause issues, use the OrgDBOrgSettings tool in Microsoft Dynamics CRM to set RecomputeOwnershipAcrossBusinessUnits to true.

Log in to the Power Platform admin center as an admin (Dynamics 365 admin, global admin, or Power Platform admin).

Select "Environments" and choose the target environment.

Navigate to Settings → Product → Features.

Turn on the "Cross‑business‑unit record ownership" switch.

After enabling the switch, you can assign the "Business Unit" option when assigning security roles to users, allowing a user to own records in any business unit as long as they have read permission on the record table.

Associating Business Units with Microsoft Entra Security Groups

You can map business units to Microsoft Entra security groups to simplify user management and role assignment.

Create a Microsoft Entra security group for each business unit, assign the corresponding Dataverse team security role to each group, and add users to the appropriate groups. This enables users to access resources across multiple business units when needed.

Owning Business Unit

Each record has an "Owning Business Unit" column that determines which unit owns the record. By default, this column is set to the creator’s business unit unless the feature switch is enabled.

Note When changing the owning business unit, ensure cascade settings are correctly configured, especially when using the SDK/.NET.

To allow users to set this column, grant them the "Append To" privilege on the Business Unit table at the local level and enable the column on forms, views, or column mappings.

Table/Record Ownership

Dataverse supports two ownership types: organization‑owned and user/team‑owned. The choice is made when creating a table and cannot be changed later. Organization‑owned records have a single access level (user can or cannot perform an action). User/team‑owned records support hierarchical access levels (organization, business unit, parent‑child business unit, or user‑only).

Example: User A in Business Unit A has Business Unit‑level read access to contacts #1 and #2 but not #3.

The security role editor shows standard privilege types (Create, Read, Write, Delete, Append, Append To, Assign, Share) for each table, each with a visual key indicating the granted access level.

Modernized Business Unit Record Ownership

In the modernized model, a user can own records in any business unit as long as they have a security role with read permission on the record table, without needing a role in each owning unit.

To enable cross‑business‑unit record ownership in production, install the Organization Settings Editor and set RecomputeOwnershipAcrossBusinessUnits to true, then set AlwaysMoveRecordToOwnerBusinessUnit to false.

Note If the feature is disabled or the setting is false, the "Owning Business Unit" field cannot be set or updated, and records with mismatched owning units will be reassigned to the owner’s unit.

Teams (Including Owner Teams)

Teams are another security building block and belong to a business unit. Each unit has a default team automatically created and managed by Dataverse. Owner teams can own records, granting all members access to those records. Access teams are discussed in the record‑sharing section.

Record Sharing

Individual records can be shared with another user or team, providing a flexible but less performant way to grant access outside of ownership or team membership. Sharing can be done at user or team level; access teams offer higher performance because they do not own records or have security roles.

Record‑Level Security in Dataverse

Access to a record is the cumulative result of a user’s security roles, business unit, team memberships, and any shared records. All these permissions are evaluated within the scope of a single Dataverse database.

Column‑Level Security

When record‑level security is insufficient, column‑level security can be enabled for custom and most system columns, including PII. A column security profile defines which columns are secured and the access (Create, Update, Read) granted. Profiles are associated with users or teams, and users must already have record access to benefit from column‑level permissions.

Managing Security Across Multiple Environments

Security roles and column security profiles can be packaged in a Dataverse solution and moved between environments. Business units and teams must be recreated in each target environment, and users must be assigned accordingly.

Configuring User Environment Security

After creating roles, teams, and business units, assign users to a business unit (default is the root unit) and add them to the unit’s default team. Assign any required security roles directly or via team membership. If column‑level security is used, associate the user or team with the appropriate column security profile.

Security is complex and should be designed collaboratively by application architects and permission‑management teams, with thorough testing before deployment.

See Also

Configure environment security

Security roles and privileges

Dataverse and D365 are excellent resources for learning software architecture design.