Troubleshooting Record Access with Sharing Hierarchy

Why This Topic Matters

One of the most common support tickets an administrator receives sounds like this: "I can see the record, but I can't edit it," or "Why can my colleague see this Opportunity when I can't?" Answering these questions quickly and correctly requires a precise understanding of how Salesforce layers its sharing model. The Salesforce Advanced Administrator exam dedicates a meaningful portion of the Security and Access section to troubleshooting record access, because real-world administrators must diagnose access problems without guessing. If you misconfigure sharing, you either expose sensitive data (a compliance risk) or block users from doing their jobs (a productivity risk). Both are expensive mistakes.

Exam questions in this area are scenario-driven. They describe a user, a record, some configuration details, and ask you to explain the observed behavior or recommend a fix. Success depends on knowing the order in which Salesforce evaluates access and knowing which tools reveal why a user has or lacks access.

What Is the Sharing Hierarchy?

The sharing hierarchy, often called the "layers of record access," is the stack of mechanisms Salesforce uses to determine what a user can see and do with a record. These layers are cumulative and additive: each layer can only open up access beyond the baseline, never restrict it further (with the notable exception of object permissions and field-level security, which act as gates). The layers, from most restrictive baseline to most permissive, are:

1. Organization-Wide Defaults (OWD) – the baseline level of access for records a user does not own. Options are Private, Public Read Only, Public Read/Write, Public Read/Write/Transfer (Leads and Cases only), and Controlled by Parent (for detail objects in master-detail relationships and some standard objects such as Contacts).

2. Role Hierarchy – users higher in the hierarchy automatically gain access to records owned by, or shared with, users below them. This can be disabled for custom objects using the "Grant Access Using Hierarchies" checkbox, but it is always on for standard objects.

3. Sharing Rules – automatic exceptions to OWD that open records to public groups, roles, roles and subordinates, or territories. There are two types: owner-based (based on who owns the record) and criteria-based (based on field values). Sharing rules can grant Read Only or Read/Write, never Full Access or Transfer.

4. Manual Sharing – record owners, users above them in the hierarchy, users with Full Access, and administrators can share individual records through the Sharing button. Manual shares are removed if the record owner changes.

5. Teams – Account Teams, Opportunity Teams, and Case Teams grant record-level access to team members, with configurable access levels per member.

6. Apex Managed Sharing – programmatic sharing written by developers, stored in share objects with a custom reason. Visible to admins in the Sharing detail but only editable through code.

7. Territory Management – an alternative access model for Accounts and related records based on territory assignment rather than role.

Sitting on top of these record-level layers are two object-level gates: profiles and permission sets (object permissions such as Read, Create, Edit, Delete, View All, Modify All) and field-level security. A user with no Read permission on an object will never see its records, no matter how many sharing rules exist. Conversely, View All and Modify All on an object bypass the sharing model entirely for that object, and the system permissions View All Data and Modify All Data bypass sharing across the whole org.

How Record Access Is Actually Evaluated

When a user attempts to view or edit a record, Salesforce effectively asks a series of questions:

Step 1: Does the user have object permission? If the profile or an assigned permission set lacks Read on the object, access stops here. The object does not appear in the user's tab, search, or related lists. If the user needs to edit, Edit permission is required in addition to record-level Read/Write access.

Step 2: Does the user have View All or Modify All? If yes, sharing is irrelevant for that object. This is the first thing to check when a user can see "everything" unexpectedly.

Step 3: Is the user the record owner? Owners have Full Access (read, edit, delete, transfer, share), subject to object permissions. Note that if a queue owns the record, queue members have owner-like access.

Step 4: What does the OWD allow? If the OWD is Public Read/Write, every internal user with object permission can read and edit. If it is Public Read Only, they can read but not edit. If Private, non-owners have no access unless a higher layer grants it.

Step 5: Does the role hierarchy grant access? If the user's role is above the owner's role (and Grant Access Using Hierarchies is enabled), the user inherits the owner's level of access. Users in the same role or in a sibling branch do not receive access through the hierarchy. Users with no role assigned receive nothing from this layer.

Step 6: Do sharing rules, manual shares, teams, Apex sharing, or territories grant access? Salesforce combines all of these and grants the most permissive result. If one sharing rule grants Read Only and a manual share grants Read/Write, the user gets Read/Write.

