Dataverse: Security (ROLES/BU/Teams)

Introduction to the Dataverse Security Model

Microsoft Dataverse uses a granular and hierarchical security model to control access to data and functionalities. This model is based on business units, security roles, and teams. Each user or team can have one or more roles defining permissions for tables and operations (read, write, create, delete, assign, share, append, append-to).

The security model ensures that sensitive information is only accessible to authorized users. It extends to APIs, guaranteeing that the same rules apply regardless of the access interface.

Business Units: The Hierarchical Foundation of Security

Each Dataverse environment includes at least a root business unit representing the entire organization. Additional business units can be created to reflect corporate structure such as divisions or departments. Users are assigned to a specific unit, which defines their visibility scope and data management capabilities.

The business unit hierarchy enables scenarios such as:

• Restricted access to department-specific data.
• Extended visibility to child units (Parent: Child Business Units).
• Centralized permission management for cross-department teams.

Security Roles and Permission Levels

Security roles define what actions a user can perform in Dataverse. Each role contains a set of permissions for each table and feature. The available access levels are:

1. None Selected: no access granted.
2. User: access limited to owned records.
3. Business Unit: access to records within the same business unit.
4. Parent: Child Business Units: access to own unit and subordinate units.
5. Organization: access to all records within the organization.

Each role grants permissions for specific operations such as:

• Create: create new records.
• Read: view existing records.
• Write: edit existing records.
• Delete: remove records.
• Append and Append To: link records across tables.
• Assign: reassign record ownership.
• Share: share records with other users.

To avoid conflicts, it is recommended to create custom roles instead of modifying system default ones. This approach simplifies maintenance and ensures platform update compatibility.

Teams and Role Assignment

Teams allow flexible data access management. There are several types of teams in Dataverse:

• Business Unit-based Teams: automatically created for each business unit.
• Custom Owner Teams: manually created, can own records and have assigned roles.
• Access Teams: ideal for ad hoc record access without permanent roles.
• AAD Security Group Teams: integrated with Azure AD to automatically assign permissions to users in a group.

Teams enable administrators to quickly assign roles to groups of users, reducing management complexity. Integration with Azure Active Directory allows synchronization of members and privileges in real time.

A key benefit of AAD Security Group teams is the ability to manage user additions and removals directly from Azure AD without manual Dataverse intervention.

Column-Level Security

Dataverse allows protecting individual columns within a table, useful for managing sensitive data such as credit card numbers, passwords, or personal details. Column-level security is configured in three main steps:

1. Enable security for the desired column in the Maker Portal.
2. Create a column security profile and define read, create, and update permissions.
3. Add users or teams as members of the profile.

Users not included in the security profile won’t see or access protected data, even through APIs. Column-level security ensures end-to-end protection.

Sharing and Granular Permissions

Beyond roles, Dataverse allows sharing individual records with other users or teams. Sharing may include specific rights (read, write, delete) and is managed at the record level. This feature is valuable for temporary collaboration scenarios or limited access for external consultants.

Sharing can also be automated through Power Automate flows or plugins, ensuring permissions adapt dynamically to data lifecycle events.