Who can actually read this field?
Not which roles mention the table. Which principals can reach the column, what each one is allowed to do with it, and the path they took to get there. Pathix resolves it from either end, across direct roles, team membership, the business-unit hierarchy and field security profiles.
Every principal, and how each one got there.
The list matters less than the path. A user who holds write directly is a decision somebody made. A user who holds the same write through a team they were added to for an unrelated reason is the one nobody remembers granting, and it is the one an access review is looking for.
Ask it from the field, or from the person.
Access reviews start from a person. Incidents start from a column. Pathix answers both from the same resolved model, so the two never disagree.
Click a question to see the view it returns.
“Has write on account” can mean four different things.
Every privilege in Dataverse carries a scope, and the scope is what decides whether a grant is routine or a problem. The same privilege on the same table means one record or the entire environment depending on it, so Pathix reads the scope on every grant rather than reporting that the privilege exists.
Their own records only.
Every record in their business unit.
Their business unit and everything beneath it.
Every record in the environment.
A Business Unit or Parent-Child scope means nothing until you know where the principal sits in the tree and who reports to them. Pathix walks the business-unit structure and the manager hierarchy, and it applies the platform's documented depth cap on that rollup rather than implying the walk goes on forever.
Access reached through a team is identical in effect to access held directly, and it is the path that survives an offboarding checklist. Pathix resolves both and labels which one a given grant came through, so a review can tell a decision from an inheritance.
A secured column is only as secured as what it flows into.
Pathix reads which columns are field-secured, which profiles grant read, update or create on them, and who belongs to each profile. It accounts for the System Administrator bypass correctly, so what you are looking at is real exposure rather than a list of false alarms.
Two gaps are worth the trouble on their own. A column can be secured with no profile granting access to it, which does not protect anything and quietly breaks the people who were meant to see it. And a secured value can land in an unsecured column through an attribute mapping or a formula, which is the one case where reading the security model alone would miss it: catching that needs the dependency graph and the access model at the same time, which is the reason Pathix keeps both.
7 security surfaces, read on every scan.
All of it read-only, through the documented API, by an application user holding a least-privilege role Pathix ships and documents.
Every role, every privilege it grants, and the scope of each grant: User, Business Unit, Parent-Child Business Unit, or Organization. The scope is the part that decides whether a privilege is routine or a problem.
Users, application users (the integrations), and teams, each with its type and its enabled or disabled state. Disabled is tracked because a disabled account that still holds roles is one of the conditions worth catching.
Roles held directly, and roles reached through a team. Both paths grant the same access, and the team-mediated one is the path access reviews miss.
The business-unit tree and the manager hierarchy that widens a Business Unit or Parent-Child scope into real reach. The hierarchy rollup has a documented depth cap, which Pathix applies rather than pretending the walk is unbounded.
Which columns are field-secured, which profiles grant read, update or create on them, and who is a member of each profile.
Share counts and the tables shared, in aggregate. Pathix never stores which records were shared: that question is a deliberate handoff back to Dataverse, and the boundary is a design decision rather than a gap.
The environment-level switches that change what the rest of this means, including audit configuration and hierarchy settings.
How Pathix itself is deployed and constrained is on Security, and what it stores about your principals is on Your data.
Able to write is not the same as writes.
Permissions and dependencies are kept as two separate projections and never merged into one edge. A role that grants write access to a column is not a writer of that column, and letting a permission appear in a dependency list as though it were would create exactly the confusion an access review exists to remove.
The single point where they touch is a runtime access grant: logic that programmatically shares a record is an action rather than a permission, so it is recorded as an edge, and only on the security projection.
Three things worth being precise about.
Pathix reads the security model as it was configured at scan time and resolves what a principal is able to reach. It did not observe a request being allowed or denied, and an answer here is a statement about configuration, not about something that happened.
Manual record shares come back as counts and the tables involved. Pathix never stores which records were shared. That question belongs to Dataverse and is a deliberate handoff, which is also why a permissions review here cannot leak record contents.
The answer reflects the environment as of the scan that produced it. A role assigned an hour ago shows up on the next scan, and the view says which scan it came from rather than implying it is live.
The conditions Pathix flags on this surface.
Resolving access is the investigation. Every scan also runs the deterministic checks over the same model without being asked: a role shared between a human and an integration, a disabled account still holding its roles, an integration able to rewrite the security model, a column secured with nothing granting access. Those are catalogued as findings, with the control they map to, rather than repeated here.
Run the access review you have been deferring.
The demo runs the real console on sample data, so you can resolve access from both ends before anyone touches your environment.