Four mechanisms decide who sees what
Dataverse security runs on four mechanisms, and most teams operate all four without being able to describe any of them. Business units partition ownership. Security roles grant privileges at a defined depth. Teams group people and can own records themselves. Sharing grants access to one record outside all of that. Every access question resolves through some combination of the four.
Depth carries the most weight and gets the least attention. A role does not grant read on Account. It grants read on Account at user, business unit, parent and child, or organisation depth. The same privilege at a different depth is a completely different grant. Read at user depth shows a salesperson the accounts they own. Read at organisation depth shows them every account the company has ever held, and the two settings sit one click apart.
That resemblance is why people misjudge what they have handed out. A report comes back empty, somebody widens a privilege by one ring, and nothing anywhere records that forty people now read the whole company pipeline. Before editing a role in an environment you did not build, spend an hour with a plain explanation of what Dataverse is.
The business unit tree is the decision you cannot undo
Of the four, business unit structure is the one that is genuinely expensive to reverse. Roles can be rewritten in an afternoon and teams rebuilt over a weekend. Moving a business unit or collapsing two of them moves every record owned beneath it, forces every role assignment attached to it to be reissued, and breaks anything that assumed a particular ownership path.
The common mistake is drawing the tree from the current organisation chart. In week two that feels obvious, because the org chart is the only picture of the company anyone has. It guarantees churn, because reporting lines change every time a director is hired, a region splits, or two divisions merge. Each reorganisation then arrives as a Dataverse restructuring nobody budgeted for.
Draw the tree from data access boundaries that move slowly instead. Those are usually legal entities, regulated jurisdictions, franchise separations, and acquired businesses that keep their own customer base. Test each proposed unit with one question. If this group merged with its neighbour tomorrow, would anybody object to the two seeing each other's records? A firm objection means the boundary is real. A shrug means they belong in one unit, with role design carrying the difference.
Shallow beats deep. Three levels following genuine separations will outlive seven that mirror management. If the separation you are sketching covers groups who should never share data or apps at all, it belongs one layer further out in how you split your environments.
Fewer roles combined, or one role per job title
Role design settles into one of two schools. The first builds a small set of composable roles, each covering one capability such as case handling or quote approval, and assigns two or three to a person. The second builds one self contained role per job title, assigned in a single click.
Composition wins on maintenance. When the rule about who may delete a case changes, you edit one role instead of hunting through nineteen job titled copies that have drifted apart since go live. New job titles get cheap too, since a hybrid role becomes a combination of parts that already work.
The honest cost is readability. Under composition nobody can open one role and know what a person can do, since the effective set is the union of every role from every source, always at the most generous depth in play. Either way you need a standing answer to one question. What can this named person actually do today? Putting that answer in reach early, in the spirit of the permission audits people run on Salesforce, keeps either design honest.
Somebody also has to watch the combinations. Two roles that look reasonable alone can add up to a person who raises a purchase order and approves it, the problem behind one person wearing four hats. Depth makes it worse, because approval at organisation depth reaches records the holder was never meant to see.
Who owns the record, a person or a team
Ownership decides what those depth settings operate on, so it deserves a deliberate choice. Individual ownership fits work with one accountable name on it. A sales opportunity, a case with an assigned agent, a task on somebody's list. The owner reads it at user depth, their manager at business unit depth, and responsibility stays legible.
Team ownership fits work a group carries between them. A queue of unassigned service requests, reference data maintained by a small data office, records that outlive whoever created them. It removes the reassignment scramble when somebody changes job, because nobody held the record personally. The cost is vaguer accountability, and a record owned by thirty people is a record nobody chases.
Prefer teams whose membership comes from a directory group, so joiners and leavers get handled where joiners and leavers are already handled. The model that drifts fastest is the one depending on somebody remembering to update it by hand after a Monday announcement.
Sharing is how a security model quietly stops being one
Sharing deserves a harder look than it gets. It grants access to one record, to one person or team, outside business units and outside roles entirely. It solves the immediate problem in about four seconds, and that speed is why it accumulates faster than anything else.
A shared record stays shared long after the reason has gone. The colleague covering a two week absence still reads the account three years later. The partner brought in for one deal still reads the file after the contract ended. Nothing expires, and no screen will list what a departing employee can still open.
An environment relying on sharing for routine access has stopped having a security design. If half the sales team needs the same records daily, that belongs in a business unit boundary or a team, not in thousands of individual grants. Count share rows per table against record counts. Any table where the two approach the same order of magnitude is telling you the model does not match the work.
Testing, transfers, and the price of every check
Test by signing in and checking as a specific restricted user, never by reading role definitions. A definition describes intent. A session describes reality. Keep three or four standing test accounts matching your most constrained job profiles, refresh their assignments whenever the design changes, and open the real apps before sign off.
Transfers are where surplus access is born. Ownership moves with the record, existing shares stay put, and role assignments follow the person. Somebody moving from the north team to the south keeps every record ever shared with them, and if the old role was never removed, the old depth too. Check movers and leavers monthly on both halves, roles held and records still shared.
The point that matters most at scale is that every access decision costs something at query time. Each retrieve applies the ownership test, walks the business unit hierarchy where depth demands it, and checks team membership and the share table. A deep tree with heavy sharing makes every list view and rollup do more work, and the symptom surfaces as slow grids before anyone connects it back to security. Reporting applies its own rules on top, which is why row level security in Power BI is a separate design task.
The check to run in an environment you inherited
Export every security role and list, for each one, the privileges granted at organisation depth. Almost every environment has a role granting read across the whole organisation on a table somebody assumed was scoped, and it usually arrived through a support ticket two years ago that closed without a review. Put that list in front of whoever owns the data and watch which lines they cannot explain.
Then count the shares. Compare share rows on your three busiest tables against their record counts, and pull the ten people with the most records shared to them. If one of them left the sales team eighteen months ago, you have the shape of the problem and the evidence to fund fixing it. Both checks take an afternoon.
