Designing a Dataverse security model

What it does

A Dataverse security model is built from four things: business units as the ownership boundary, security roles as the privilege set, teams as the way to grant across boundaries, and sharing as the per-row exception. Almost every design failure comes from using the wrong one of those four for the job.

Key facts

Business units define a security boundary and every user and team belongs to exactly one. Roles grant access at four depths — user, business unit, parent-child business unit, and organisation.
Modernised business units let a user be assigned a role from a business unit other than their own, and let records be owned in a business unit other than the owner's. This is the supported answer for matrix organisations and removes most of the reasons people used to build deep hierarchies.
Owner teams can own records, so team membership grants direct access. Access teams grant access to specific rows without owning them.
Every business unit gets a default team created automatically when the business unit is created.
Sharing grants access to a single row for a single user or team. Microsoft's explicit guidance is to share only what's necessary with the smallest set of users or teams, because extensive sharing causes performance problems at scale.
Microsoft also advises against automating sharing and recommends turning off share privileges in security roles where you can.
Privileges are cumulative across roles. A user with two roles gets the greater access of the two — you can't take access away by adding a restrictive role.
Column-level security is configured separately from row access, through field security profiles, and applies regardless of the row-level model.

When to use / skip

The default position, and it's right far more often than clients expect: one business unit, a small number of roles, teams for cross-cutting access, and sharing reserved for genuine exceptions. Most organisations that ask for a business unit hierarchy are describing a reporting structure, not a security requirement, and there's no rule saying those have to match.

Build a business unit hierarchy when data genuinely must not be visible across parts of the organisation — separate legal entities, regulated separation, franchise or brokerage models where one branch seeing another's pipeline is a commercial problem. Everything softer than that is better served by teams and role depth.

The design that reliably fails is the one that starts with an org chart. Someone draws thirty business units mirroring the company structure, then discovers half the users work across them, then patches it with sharing rules, and eighteen months later the system is slow, nobody can explain who can see what, and reorganising the business means rebuilding security. Modernised business units exist precisely because that pattern was so common.

Configuration decisions

Business unit hierarchy versus a flat structure with teams. Decide from the data separation requirement, not the org chart.
Whether modernised business units are turned on, which changes what's possible and is a decision worth making explicitly rather than inheriting.
Owner teams versus access teams: predictable group access versus per-row collaboration. Auto-created access teams via team templates are the pattern for "the people working on this record".
Whether share privileges stay in the roles at all. Removing them is a real design choice with real user consequences.
Whether column-level security is needed, and on which columns — it's the answer to "some people can see the record but not the salary", and people reach for business units for that instead.
Where hierarchy security (manager or position-based) fits, if managers need visibility of their reports' records without a role change.

Gotchas

Roles only add. Teams and users accumulate privileges across every role they hold, so a "restricted" role does nothing if the user also holds a broad one.
Moving a user between business units has consequences for record ownership and role assignment that surprise people during reorganisations. It's not a field update.
Heavy use of sharing degrades performance at scale, and it degrades gradually, so nobody connects the slowdown to the design decision made two years earlier.
Automated sharing from a flow or plug-in is the classic way to generate millions of principal-object-access rows. It works fine in test and becomes the performance incident in year two.
Column-level security failures are silent in most surfaces — the field just isn't there. Users report it as a bug, not as security working.
Business process flows, queues and dashboards all have their own access considerations that the row-level model doesn't cover.

Consultant notes

Get the security requirement written as sentences before anyone draws a diagram. "A branch manager must not see other branches' cases" is a design input; an org chart isn't.
Model it as if the client will reorganise, because they will. A design that survives a merger is worth more than one that's precisely tuned to today's structure.
Test with real personas at real privilege levels, and make the client's security lead sign off on what each persona actually sees. Screenshots, not descriptions.
Push back on per-row sharing as a design pattern rather than an exception. Every time you agree to it, you're borrowing performance from the future.
Security is the hardest thing to change once there's production data. Spend the extra week in design; it's the cheapest week in the project.

Re-read before any client reorganisation or acquisition — that's when a security model either holds or has to be rebuilt