Business Units, Teams, and Ownership: Modeling Dataverse Security Without the Sprawl

Dataverse security looks simple until you try to model a real organization, and then it bites. The trap is treating business units as org-chart boxes — you end up with sixty business units, a maintenance nightmare, and security roles that nobody can reason about. Let's build the mental model correctly, then model a real structure with as few business units as the requirements actually demand.

The pieces and how they fit

Three concepts do the work: business units, security roles, and owners (users or teams). They combine like this:

• Every record that is user-or-team owned has exactly one owner.
• The owner sits in a business unit (a user belongs to one BU; a team belongs to one BU).
• A user's security roles grant privileges, and each privilege has an access level that defines the scope of what that privilege reaches.

The access levels, from narrowest to widest:

• User (Basic) — only records I own or that are shared with me.
• Business Unit (Local) — records owned within my own business unit.
• Parent: Child Business Units (Deep) — my BU plus all BUs beneath it in the hierarchy.
• Organization (Global) — every record, regardless of BU.

So "can user A read this record" is answered by: does A have a Read privilege on that table, and is the record's owner within the scope (User / BU / BU subtree / Org) of that privilege's access level? Ownership places the record in the hierarchy; the access level determines how far a role can see.

The business unit hierarchy

Business units form a single tree with one root BU (created with the environment). Every other BU has a parent. The hierarchy matters for exactly one thing in core security: the Deep access level, which grants reach down into child BUs.

This is the key insight people miss: BUs are a hierarchy for the purpose of cascading access downward. They are not a generic grouping mechanism, not a way to tag records, and not the right tool for cross-cutting concerns like "everyone in the EMEA region." If your only reason for creating a BU is "these people work together," you probably want a team, not a BU.

User ownership vs team ownership

A record can be owned by a user or by a team. Team ownership is the unsung hero of clean security models.

• User-owned: the record belongs to one person. Reassigning means changing the owner. Access flows through that user's BU.
• Team-owned: the record belongs to a team. Anyone with appropriate access to records owned by that team can work it, and no single person is the bottleneck. The record's BU is the team's BU.

Team ownership decouples "who can work this" from "who is the named individual," which is exactly what you want for shared queues, pooled work, and matrixed teams.

Owner teams vs access teams vs group teams

Three team flavors, and choosing wrong causes real pain:

Owner teams

A team that can own records and be assigned security roles. Members inherit the team's role-granted privileges while operating in the context of records the team owns. Use owner teams when a group of people share a pool of records and you want to manage their access by role assignment. Owner teams are static membership (you add/remove members explicitly).

Access teams

Lightweight, record-level sharing. An access team grants specific privileges (read/write/append/etc.) on a single record to its members, typically via access team templates attached to a table. You don't assign security roles to access teams; you grant per-record access. Use them when collaboration is ad hoc and record-by-record — "this one big deal needs five specialists" — and especially when you'd otherwise create hundreds of owner teams just to model transient groupings. Access teams scale where owner teams would explode.

Microsoft Entra ID (Azure AD) group teams

A team backed by a security or Microsoft 365 group. Membership is managed in Entra ID, not in Dataverse. There are two sub-types: owner group teams and access group teams. The win is governance: you manage membership where you already manage it (Entra), and the Dataverse team mirrors it. Members get the team's assigned roles. Use these when your org already governs access through Entra groups and you want one source of truth for membership. Gotcha: members are materialized into the team on access, so a brand-new group member may need to actually use the app before they fully resolve.

A quick rule of thumb:

• Stable group sharing a record pool, managed in Dataverse → owner team.
• Membership governed in Entra → Entra group team.
• Per-record, ad hoc collaboration → access team.

Hierarchy security

Separate from BUs, hierarchy security lets managers see their reports' records without giving everyone a Deep/Org role. Two models:

• Manager hierarchy — uses the manager field on the user; a manager gets access to records owned by users below them, plus optionally a configurable number of levels deep, often with read-only or read-write depth controls.
• Position hierarchy — uses position records you define, independent of the manager field; useful when reporting lines for data access differ from HR reporting lines.

Hierarchy security is the right answer to "managers need to see their team's stuff" — far cleaner than carving the org chart into nested BUs.

Modeling a real org without BU sprawl

Let's model a company: a sales org operating in North America and EMEA, with a sensitive Legal team whose contracts nobody else should see, and managers who need visibility into their reports.

The naive approach creates a BU per region, per office, per product line — dozens of BUs. Here's the lean version.

Root BU (Contoso)
 ├─ Sales BU
 └─ Legal BU

That's it — two child BUs, on one criterion: a hard data-isolation boundary. Legal contracts must be invisible to Sales, so Legal gets its own BU. Sales does not need a BU per region.

Now the rest:

• Region (NA vs EMEA) is modeled with owner teams inside the Sales BU: a "NA Sales" team and an "EMEA Sales" team, records assigned to the relevant team. Reps get a Business Unit-scoped Sales role, so they see Sales-owned records in their BU; team ownership plus sharing handles the regional pooling. No BU explosion.
• Cross-region big deals use an access team on the opportunity table — pull in specialists per deal without restructuring anything.
• Managers get a manager hierarchy security role, so a sales manager sees their reports' opportunities without anyone holding a Deep or Global role.
• Legal users have a role scoped to their own BU; Sales roles, being BU-scoped, never reach into the Legal BU. Isolation achieved by the one BU split that was actually justified.

The discipline: create a business unit only when you need a hard ownership-and-access boundary that Deep/Org scoping would otherwise cross. Everything else — grouping, regions, shared queues, transient collaboration, manager visibility — is teams and hierarchy security. Reach for a new BU last, not first, and your model stays small enough that a human can still explain why any given user can see any given record.