Step 7: Are there implicit sharing rules in play? Implicit sharing is built into the platform and cannot be turned off. Key examples: access to an Account grants read access to its child Contacts, Opportunities, and Cases (and vice versa, having access to a child record grants read-only access to the parent Account). Also, the "Opportunity Access," "Case Access," and "Contact Access" settings on an Account sharing rule or team membership determine child record access.

Step 8: Is field-level security hiding fields? A user may have full record access but still be unable to see or edit a specific field because FLS makes it hidden or read-only. This is a very common source of "I can see the record but not the field" tickets.

Step 9: Is a Restriction Rule or Scoping Rule involved? Restriction Rules (available on custom objects, Contracts, Events, Tasks, Time Sheets, and Time Sheet Entries) are the one mechanism that can remove access a user would otherwise have through the sharing model. If a user unexpectedly cannot see records they should, check for Restriction Rules.

Special Considerations for External Users

Experience Cloud (community/portal) users have their own OWD, called the External Organization-Wide Defaults. The external default can be the same as or more restrictive than the internal default, never more permissive. External users do not participate in the role hierarchy the same way; instead, they use portal roles (Executive, Manager, User) or Customer Community licenses that rely on sharing sets and share groups. When troubleshooting a partner or customer user's access, always check the external OWD first, then sharing sets, then standard sharing rules targeting the appropriate portal roles or groups.

Troubleshooting Tools You Must Know

The Sharing Button – available on a record's detail page when OWD is more restrictive than Public Read/Write. Click it and then click Expand List (Classic) or view the Sharing Hierarchy (Lightning) to see every user who has access and the reason: Owner, Role, Sharing Rule, Manual Share, Team, Apex Sharing, Territory, or Account Sharing. This is the single most important tool for answering "why does this person have access?"

Sharing Hierarchy – in Lightning Experience, this view (accessed from the Sharing dropdown) displays the user-by-user breakdown of access and the specific reason, including which sharing rule granted it. In Classic, this is accessible through the Sharing button's "Expand List."

Login As – with "Administrators Can Log in as Any User" enabled, you can reproduce the user's experience directly. This is the fastest way to confirm that a reported issue is real and to test a fix.

User Record and Profile/Permission Set Review – verify the user's role, profile, permission sets, permission set groups, and license. Check whether the user is active and whether they belong to any public groups referenced by sharing rules.

Sharing Settings Page – review OWD for the object, the Grant Access Using Hierarchies checkbox, and all sharing rules. Remember to check whether sharing rule recalculation is still running after a recent change; access does not update until recalculation completes.

Setup Audit Trail – shows recent changes to sharing settings, profiles, roles, and permission sets. Invaluable when access "suddenly stopped working."

Record Access Developer Tools – for advanced cases, SOQL against share objects (for example AccountShare, OpportunityShare, or CustomObject__Share) reveals the RowCause for each share record, and the UserRecordAccess object can be queried to check a specific user's access to a specific record.

Common Troubleshooting Scenarios and Their Likely Causes

"User cannot see any records of an object." Check object permission (Read) on profile/permission sets. Check whether the tab is visible. Check OWD Private with no sharing rules reaching the user.

"User can see but cannot edit a record." Either the user lacks Edit object permission, or the sharing layer only grants Read Only (OWD Public Read Only, a Read Only sharing rule, Read Only team access). Also check record locks from approval processes and validation rules, which can mimic access problems.

"Manager cannot see subordinate's records on a custom object." Grant Access Using Hierarchies is likely unchecked for that object.

"User can see too many records." Look for View All or Modify All on the profile or a permission set, View All Data or Modify All Data system permission, an overly broad sharing rule, or an OWD that is more open than intended.

"Access disappeared after the record owner changed." Manual shares are deleted on owner change. Owner-based sharing rules recalculate for the new owner. Team members may be removed depending on settings.

"User in the same role as the owner cannot see the record." This is expected behavior; the role hierarchy grants vertical access only, not peer access. A sharing rule for that role or a public group is required.

"Sharing rule was just created but users still cannot see records." Sharing recalculation may still be in progress, or the users are not actually members of the target group or role.

"User can see the record but a field is missing." Field-level security, page layout assignment, or a dynamic form visibility rule is hiding the field.

