How Salesforce Computes Record Access: Explicit, Implicit, Inherited & Group Grants

💬 In plain words: Record access in Salesforce is calculated through specific grant types stored inside share tables. These fall into four distinct categories: explicit grants (rules, manual shares, Apex), implicit grants (parent-child relationship linkages), inherited grants (role hierarchy rollups), and group-membership grants (public groups and queues). Understanding these grant types makes access calculations clear and simplifies debugging.

📌 Example: If a user can view a parent Account without owning it or receiving a manual share, check related records. If they own an open Case under that Account, Salesforce automatically grants implicit read access to the parent record.

🎬 Real-Life Example: Auditing Unexpected Record Access

A manager asks why a team member can view a confidential Delivery__c record that was never explicitly shared with them.

The Wrong Way: Checking user profiles and permission sets for hours. Profiles and permission sets manage object-level and field-level security, not individual record access.

The Right Way:

• Work through the grant hierarchy: Is the user the record owner? Are they above the owner in the role hierarchy?
• Check for sharing rules targeting public groups the user belongs to, manual shares, or team assignments.
• Inspect the parent record for implicit access triggers.
• Open the record's Sharing Hierarchy page to view the exact RowCause for the grant.

The Outcome: Record access is always driven by stored grant rows. Locating the row reveals the cause and solution.

Understanding the Four Access Grant Types

When Org-Wide Defaults (OWD) are set to Private or Public Read Only, Salesforce calculates record access dynamically using four grant types:

Access Grant Classification (OWD Private / Read-Only)
├── Explicit ──────── direct record assignment (Manual, Sharing Rule, Apex, Teams)
├── Implicit ──────── system-managed relationship access (Parent Account → Child Case/Opp)
├── Inherited ─────── role and territory hierarchy evaluation (Manager → Subordinates)
└── Group-Membership ─ group assignments (Public Group, Role, Queue) inheriting group shares

• Explicit Grants: Direct access assignments stored on individual record share tables (such as AccountShare or CustomObject__Share). These include manual shares, criteria/owner-based sharing rules, Account Teams, and Apex managed sharing.
• Implicit Grants: Access inferred automatically from parent-child object relationships. For instance, access to a child Case or Contact automatically grants implicit read access to the parent Account.
• Inherited Grants: Access that rolls upward through the role hierarchy or territory hierarchy. When "Grant Access Using Hierarchies" is enabled, managers automatically inherit the access rights of their subordinates.
• Group-Membership Grants: Indirect access inherited by users who belong to public groups, roles, or queues. Assigning a user to a group automatically grants them access to all records shared with that group.

🧠 The E-I-I-G Access Rule
Record Access = Explicit + Implicit + Inherited + Group-Membership Grants

🧭 360 Card — Access Grant Taxonomy (E-I-I-G)

• Rule: Record access is calculated using four grant categories: Explicit, Implicit, Inherited, and Group-Membership.
• Benefit: Establishes a structured debugging framework for auditing record visibility.
• Trade-Off: Share tables store explicit grants directly, while implicit and inherited access are computed dynamically.
• Limits: When OWD is Public Read/Write, access rules are not evaluated. Turning off hierarchy access is supported only for custom objects.
• Admin Override: Object-level permissions like View All and Modify All Data bypass share table calculations entirely.

Core Q&A

Q: A user can see an Account record that was never manually shared with them. How could this access have been granted?

🎯 Core Summary: Evaluate the four grant types sequentially—Explicit, Implicit, Inherited, and Group-Membership—to determine how access was inherited.

A: Record visibility is granted through one of four core mechanisms:

• Explicit: Created via a sharing rule, an Account Team assignment, or an Apex managed share targeting the user or their role.
• Implicit: Granted automatically because the user has access to a related child record, such as a Case, Contact, or Opportunity linked to the Account.
• Inherited: Derived because the user occupies a higher position in the role hierarchy above the record owner.
• Group-Membership: Inherited because the record was shared with a public group or queue that includes the user as a member.

Scenario-Based Follow-Ups

Q1: Adding a user to a public group suddenly grants them access to thousands of records. What explains this?

A1: Group-membership grants. When a user joins a group, they instantly inherit all active and historical explicit shares assigned to that group via sharing rules or manual shares. Group assignments should be managed carefully, as adding a single member can instantly grant access to large volumes of records.

Q2: Why does making an Org-Wide Default (OWD) more restrictive fail to hide records from a manager?

A2: Inherited grants via the role hierarchy. The "Grant Access Using Hierarchies" setting ensures managers inherit the access rights of their subordinates regardless of how restrictive OWD settings are for peers. Disabling hierarchy-based access is supported only on custom objects.

Q3: An OWD is set to Private, but a service agent can still access restricted records. How do you debug this?

A3: Open the record's Sharing Hierarchy page to inspect active share rows and their assigned RowCause. Additionally, audit the user's object-level permissions for administrative overrides like View All or View All Data granted through permission sets.

Q4: How should a complex enterprise sharing model be documented?

A4: Create a comprehensive sharing matrix that maps objects against user personas. Each cell should define the access level (None, Read, Edit) and document the underlying mechanism (such as OWD, Sharing Rules, or Role Hierarchy). Store this document alongside your repository metadata and update it with every release.

⚠ Developer Warning: Share table queries only show explicit share records. Implicit and hierarchy-based access are computed at runtime and will not appear as rows in the share table.