Who can see what in your Salesforce org? Start with access
Ask a Salesforce admin “who can see this field?” and the honest answer is usually “let me get back to you.” Not because they are not good at their job, but because the answer is spread across more layers than any person can hold in their head at once.
Access is a stack, not a setting
A single user’s effective access is the sum of:
- their profile and any permission sets (and permission set groups),
- their place in the role hierarchy,
- public groups and queues they belong to,
- sharing rules, manual shares, and team memberships,
- field-level security on top of object access,
- and the defaults that managed packages quietly bring with them.
Change one layer and the effective answer changes everywhere it touches. That is why “who can see what” is genuinely hard, and why it tends to get answered with a guess.
You cannot secure what you cannot see
Before you can decide whether access is too broad, you have to be able to state, precisely, what access exists today and the exact grant behind it. That is the foundation everything else stands on: least-privilege reviews, audit evidence, incident response, compliance mapping.
This is where Who Sees What starts: it reads your access configuration, read-only, and tells you who can reach a record or field and the specific grant that allows it. From there, Lynceon turns that picture into judgment, what is risky, how severe, and what to fix first.
A practical first step
You do not need a six-month program to make progress. Start by answering one question precisely for your most sensitive object: who can read it, and why. The “why” is the part that turns a list of names into a decision. Once you can answer that on demand, the rest of a security program has something solid to build on.
Access first. Everything else in Salesforce security depends on it.