Who Can See What? Making Dataverse Security Roles Visible with AccessLens

A user opens a record they should never have seen. Or the opposite, and usually louder: a sales manager cannot open an opportunity her own team created, and she wants to know why, today. Either way the ticket lands on an admin, and the investigation begins: open the user record, list the Dataverse security roles, check which teams the user belongs to, open each team and list its roles, check the business unit, check whether the record was shared, check whether hierarchy security is enabled and where the user sits in the manager chain.

Here is my opinion up front: the admin UI shows you configuration. It never shows you effective access. Those are different questions, and the gap between them is where every one of these investigations lives.

Five mechanisms combine to decide what a user can do: business units, security roles, teams, record sharing, and hierarchy security. Each one is documented. Each one is sane. The platform gives you no single view of the combined result, and that absence is the actual problem.

Why Dataverse security roles are hard to reason about

Read the Microsoft Learn documentation on Dataverse security concepts and every layer makes sense in isolation. Roles grant privileges at depths scoped by business unit. Teams carry roles that members inherit. Sharing grants per-record access outside the role model. Hierarchy security lets managers reach their reports’ records.

The difficulty is composition. Dataverse access is additive and union-based. There is no deny. A user’s effective access is the union of privileges from directly assigned roles, roles inherited through teams, explicit shares on specific records, and hierarchy grants, all evaluated against business unit scope. The highest access level wins per privilege. Nothing ever subtracts.

That union is also full of nuances that trip up experienced admins. Team-inherited privileges evaluate in the context of the team’s business unit, not the user’s. Sharing is runtime data living on individual records, which makes it the hardest layer to audit of the five. Hierarchy security operates entirely outside the role editor.

The docs describe each layer cleanly. Production environments do not stay clean. Roles get copied and renamed. Teams accumulate for every project since 2019. Shares pile up because sharing was the fastest fix for an urgent ticket, six admins ago. After a few years, the configuration has drifted so far from anyone’s mental model that nobody in the building holds the full picture.

There is a structural reason the UI cannot show you the combined answer: effective access is per-record and computed at runtime. It is combinatorial across user, table, privilege, business unit scope, and record. No native screen owns that result. The security role editor answers “what is configured.” Nothing answers “what can this user actually do,” and those are different questions.

This is a governance gap, not an inconvenience

Auditors and incident responders ask access questions in the reverse direction. Not “what roles does Maria have?” but “who can delete accounts?” Not “is this role well designed?” but “enumerate every actor who can export customer data.” At the table-privilege level you can reconstruct this by hand, role by role, team by team. At the record level, with sharing and hierarchy in play, you realistically cannot.

This matters because governance controls are completeness assertions. “Only the finance team can delete invoices” is a claim about the entire set of actors holding that capability. If you cannot enumerate the set, you cannot verify the claim, and an unverifiable control is a deficiency in most audit frameworks, not a documentation nuance.

My position: if you cannot explain access, you cannot certify it. An access model nobody can interrogate is indistinguishable from an access model nobody controls, regardless of how carefully it was designed on day one. This is the same discipline that risk-tiered agent governance demands on the AI side of the Microsoft stack: a control you cannot inspect is a control you do not have.

To be clear about the target of the criticism: the Dataverse security model is not flawed. It is expressive, layered, and it scales to genuinely complex organizations. The tooling for reasoning about what it produces is what falls short. Visibility is a prerequisite for governance, not a nice-to-have, and today that prerequisite is unmet in the native experience.

AccessLens: effective access, with receipts

AccessLens is a tool I built to close that gap. It is a read-only PCF investigation control that shows, for any user, their effective permissions and the source of every single one: this privilege comes from this role, that one arrives through this team, this record is visible because of an explicit share, that one because of hierarchy.

The key word is traceable. An answer without a source is a guess. “Maria can delete accounts” is useless in a security review if you cannot say why, because the follow-up question is always “and how do we change that?” Source attribution turns the answer into something actionable: revoke the share, adjust the role, remove the team membership, and you know in advance which lever moves which permission.

AccessLens does three things. It computes effective access per user. It attributes every permission to its source. And it runs the lookup in reverse, which I will get to next. That is the complete feature list. It does not redesign roles, score your configuration, or recommend changes.

The practical effect: an investigation that commonly eats hours of manual cross-referencing becomes a lookup whose output you can capture as an artifact for the review file. That time estimate is common experience, not a measurement, and your environment’s complexity sets the real number. The structural point stands either way: a traceable answer survives scrutiny; a reconstructed one invites it.

Reverse lookup: the question the native UI cannot even ask

Everything native runs forward: pick a user, inspect their configuration. The Check Access feature on a record is genuinely useful and honest work by the platform team; it tells you what a specific user can do on that specific record, and why. But it is one user, one record, forward direction.

Audits run backward. “Who can delete rows in the account table?” “Which users can see this one sensitive record?” Access certification, least-privilege attestation, separation-of-duties checks, and blast-radius analysis during incident response all start from a capability and demand the list of actors. AccessLens runs the query in that direction, across roles, teams, shares, and hierarchy at once. One distinction worth keeping sharp when you run these queries: “who holds delete privilege on the account table” is a configuration question, while “who can delete this account record” additionally pulls in shares and hierarchy. AccessLens answers both; conflating them is how reviews go wrong.

The native cells in that table are deliberately honest. Nothing there is impossible manually. It is all possible the way counting grains of rice is possible. Reverse lookup is the audit-season feature because audit season is exactly when you need the backward question answered fifty times in a week.

Design choices as trust signals

Strong position: a security investigation tool that can mutate security is a liability, full stop. An auditor evaluating your process will, and should, ask what the tool itself can do. AccessLens is read-only by design. It cannot change roles, cannot modify shares, cannot touch team membership. There is no mode, flag, or future setting that changes this. When you are deciding whether to trust a tool near Dataverse security, evaluate it first on what it cannot do.

The second choice is config-driven setup. AccessLens adapts to the environment it lands in rather than assuming a particular role structure, business unit depth, or naming convention, because after years of drift no two environments share those assumptions. I treat both choices as pcf best practices for anything built on the Power Apps component framework that touches security data. That label is my judgment as the tool’s author, not Microsoft’s guidance verbatim, but the underlying principle of least capability is not controversial anywhere in security engineering.

One more principle that matters more than it sounds: a security tool must distinguish “no access” from “could not evaluate.” Silent under-reporting is the dangerous failure mode, because it produces confident wrong answers in exactly the context where confidence gets written into an audit response. Design for loud uncertainty.

What a tool should never do for you

Visibility is not governance. The dividing line is deterministic computation versus normative decision. Computing effective access, attributing sources, running reverse lookups: all mechanical graph resolution, and a tool should own all of it. Deciding whether Maria should have delete rights on accounts, whether a role violates least privilege, how often access reviews run and who signs them: those are judgments, and they stay with humans.

AccessLens makes those jobs faster and defensible. It does not make the decisions, and it never will, because a tool that claims to is selling you absolution, not security.

So here is the dangerous question in Dataverse, and it is not “is our security model good?” It is “can anyone here actually answer who can see what?” If that answer takes hours, you do not have a visibility problem. You have a governance problem, and making effective access inspectable is the first fix, not the last.