"User can see a Contact but not its parent Account's details beyond the name." Implicit sharing grants read access to the Account name only in some cases; full Account access requires the Account's own sharing to allow it.

Exam Tips: Answering Questions on Troubleshooting Record Access with Sharing Hierarchy

Tip 1: Always start at the object level. Before considering sharing rules or role hierarchy, confirm the user's profile or permission set grants the required object permission. Many distractor answers suggest adding a sharing rule when the real problem is a missing Read or Edit permission. Sharing cannot grant what the profile forbids.

Tip 2: Remember that sharing is additive. Salesforce grants the most permissive access across all layers. If a question asks why a user has more access than expected, look for the single most permissive source rather than assuming a conflict. No sharing mechanism except Restriction Rules can take access away.

Tip 3: Know what each layer can and cannot grant. Sharing rules and manual sharing grant Read Only or Read/Write only. They never grant Full Access, delete rights, or transfer rights. Only ownership, role hierarchy above the owner, and Modify All deliver those. If a question says a user needs to delete records they do not own, the answer involves Modify All or ownership, not a sharing rule.

Tip 4: Watch for the Grant Access Using Hierarchies checkbox. Whenever a scenario involves a custom object and a manager who cannot see subordinate records, this checkbox is the prime suspect. It cannot be disabled for standard objects, so if the question involves Accounts or Opportunities, look elsewhere.

Tip 5: The role hierarchy is vertical, not horizontal. Peers in the same role or in different branches do not share records through the hierarchy. The exam loves to describe two sales reps in the same role and ask why one cannot see the other's record. The answer is a sharing rule or team, not a role change.

Tip 6: Identify the right diagnostic tool. If the question asks how to determine why a specific user has access to a specific record, the answer is the Sharing button / Sharing Hierarchy view on that record. If it asks how to reproduce what a user sees, the answer is Login As. If it asks what recently changed, the answer is Setup Audit Trail. Match the tool to the question verb.

Tip 7: Distinguish record access from field access. If the user can open the record but a particular field is missing or grayed out, the problem is field-level security or page layout, not sharing. Do not choose a sharing-related answer for a field-related symptom.

Tip 8: Remember owner-change side effects. Manual shares vanish when the owner changes. If a scenario mentions a recent ownership transfer followed by lost access, that is your answer.

Tip 9: Handle external users separately. Any question mentioning partner users, customer users, or Experience Cloud requires you to think about External OWD, sharing sets, and share groups. The internal role hierarchy does not solve external user access problems.

Tip 10: Consider implicit sharing for Account children. If a user can see an Account but not its Opportunities, check the Opportunity Access level on the relevant sharing rule or team membership. If a user has unexpected read access to an Account, it may come from access to a child Contact, Case, or Opportunity.

Tip 11: Do not forget Restriction Rules. If the scenario says a user has every permission and sharing rule needed but still cannot see certain records, and the object is a custom object or one of the supported standard objects, a Restriction Rule is the likely culprit.

Tip 12: Choose the least-privilege fix. When multiple answers would technically solve the problem, the exam expects the one that grants the minimum necessary access. Prefer a criteria-based sharing rule over opening the OWD; prefer a permission set over editing a profile used by many users; prefer a team over View All.

Tip 13: Eliminate answers that violate platform rules. Any option that proposes a sharing rule granting Full Access, an external OWD more permissive than the internal OWD, or disabling Grant Access Using Hierarchies on a standard object is automatically wrong because those configurations are impossible.

Tip 14: Read for recalculation timing. If the scenario mentions a sharing change made "a few minutes ago" in a large org, the correct explanation may simply be that sharing recalculation has not finished. Salesforce sends an email when it completes.

Quick Reference Summary

Order of evaluation: Object permissions and FLS gate everything → View All / Modify All bypass sharing → Ownership grants Full Access → OWD sets the baseline → Role hierarchy opens vertical access → Sharing rules, manual shares, teams, Apex sharing, and territories add access → Implicit sharing connects Accounts to children → Restriction Rules can subtract access.

Primary diagnostic tool: the Sharing button and Sharing Hierarchy on the record, which shows each user's access and its reason.

Mastering this topic means being able to walk through these layers methodically for any scenario, name the exact cause, and select the most precise, least-privilege remedy. Practice by picking real records in a sandbox, viewing the Sharing Hierarchy, and explaining every line of access you see. That habit translates directly into exam confidence.