Lesson 13 of 18 · 5–7 minutes

Opening Access: Role Hierarchy, Sharing Rules, Public Groups & Apex Sharing

After setting OWD, close the gap between the baseline and the access matrix without broadening access for everyone.

Learning sequence · data model first, security layers next

Your focus

Start Your Salesforce Career

FULL · Learn • Apply

Match manager, regional peer and exception requirements to mechanisms.

Learning objective

Select the smallest record-sharing mechanism that fits a business exception.

Before you start

OWD baseline, least privilege, object access and FLS.

Real-world scenario

Accounts are Private. East-region colleagues need Read Only; regional managers need team visibility. A criteria-based rule for Region = East can share to an East public group. Use hierarchy for management access. A changing specialist assignment on a custom onboarding object may justify programmatic sharing if rules or supported teams cannot represent it.

The concept

Role hierarchy supports upward record visibility for managers; peers do not automatically share with each other. Standard objects use hierarchy access; custom objects can disable Grant Access Using Hierarchies. A role is not an object permission. Sharing rules add repeatable owner-based or criteria-based grants to eligible recipients. Public groups organize recipients; membership alone is not an object permission or a record grant. Use Apex sharing for programmatic exceptions when declarative mechanisms do not fit. Plan grant creation, updates and removal. Custom-object Apex sharing reasons help track intent; manual-row-cause shares can disappear on owner transfer. Runtime CRUD/FLS and sharing enforcement in Apex are later topics.

Verify object Read and needed field visibility first. Apply each selected mechanism to the access matrix and test an outsider, a peer and a manager. Re-test group membership and owner changes. These are additive mechanisms to choose from, not mandatory sequential gates or a reason to grant Edit.

Opening access beyond OWD

Teaching order, not a runtime pipeline: use the mechanisms your access matrix needs.

1.OWD
Restrictive baseline.
2.Role hierarchy
Upward management visibility.
3.Sharing rules / public groups
Repeatable grants to defined recipients.
4.Apex sharing
Programmatic exceptions with a managed lifecycle.

OWD connects to Role hierarchy: consider management access
Role hierarchy connects to Sharing rules / public groups: consider peer or cross-team access
Sharing rules / public groups connects to Apex sharing: consider only remaining exceptions

Common mistake

Expecting a role to share automatically with peers, treating public-group membership as a grant, or using Apex before checking declarative options. Sharing cannot compensate for missing object or field permission.

Interview angle

“Give regional colleagues Read but not Edit.” Keep Private OWD, select a suitable rule and recipient group, grant Read Only, then verify that other grants do not already provide Edit.

Pause and apply

Write the East-region rule and three expected-access tests. If a specialist assignment ends, what removes the exceptional share? Who owns that cleanup?

Official references

Reviewed 2026-09-22. Examples are illustrative; no code is executed here.

Key takeaways

Hierarchy serves upward visibility; rules serve repeatable sharing needs.
Groups identify recipients; a mechanism grants the access.
Programmatic exceptions need revocation and owner-change tests.

Practice next

Combine Private OWD, regional recipients and Read Only sharing in one design.

Regional Account Sharing

Reading these lessons does not yet save completion. Challenge results continue to provide assessment evidence.