Live on AppExchange · Free · Never requires payment
Pick anyone in your org, drill into any app, and see every object, field and record they can access, with the exact profile, permission set or sharing rule that granted it. 100% native. Read-only.
Someone asks why a user can see a record they should not. Answering it means stitching together profiles, permission sets, permission set groups, role hierarchy, sharing rules and manual shares in your head, one Setup screen at a time.
Profiles, permission sets, permission set groups, role hierarchy, sharing rules and manual shares all grant access, and nothing shows them together.
Setup starts from a permission set and lists who it affects. The question you were asked started from the person.
Security reviews, onboarding checks and offboarding checks all stall when confirming one user's effective access takes half an hour.
An access question left half-answered is how over-permissioned users stay over-permissioned, right up until a compliance check or an incident finds them first.
Instead of starting from a permission set or profile and working out who it touches, Who Sees What starts with the person, and resolves everything into one clear, user-centered view.
Anyone in your org. No configuration, no reverse-engineering, nothing to define before you ask.
Along with the exact profile, permission set or sharing rule responsible for granting it.
It works across Sales Cloud, Service Cloud, Data Cloud and Nonprofit Cloud, on nearly every Salesforce edition, and because it is read-only it is safe to install in production and safe to hand to anyone who needs an answer.
There is no configuration stage. Install it, pick a person, and read the result.
Installs from AppExchange in a few clicks. Lightning ready, nothing to configure before you can use it.
Start from the person the question is actually about, rather than from a profile or permission set.
Narrow to the app you care about, or look across the org, whichever the question calls for.
Object access and field-level security together, resolved into one view instead of several Setup screens.
Record visibility included, which is where role hierarchy, sharing rules and manual shares usually complicate the answer.
Every result names the exact profile, permission set or sharing rule responsible, so you know precisely what to change.
One question, answered completely, without changing anything.
Pick any user and see every object, field and record they can touch. No reverse-engineering permission sets required.
Every access result shows the exact profile, permission set or sharing rule that granted it.
Runs entirely inside Salesforce with no write access and no external data storage. Nothing to break, nothing to expose.
Works across Sales Cloud, Service Cloud, Data Cloud and Nonprofit Cloud, on nearly every Salesforce edition.
Speeds up troubleshooting, security reviews, onboarding and offboarding checks, and permission set cleanup.
Scope the question to a single app or look across the whole org, whichever the situation calls for.
Works in orgs using Person Accounts, so the answer is complete rather than partial.
Never requires payment, and there is no user cap or usage tier.
Standard setup screens are organised around configuration objects. This one is organised around the user, which is how access questions arrive in the first place.
Access is rarely explained at one level alone. Seeing object, field and record access side by side is what makes an answer conclusive rather than partial.
Knowing a user can see something is only half the answer. Knowing which rule granted it is what lets you fix an over-permissioned user with confidence.
A permission inspector that could also change permissions would be a liability. This one cannot, which is what makes it safe to install in production and safe to hand to anyone who needs an answer.
Nothing about a profile, permission set, role or sharing rule can be modified from inside the app.
It is a native package. Your permission model is never transmitted to an external service for analysis.
Because it cannot change anything, access to it can be granted more widely than access to Setup.
Showing the specific granting rule turns an assertion about a user's access into something you can put in front of a reviewer.
Same question, minutes instead of an afternoon, and an answer you can defend.
An access question stops being an afternoon of cross-referencing setup screens.
Object, field and record access together means fewer partial answers that later turn out wrong.
Read-only means installing it and using it cannot change a single permission in the org.
Being able to show the granting rule turns an assertion about access into evidence.
Access that nobody intended is far easier to find when it is visible in one place.
No license, no per-user fee, and nothing to renew.
| Standard setup screens | Manual spreadsheet audit | Who Sees What | |
|---|---|---|---|
| Direction of enquiry | Permission set first | Whatever you assemble | User first |
| Object access | Several screens | Manual | One view |
| Field-level detail | Separate screen | Manual | Included |
| Record-level access | Hard to confirm | Estimated | Included |
| Shows the granting rule | Inferred | Inferred | Shown |
| Risk of changing something | Yes, you are in setup | None | None, read-only |
| Time to an answer | Hours | Longer | Minutes |
Comparison reflects publicly documented behaviour at time of writing. Verify before publishing.
Resolve a user's access question in seconds instead of a 30-minute investigation across Setup.
Run them properly before a compliance check or an org health check, rather than sampling and hoping.
Confirm a new joiner's access is exactly what it should be on day one, not three weeks later.
Verify that access has actually been removed everywhere it was granted, with evidence.
See which rules are actually doing the work before deleting anything from a sprawling permission model.
Document and explain an org's access model to stakeholders during an implementation.
It shows the effective access of a single Salesforce user: every app, object, field and record they can reach, and the exact profile, permission set or sharing rule that granted each piece of access.
Setup is organised around permission sets and profiles, so you work backwards from configuration to people. This starts from the user, which is the direction access questions are actually asked in.
No. It is read-only by design. Nothing about a profile, permission set or sharing rule can be modified from inside the app.
It is native and read-only, which is exactly the combination that makes it safe to install in a production org.
Both, along with field-level security, since record access is where role hierarchy, sharing rules and manual shares usually complicate the answer.
It works across Sales Cloud, Service Cloud, Data Cloud and Nonprofit Cloud, on nearly every Salesforce edition, and supports orgs using Person Accounts.
No. It runs entirely inside your org with no external service involved.
It is free and never requires payment. There is no user cap and no usage tier.
Administrators, consultants and developers. It speeds up troubleshooting, security reviews, onboarding and offboarding checks, and permission set cleanup.
Install Who Sees What from the Salesforce AppExchange and answer your next access question in two clicks.
Get it on AppExchangeFree managed package · No credit card · Published by TwinStack Solutions
Native apps built around the same idea: less manual work between your data and your Salesforce org.
Responses, straight into Salesforce.
Import smarter. Map faster.
New posts most weeks: setup guides, integration patterns, and what we learn from the Salesforce community.
The five places permission comes from, and why no screen shows them together.
A practical review process for effective access in a mature org.
How to trace an access grant back to its source.
