Permission Inspector

Ask in a task, in plain language: "why can't Jack see Annual Revenue on Account?", or the other way round — "why CAN this contractor see that account?". OrgBolt walks the org's visibility model one layer at a time and answers with the layer that decides it.

Every verdict names its evidence: which profile, which permission set, which sharing rule, which page. You can check any claim in Setup yourself. A progress panel shows each layer as it lands, so a trace that takes a few seconds looks like work happening.

The walk stops at the first layer that says no. That layer is the answer, and every layer after it is marked "not evaluated — access is already denied at …" rather than left out. You read one cause, not a wall of diagnostics.

When a record is granted, the trace names the path that granted it — the user owns it, their queue owns it, the org-wide default is public, the role hierarchy reaches down to the owner, a named sharing rule shares it, or a share row does. When it is denied, the trace lists every path it checked and why each one failed.

Salesforce does not publish an answer for everything. Where that is true, the trace says so instead of inventing one. These layers report as "not traced" and never as a verdict:

• Whether a license type admits an object. The licence itself is named; the entitlement is not queryable.
• Per-user record type visibility, when the object has record types. An object with none cannot be constrained by them, and that case is answered.
• Grant Access Using Hierarchies on a custom object. Salesforce exposes no API for the toggle, so the trace says it assumed it is on — if you cleared it in Setup, that path is wrong and the trace tells you to check.
• Whether a session-based permission set is activated in the user's session right now. Such a set is reported as a near miss, not as a grant.

OrgBolt also checks itself. After the walk reaches its own verdict, it asks Salesforce the same question and compares the two answers. If Salesforce grants access that no traced path explains, the trace says the grant comes from a layer it does not model — implicit sharing from a parent record, a territory, or an Apex share — and refuses to name which. A wrong cause is worse than an honest gap: you would go and change the wrong thing.

Object and field questions need no permission from you — permission sets, profiles, sharing rules and page layouts are configuration, and OrgBolt reads configuration all the time. A question about one record is different. Reading who owns it, which shares are on it, and what Salesforce says about it means reading record data, and that needs the same standing permission as a data query.

Without it, the trace still runs and still answers. Object, field, record type and license layers all complete; the record layers are marked skipped with the reason, and the chat offers you two choices: allow record data for this org and re-run, or keep the partial answer.

The permission is re-read every single time a trace runs, so revoking it in Settings → Orgs stops the record reads on the very next trace, including part-way through a task.

When the trace ends in a denial it can fix, it offers two options side by side: the best existing permission set (or permission set group) in your org, and a new one scoped to just the missing privilege. Both always render, because the trade-off between permission-set sprawl and least privilege is yours to make, not OrgBolt's.

"Best" means the smallest addition for that specific user — the candidate that adds the fewest privileges they do not already hold. Not the smallest set in the org: a five-permission set is the wrong answer when the user already has four of the five and a forty-permission set would add three. The score is arithmetic over what each set grants, so you can reproduce it. The AI does not rank the options.

• A set that would not actually lift the denial is never offered, however small it is.
• A set carrying View All Data or Modify All Data is dropped, not ranked — it would score as a tiny addition while handing over every record in the org.
• A session-based set is not offered: assigning one grants nothing until the user activates it in their session.

One cause swaps the first button. When the user is already assigned to a set that grants what they are missing — and that assignment has expired — assigning another set would be the wrong fix. The trace names the expired assignment, says when it expired, and offers to renew it instead, next to the same scoped-new-set alternative. You choose how long the renewed access lasts: 7, 30, or 90 days, or no expiration. Nothing is pre-selected, and nothing is renewed until you choose.

Applying either fix — an assignment or a renewal — immediately runs a second trace, so you get a before-and-after view. That is what lets you tell the person who filed the ticket "verified fixed", with the evidence attached.

• The saved trace holds the object, the field, and the record's 18-character Id. Nothing else about the record.
• No record values are stored, and no display names. Names appear on your screen while the trace runs and in the task transcript, because you typed one and read the other.
• Every trace writes an audit row — permission_trace.completed — carrying the verdict, the layer that decided it, and whether OrgBolt's answer and Salesforce's own answer agreed.
• Applying a fix is audited the same way permission set assignment always has been.

Traces stay with the task. Deleting the task deletes them; deleting your account purges them.