If OWD Is Private, Can a User Still See It Using Their Role?
Short version: yes — but the role hierarchy only opens access in one direction, and one setting decides whether it applies at all.
Yes. When an object’s organization-wide default (OWD) is Private, a user can still see a record they don’t own if they sit above the record’s owner in the role hierarchy. Access flows upward only — managers inherit their subordinates’ records, never the reverse — and the object must keep Grant Access Using Hierarchies enabled.
Why the Role Hierarchy Opens a Private OWD
Organization-wide defaults set the floor, not the ceiling. Setting an object’s OWD to Private declares the most restrictive baseline: by default, users can view and edit only the records they own. But Private is a starting point, not a wall.
Salesforce gives you four record-level access tools that open that baseline back up — organization-wide defaults, the role hierarchy, sharing rules, and manual sharing — listed in order of increasing access. You lock data down with OWD, then selectively grant access with the rest. The role hierarchy is the tool that answers your question, and it works automatically: the moment a user is placed above a record’s owner in the hierarchy, they inherit access to that record with no sharing rule required.
That is exactly why a Sales Manager can open a sales rep’s Private opportunity even though the rep owns it. The Private OWD never restricted the manager — it only restricted everyone who isn’t above the owner.
A Private OWD does not mean “only the owner can see the record.” Anyone above the owner in the role hierarchy inherits access automatically. Scenario questions lean on this constantly — read carefully for who sits where in the hierarchy before deciding who can see what.
Which Direction Access Flows
Role hierarchy access is one-directional: it flows upward. A user inherits access to records owned by — or shared with — people in roles below them. The reverse never happens by default; a subordinate gets no automatic access to a manager’s records.
Picture a Sales Manager role sitting above a Sales Rep role, with Opportunity OWD set to Private:
- The Sales Manager can view and edit every opportunity the Sales Rep owns.
- The Sales Rep sees none of the Sales Manager’s opportunities.
- Two reps at the same level see nothing of each other’s records — a peer isn’t “above,” so there’s no inheritance.
One nuance worth committing to memory: a manager inherits access to every record their subordinate can reach through any mechanism — ownership, sharing rules, or manual sharing — not just records the subordinate personally owns. The hierarchy carries the subordinate’s full visibility upward. For how those mechanisms stack together, see the complete guide to Salesforce’s record-level security model.
Build the role hierarchy around who needs to see whose data, not your org chart. Because managers automatically gain visibility into their reports’ records, you rarely need a sharing rule to grant that vertical access — the hierarchy already does it.
Standard vs. Custom Objects: One Setting Decides
Whether the hierarchy grants this upward access is controlled by a single setting: Grant Access Using Hierarchies, found at Setup → Sharing Settings → Organization-Wide Defaults. It is enabled by default for every object — but you can only change it on custom objects.
Standard Objects
Grant Access Using Hierarchies is always selected and cannot be edited (it’s enabled for most, though not all, standard objects). The role hierarchy will always open a Private record upward.
Custom Objects
Enabled by default, but admins can deselect it. When unchecked, users higher in the role hierarchy are prevented from inheriting access to that custom object’s records.
To change it: from Setup, enter Sharing Settings in the Quick Find box and select Sharing Settings, click Edit in the Organization-Wide Defaults section, then toggle the checkbox and save. Salesforce runs a sharing recalculation to apply the change.
When a Role Still Can’t See the Record
Sitting above the owner isn’t always enough. A role will not surface a Private record in any of these cases:
- Grant Access Using Hierarchies is disabled (custom objects only). With it unchecked, only the record owner and users granted access through OWD or sharing features see the record — the hierarchy is bypassed entirely.
- The custom object’s access is Controlled by Parent. You can’t disable hierarchy access for a master-detail child whose default access is
Controlled by Parent; the child follows the parent’s sharing. - The user lacks object-level access. Record-level access can never exceed object permissions. If the user’s profile or permission set doesn’t grant Read on the object, no role placement reveals the record — object-level security (OLS) is checked first.
- Access came from a sharing set. Record access granted to users via sharing sets isn’t extended to their superiors in the role hierarchy.
In short: the role hierarchy is a powerful, automatic upward grant on top of a Private baseline — but it’s gated by the Grant Access Using Hierarchies flag and always bounded by the user’s object-level permissions.
Quick Exam Recall
- Private ≠owner-only — Anyone above the owner inherits access when Grant Access Using Hierarchies is on.
- Access flows up only — Managers see subordinates’ records; subordinates never see managers’ by default; peers see neither.
- Standard vs. custom — The setting is always on (and locked) for standard objects, and toggleable only for custom objects.
- OLS is the gate — Object permissions are checked before record access; a role can’t reveal a record the user has no object-level Read on.
Test Your Knowledge
Drill OWD, role hierarchy, and sharing scenarios with exam-style practice questions.
Want the deeper sources? Salesforce documents this behavior in Controlling Access Using the Role Hierarchy, the Trailhead Data Security module, and the Platform Sharing Architecture guide.
Verified against the official Salesforce Summer ’26 Admin & User documentation. The role-hierarchy access mechanic is release-stable. Study smarter at CertifySF.com.