Dataverse Security Explained: Business Units, Teams, Roles & Ownership

1. Dataverse Table Ownership (Organization vs User/Team)

Organization-Owned Table:

• Records do NOT have individual owners.
• Only None or Organization permission levels are allowed.
• Used for: Configuration tables, global reference data.

User/Team-Owned Table:

• Records are owned by users OR teams.
• Allows scopes: None, User, Business Unit, Parent:Child BU, Organization.
• Used for: Operational data (Projects, Cases, Accounts).

2. Business Unit vs Team (They Are Not Same)

Business Unit:

• Defines security boundary and data visibility.
• Every user belongs to exactly one BU.
• Cannot own records.

Team:

• A group inside a Business Unit.
• Can own records (Owner Team).
• You can add/remove members.
• Roles assigned to Teams apply only to Team members.

3. Default Business Unit Team (Auto-created Team)

This team is automatically created when a Business Unit is created.

• Has the same name as the Business Unit.
• You cannot add/remove members manually.
• Members appear automatically = All users in that BU.
• Used for BU-wide security inheritance.
• Not meant for record ownership or sharing.

4. Normal Team (Owner Team)

This is the Team you create manually.

• Must select a Business Unit while creating.
• You can add/remove members normally.
• Can own records.
• Can have Security Roles assigned.

Roles assigned here apply ONLY to team members.

5. Why Team Must Be Linked to a Business Unit

• Team's security scope depends on its BU.
• Record ownership uses team's BU.
• Permissions (User/BU/Parent-Child) must be calculated based on BU hierarchy.
• Team roles must match Business Unit security context.

6. Role Assignment: Team vs Business Unit

When you assign a security role to a Team:

• Only Team Members get the permissions.
• Other BU users do NOT get the role.

When you assign a security role to the Business Unit's Default Team:

• ALL users in the Business Unit get the role automatically.
• Default Team acts as a security propagation layer.

7. Assigning a Record to Another Business Unit

1. You cannot assign a record directly to a Business Unit.
2. You must create an Owner Team inside that BU.
3. The Team must have correct security roles: Read + Write + Assign.
4. Record ownership changes to that Team, and BU updates automatically.

8. Assigning Security Roles to a Business Unit (How It Actually Works)

You cannot assign a security role directly to a Business Unit.

Instead, Dataverse creates a hidden mechanism called:

✔ Default Business Unit Team

• This team has the same name as the Business Unit.
• You cannot manually add or remove members from it.
• All users belonging to the Business Unit appear automatically as members.
• When you assign a role to this Default Team → all BU users get the role.

Summary:

• Role assigned to Default BU Team → ALL BU users get the role.
• Role assigned to a custom team → ONLY team members get the role.
• Default team = BU-wide role propagation mechanism.

9. Does Adding a User to a Team in Another Business Unit Give Record Access?

Short Answer: NO - Not automatically.

The user can see records from another BU ONLY IF the team they joined has the required security role permissions.

Team membership ALONE does not grant access.

✔ When the user CAN see the record

• The team they joined has Read permission for that table.
• The team has Write/Assign permission (if needed).
• The team is the owner of that record and the user is a team member.

When the user CANNOT see the record

• The team has no roles or insufficient permissions.
• User is added to the correct team but the table is organization-owned with no team rights.
• The team is an Access Team with no privileges assigned.

✔ Final Rule

Team membership + Team's assigned roles = Final access

A user from any BU can access records in another BU through:

• Team roles (Read/Write/Assign)
• Team-based ownership of the record

Dataverse Security Scenario - Business Unit Mismatch & Read Privilege Failure

🟢 Scenario Setup

• Security Role: "Security"
• Table: User Owned (sun_userowned)
• Team: Test Security (Owner Team)
• Team Business Unit: BU2
• User Business Unit: BU1
• Role Privileges for Table:
• Create = Organization
• Read = Business Unit
• Other permissions = Business Unit
• BU1 doesn't have any permission or security role assigned..
  The user who belong to BU1 also is part of Test Security Team.

🔴 The Issue

The user in BU1 encounters the error:
“Missing prvReadsun_userowned privilege. Read Privilege Check For Owner failed.”

This happens because Read = Business Unit only gives access to records within the same Business Unit. Since the user is in BU1 and the record or team is in BU2, the user cannot read the record. Dataverse does not allow a role to grant privileges for multiple specific BUs.

🔎 Why the Error Occurs

• The user is in BU1.
• The team is in BU2.
• Read privilege is scoped to Business Unit.
• BU-level privileges only apply to the user’s own BU, not other BUs.
• Therefore, the Read privilege check for records in BU2 fails.

🟡 Incorrect Assumption

Assigning the "Security" role to a user in BU1 does not allow them to read records from BU2. Adding Create privilege also does not fix Read privilege issues because Create and Read are independent privileges.

🟢 How to Resolve the Issue

• Option 1 (Recommended): Change Read = Organization for the table in the Security role.
  This allows users to read records across all BUs.
• Option 2: Move the user from BU1 to BU2.
  Now Read = Business Unit works correctly because the user and team/records belong to the same BU.
• Option 3: Ensure records are owned by a BU1 team.
  If record owners are in BU1, BU1 users can read them with BU-level privileges.

Microsoft 365 Group Roles vs Dataverse Team Types

🟢 Microsoft 365 / Microsoft Entra ID Group Roles

When you create a Microsoft 365 Group or Microsoft Teams group, the group contains three types of members:

• Owners – Manage the group, add/remove users, control settings.
• Members – Regular internal users who can collaborate.
• Guests – External users with limited permissions.

When this group is used in Dataverse, all three roles (Owners, Members, Guests) become team members inside the mapped Dataverse Team.

🔵 Dataverse Team Types

Dataverse supports different team types, each behaving differently:

• Owner Team – Can own records and have security roles assigned. Members inherit the team's roles. Team belongs to a Business Unit.
• Access Team – Cannot own records. Only used for sharing specific records. No security roles assigned.
• Azure AD Group Team – Created by mapping a Microsoft 365 or Entra ID Group to Dataverse. Functions like an Owner Team but membership is automatically synced.

🟣 How Microsoft 365 Group Members Map to Dataverse Team Members

• Owner (M365) → Member in Dataverse Team
• Member (M365) → Member in Dataverse Team
• Guest (M365) → Member in Dataverse Team (limited Dataverse access)

Dataverse does not differentiate between Owners, Members, and Guests. All become simply team members in the Dataverse Azure AD Group Team.

🟠 Business Unit and Privilege Behavior (Important)

Azure AD Group Teams behave exactly like Owner Teams:

• Team belongs to a Business Unit (BU).
• The security roles assigned to the team determine what members can do.
• If the team has Read = Business Unit, members can access records:
  • Owned by the team, and
  • Inside that team's Business Unit

🟡 Example

Team: Test Security (Azure AD Group Team, Owner Type) – BU2
User: Belongs to BU1
Record Owner: BU2 Owner Team
Privileges: Read = Business Unit

• BU1 user is added as Member to Microsoft 365 Group.
• Group is mapped as an Azure AD Group Team in Dataverse.
• Dataverse treats them as a team member of the BU2 team.
• User inherits BU2 team's security roles.

Result: BU1 user can access BU2 team-owned records.

Limitation: BU1 user cannot access BU2 user-owned records unless Read privilege is at Organization level.