The Salesforce access layers, explained
When someone asks “who can see this record?”, the honest answer is that Salesforce decides it for you across several layers, and the layers combine in ways that are easy to lose track of. Knowing the layers is the difference between guessing and knowing. Here is the whole stack, from the broadest setting down to the single field.
1. Object permissions
Before anything else, a user needs Read on the object. Object permissions come from the profile and from any permission sets assigned to the user. No Read on Account means no Account record is visible, full stop. This is the gate everything else sits behind.
2. Org-wide defaults
Org-wide defaults (OWD) set the baseline for each object: Private, Public Read Only, or Public Read/Write. Think of OWD as the floor. If an object is Private, users see only the records they own or that are shared up to them. Everything below this point is about opening that floor back up for the people who genuinely need access.
3. The role hierarchy
If an object’s OWD grants access up the hierarchy, a user inherits access to records owned by people below them in their role branch. A sales manager sees their reps’ opportunities not because anyone shared them, but because the role hierarchy rolls that access upward. It is quiet and automatic, which is exactly why it surprises people.
4. Sharing rules
Sharing rules open access sideways, across the hierarchy. They grant a group, role, or set of users access to records that meet a condition (records owned by a region, or records where a field has a certain value). Sharing rules are powerful and they accumulate. Most orgs have more of them than anyone remembers writing.
5. Groups, queues, and manual sharing
Sharing is frequently granted to public groups and queues rather than to individuals, and group membership can nest inside other groups. Manual and team sharing add one-off grants on top. The result is that “who is in this group” becomes part of “who can see this record,” one more place access hides.
6. View All and Modify All
Some permissions cut straight past everything above. View All Data and Modify All Data, and their per-object cousins View All and Modify All, grant blanket access regardless of OWD, hierarchy, or sharing rules. These are the permissions most worth auditing, because a single permission set can quietly hand someone the whole object.
7. Field-level security
Even when a user can see a record, field-level security decides which fields on it they can read. A record can be visible while its most sensitive field is not, or the reverse, which is why “can they see the record” and “can they see the revenue field” are two different questions.
Why the layers matter
Each layer is reasonable on its own. The trouble is that access is the sum of all of them, evaluated together, and no single screen in Salesforce shows you that sum. To answer “who can see this, and why” by hand, you have to trace a path through all seven layers for every user, and then do it again the next time something changes.
That tracing is exactly what Who Sees What does for you. It reads your org’s configuration (read-only, with nothing installed) and resolves all seven layers at once, so when you ask who can see a record or a field, you get the complete list and the specific reason for each person: the profile, the permission set, the sharing rule, or the group that grants it. The layers do not change. What changes is whether you can see them clearly.