Security model troubleshooting

What it does

When someone can't see a row, the question is which of the two checks failed. Check Access on the row command bar tells you how a user was granted access — or that they weren't — and Run diagnostics on the user in the admin center covers the earlier failures around licences, groups and roles.

Key facts

Check Access shows access through four routes: ownership, role access, shared access and hierarchy access. Administrators can look up any user; ordinary users can only see their own.
Who has access lists everyone with a given privilege on the row, categorised as Direct role, Team role, Shared, or Application users. It needs IsAccessCheckerAllUsersEnabled and IsAccessCheckerNonAdminAllUsersEnabled set to true through the OrganizationSettingsEditor tool.
The Who has access list deliberately excludes managers who'd get access through hierarchy security, because the list would be too long. That route has to be reasoned about separately.
Selecting a user who has no access to the row returns a blank screen rather than a helpful message.
To reach an environment at all a user needs: sign-in enabled in Entra ID, a licence with a recognised Dynamics 365 or Power Platform service plan (or active per-app plans on the environment), membership of the environment's Entra group if one is assigned, and at least one security role assigned directly or via a group team.
Run diagnostics sits under Settings > Users + permissions > Users in the admin center. Running it also synchronises the user's Entra information into the environment.
Known limitation: diagnostics only checks roles assigned directly to a user. It doesn't check roles inherited through group team membership.
Certain users aren't pre-provisioned into environments at all — Office-licence-only users with a Dataverse plan, owners of Entra groups assigned to environments, and members of Entra groups behind a group team. They can be added on demand.
The "we cannot find any apps for your role" class of error usually traces back to User Entity UI Settings Read not being set to User on the role.

When to use / skip

Work outward from the row, not inward from the role. Check Access on the specific record answers "how does this person get in" in seconds and stops you guessing. Only when Check Access shows nothing at all do you go up a level to Run diagnostics and the licence-and-group checks. The mistake almost everyone makes is starting in the security role editor, adding a privilege, watching it not help, and adding another — after three rounds of that the model is worse and the ticket is still open. If the user can't see the environment or the app at all, that's a licence, Entra group or app-opener problem, not a row access problem, and Check Access won't tell you anything.

Configuration decisions

Whether the Who has access settings are enabled in every environment, which they should be before you need them.
Whether non-admins can use Who has access, or only administrators.
What your standard triage order is, written down, so the service desk doesn't reach for privileges first.
Whether service accounts and application users are documented, because "an application user did it" is a common answer that takes ages to reach.
How you record the intended access design, since troubleshooting without a baseline is just opinion.

Gotchas

The usual root causes, roughly in order: the user's business unit is wrong, the row is owned by a service account, a team grants access nobody knew about, a share nobody remembers, or the privilege is at User level when the row belongs to someone else.
Roles assigned through group teams aren't checked by Run diagnostics. A user with all their access via a group team can look broken in diagnostics and be perfectly fine.
Column security is the invisible one. The user can open the row, some fields show asterisks, and it presents as a form or data problem. Test with a non-admin, because admins never see the masking.
Cascading share behaviour explains a lot of surprising access, and it doesn't appear as a share on the row you're looking at — it came from a parent.
Testing as a system administrator proves nothing about column security and very little about anything else. Keep a dedicated test account per role.
The blank screen when checking a user with no access looks like the tool failing. It's the answer.

Consultant notes

Turn on the access checker settings during environment setup, not during an incident. It's a five-minute job that pays for itself the first time.
Give the service desk a one-page triage script: Check Access on the row, then Run diagnostics on the user, then look at team membership and shares, and only then consider a role change. It stops the slow erosion of the security model.
Keep a set of persona test accounts, one per role, and use them for every release. It's the only reliable way to catch security regressions before users do.
When you inherit an environment, audit shares, team role assignments and organisation-level privileges before you touch anything. That's usually where the surprises are, and it's a much better first conversation with the client than a list of symptoms.

Worth revisiting when diagnostics starts checking group team role inheritance, or if hierarchy-derived access shows up in Who has access.