Business units and teams in Dataverse — a deep dive

Dataverse security has several composable elements: business units define organisational hierarchy, teams group users for shared ownership and access, security roles define what privileges, and records can be owned by users or teams. Getting the composition right is the foundation of a maintainable security model — and the wrong composition is the root cause of permission tangles years later.

Business units (BUs). A hierarchical structure rooted at one root BU (the organisation itself). Child BUs nest beneath; can be many levels deep. Every user belongs to exactly one BU.

Business units are primarily about scope in security roles. Many privilege levels (Read, Write, etc.) come with a depth:

• None — no access.
• User — only own records.
• Business Unit — records owned by users in the same BU.
• Parent: Child Business Units — own BU + child BUs.
• Organization — all records.

So Read Account (BU) lets the user see all accounts owned by anyone in the same BU as them.

Designing BU hierarchy. Three patterns:

• Geographic — by region (Americas, EMEA, APAC) and sub-region.
• Functional — by division (Sales, Service, Operations).
• Mixed — a hybrid based on the security model needs.

The hierarchy is rigid. Moving users between BUs is operationally heavy. Design conservatively; over-fine-grained BU hierarchies become unmaintainable.

Teams. A team is a named group of users. Three types:

• Owner team — can own records. Users in the team see records owned by the team if they have appropriate privileges.
• Access team — can't own records; instead grants ad-hoc access to specific records via access team templates.
• Microsoft 365 group team — auto-synced with an M365 group's membership.

Each type has its place.

Owner teams. Used when a record belongs to a group, not an individual:

• Cases owned by a Support Team rather than a specific agent.
• Accounts owned by the regional sales team.
• Projects owned by a project team.

Owner teams have a BU and a security role (or set). Team-owned records inherit access from the team's privileges plus individual users' privileges.

Access teams. Used for ad-hoc record sharing without creating a full team:

• A deal that requires a cross-functional subteam.
• Sensitive cases shared with a specific group of people.

The pattern:

1. Define an access team template for the table (e.g., "Account Project Team").
2. The template specifies what permissions members get (Read, Write, Append, etc.).
3. On a specific record, add users to the access team.
4. Users get the configured permissions on that record only.

Access teams scale better than manual sharing because the membership is tracked per-record. No team explosion.

Microsoft 365 group teams. Sync membership from an M365 group:

• Add a user to the M365 group → added to the team in Dataverse automatically.
• Remove from M365 → removed from Dataverse team.

Useful for departmental teams whose membership is already managed in M365 directory. Single source of truth for membership.

Security roles on teams. Teams can be assigned security roles. Permission a user has = max(roles they personally have) ∪ max(roles their teams have).

This is the most common design pattern: most users don't have roles directly; they inherit roles via teams.

• Easier to manage at scale.
• New users added to a team get the right permissions automatically.
• Permission changes happen at the role level, propagating to all team members.

The composition.

• User belongs to a BU.
• User belongs to zero or more teams.
• User has zero or more security roles.
• Teams have zero or more security roles.
• Records have an owner (user or owner team) and an owning BU.
• Security check: does the user (directly or via teams) have a role granting the needed privilege at sufficient depth on the record's BU?

Hierarchical security. A separate model layered on top — manager-relationship-based access. Used less commonly; useful for "managers see their direct reports' records" patterns.

Position-based access — another less-used layer where positions in a chart automatically grant access. Often more trouble than it's worth.

Common design mistakes.

• Too many BUs. Hundreds of BUs for a small organisation; users in wrong BUs constantly; data invisible across BUs that should share.
• BU as a tag. Using BU to categorise customers (commercial vs enterprise) instead of for security scoping. Use a Choice column for categorisation.
• Individual role assignments. Every user has individual roles; rolling out a new permission means editing every user. Use teams instead.
• Owner teams used for sharing. Putting the user in an owner team gives them access to all the team's records — too broad. Use access teams for selective record-level sharing.
• Forgotten team membership cleanup. Departed users still in teams; security review periodically.
• Default Business Unit on user creation. All users default to the root BU; admin forgets to assign; entire organisation has root-level access.

Privilege inheritance. Don't confuse privilege inheritance with record ownership:

• Privilege inheritance: user gets permissions from team's role.
• Record ownership: user or team owns the record; their access depends on privileges.

Operational rule. Design the security model with care upfront. Start simple: a flat BU structure, role-based access via teams, access teams for ad-hoc cross-team sharing. Add complexity only when concrete needs demand it. The most maintainable security models are not the most expressive; they're the cleanest.