Org-wide defaults: the floor of your sharing model
If you only understand one Salesforce access setting deeply, make it org-wide defaults. Almost every other sharing decision is a reaction to what you set here. Get the floor right and the rest of your model has a chance. Get it wrong and you spend years patching around it.
What org-wide defaults actually do
For each object, the org-wide default (OWD) sets the baseline visibility for records a user does not own: Private, Public Read Only, or Public Read/Write. There is also Controlled by Parent for detail objects, which inherits from the master. The key idea is that OWD is the most restrictive setting, and everything else (the role hierarchy, sharing rules, manual sharing) can only open access up from there. Nothing widens by accident below the floor, and nothing you build on top can make the floor lower.
The instinct to go Public, and why to resist it
Public Read/Write is tempting because it makes the “I can’t see this record” tickets stop. It also makes your sharing model meaningless, because once everything is public there is nothing left to audit and no way to scope access to a team, a region, or a role. The healthier pattern is to set the floor as private as the business can tolerate, then deliberately open access for the groups that need it. Restrictive by default, permissive by decision. That way every grant is something someone chose, which means every grant is something you can review.
The “Grant Access Using Hierarchies” checkbox
For custom objects, there is a quiet but important setting next to OWD: whether access rolls up the role hierarchy. Leave it on and managers inherit access to their reports’ records automatically. Turn it off and they do not. This single checkbox decides whether your hierarchy is part of your access model or not, and it is easy to set without realizing how much it changes.
Why OWD is hard to reason about later
The trouble with the floor is that you set it early, when the org is small, and then the org grows on top of it. New objects, new roles, new sharing rules, and new permission sets all interact with that original choice. A year later, “is Account private?” has a simple answer, but “given that Account is private, who can actually see this specific Account, and why?” does not. The floor is one setting; the access that results from it is the sum of every layer above.
Seeing the floor and everything on top of it
This is where a clear picture helps. Who Sees What reads your org’s OWD for each object and then traces every layer that opens access above it, so you can see not just what the baseline is but what it adds up to in practice. You can confirm an object is genuinely private, find the records where access is wider than the floor would suggest, and see exactly which rule, role, or permission opened each one. The point is not to second-guess your defaults. It is to be able to look at any record and know that the access you see is the access you meant.
Set the floor on purpose, open it on purpose, and keep a way to check that the two still match. That is most of a healthy Salesforce sharing model right there.