2.2 Record-Level Sharing Architecture
Key Takeaways
Organization-Wide Defaults (OWD) establish the baseline security posture; custom object OWDs can be set to Private, Public Read Only, or Public Read/Write.
The Role Hierarchy automatically rolls record access up to managerial roles; while mandatory for standard objects, 'Grant Access Using Hierarchies' can be disabled on custom objects.
Sharing Rules expand access beyond the OWD baseline; they can never restrict or contract access below the OWD.
Sharing Rules cannot target individual users directly; targets must be Public Groups, Roles, Roles and Internal Subordinates, or Roles and Subordinates.
Criteria-based sharing rules evaluate record field values (subject to the combined criteria-based and guest-rule allocation (50 per object by default)), while Owner-based sharing rules evaluate record ownership.
2.2 Record-Level Sharing Architecture
Once a user has been granted object-level CRED permissions and field-level visibility, Salesforce evaluates Record-Level Sharing to determine which specific records (rows) in the database that user is permitted to view, edit, or delete.
The overarching philosophy of Salesforce record-level security is opening access from a secure baseline. You configure the baseline access level to be as restrictive as necessary for the most limited user in your organization, and then systematically use declarative sharing mechanisms to expand access to roles, groups, and individuals.
The Record Sharing Pyramid
Salesforce structures record access like an inverted funnel or pyramid, moving from universal baseline controls to granular, exception-based sharing:
- Organization-Wide Defaults (OWD): Sets the default baseline for all records of an object across the entire company.
- Role Hierarchy: Automatically rolls record access up vertical management reporting lines.
- Sharing Rules: Declaratively opens lateral access across roles, territories, and public groups based on ownership or field criteria.
- Manual Sharing and Teams: Allows record owners to grant ad-hoc access to individual collaborators on specific records.
Organization-Wide Defaults (OWD)
Organization-Wide Defaults establish baseline access, while hierarchy, sharing rules, teams, and manual sharing open access. Supported objects can also use Restriction Rules to filter access already granted. Object permissions and administrator overrides remain relevant.
When determining the appropriate OWD for any object, ask the golden architectural question: "Is there at least one user in the organization who should NOT see records of this object?"
- If Yes, the OWD must be set to Private.
- If No, ask: "Is there at least one user who should view but NOT edit records of this object?"
- If Yes, the OWD must be set to Public Read Only.
- If No, the OWD can be set to Public Read/Write.
OWD Setting Definitions
| OWD Setting | Permitted User Capabilities | Applicable Objects |
|---|---|---|
| Private | Only record owners and users higher in the role hierarchy can view and edit records. | Standard and Custom Objects |
| Public Read Only | All internal users can view and report on all records; only owners and managers can edit. | Standard and Custom Objects |
| Public Read/Write | All internal users can view, edit, and report on all records. | Standard and Custom Objects |
| Public Read/Write/Transfer | All internal users can view, edit, and transfer ownership of records. | Leads and Cases only |
| Controlled by Parent | Child records automatically inherit the exact sharing setting and visibility of their master parent. | Detail objects in Master-Detail relationships; Contacts (optional) |
Note
Public Read/Write/Transfer is available exclusively on Leads and Cases. This setting allows customer service representatives and inside sales agents to reassign unassigned queue records without requiring record ownership or administrative super-permissions.
The Role Hierarchy and 'Grant Access Using Hierarchies'
The Role Hierarchy models an organization's management and reporting tree. By default, Salesforce uses the role hierarchy to automatically roll record access upwards: a user positioned at a higher level in the hierarchy inherits the exact same record permissions (Read or Edit) that their subordinates hold on records they own or have shared with them.
For example, if a sales representative owns an Account record with full edit rights, their Regional Sales Manager and the VP of Sales automatically inherit edit access to that same Account record, even if the OWD is Private.
Standard vs. Custom Object Hierarchy Behavior
A critical distinction on the Platform App Builder exam governs whether hierarchy access can be toggled:
- Standard Objects: The "Grant Access Using Hierarchies" setting is permanently enabled and cannot be unchecked. Access to standard objects (Accounts, Contacts, Opportunities, Cases) always rolls up to higher roles.
- Custom Objects: The "Grant Access Using Hierarchies" checkbox is fully configurable. Administrators can deselect this option on any custom object where managerial roll-up is undesirable.
Realistic Exam Scenario: Executive Whistleblower System
Consider an enterprise that builds a custom object named Whistleblower_Report__c to manage sensitive internal ethics complaints. The OWD is set to Private. However, junior HR coordinators submit reports, and executive vice presidents above them in the role hierarchy can view these reports due to default hierarchy inheritance.
To solve this without restructuring the corporate role tree, the app builder simply edits the Sharing Settings for Whistleblower_Report__c and unchecks "Grant Access Using Hierarchies". Once disabled, only the record owner and users explicitly granted access via sharing rules or permission sets can view the records.
Sharing Rules: Owner-Based vs. Criteria-Based
When Organization-Wide Defaults are set to Private or Public Read Only, Sharing Rules allow administrators to make declarative, automatic exceptions to grant lateral access to peers or cross-functional departments.
Owner-Based Sharing Rules
Owner-based sharing rules evaluate who owns the record. They establish rules such as:
- "Share all Opportunities owned by members of the 'US Commercial Sales' Role with the 'US Sales Engineering' Public Group with Read/Write access."
Owner-based sharing rules are ideal for aligning record access with departmental or regional boundaries.
Criteria-Based Sharing Rules
Criteria-based sharing rules evaluate record field values, completely independent of who owns the record. They establish rules such as:
- "Share all Account records where
Industry == 'Government'with the 'Federal Compliance Team' Public Group with Read Only access."
Key constraints on Criteria-Based Sharing Rules:
- An organization can create a maximum of 50 criteria-based sharing rules per object on Enterprise Edition.
- They cannot evaluate encrypted fields, formula fields referencing external objects, or long text area fields.
Guest User Sharing Rules
Salesforce requires dedicated sharing rules to grant unauthenticated public website visitors access to records via Experience Cloud sites. Guest User Sharing Rules must be criteria-based and can grant Read-Only access only; they can never grant Edit or Delete permissions.
Sharing Targets and Cardinal Limitations
Sharing rules can grant access to the following targets:
- Public Groups: Custom groupings of individual users, roles, and other public groups.
- Roles: All users assigned to a specific node in the role hierarchy.
- Roles and Internal Subordinates: All users assigned to a role plus all users in roles below it, excluding external portal or community users.
- Roles and Subordinates: All users assigned to a role and all subordinate roles, including external community members.
Warning
Sharing rules CANNOT share records directly with individual users. If an exam question asks how to share records with a single named employee using a sharing rule, the answer requires creating a Public Group containing that single employee, or utilizing Manual Sharing.
Cloud Kicks has deployed a custom object called Internal_Audit__c to track sensitive workplace investigations. The Organization-Wide Default (OWD) is configured as Private. However, the Director of Internal Audit discovers that regional sales directors can see audit records created by sales managers reporting to them. Company policy strictly dictates that only the record creator and the Internal Audit committee may see audit records. How should the app builder adjust the security model?
Create an Owner-Based Sharing Rule that revokes access from the sales management roles.
Change the Organization-Wide Default of Internal_Audit__c to Controlled by Parent.
Enable Profile-Based Record Locking on Internal_Audit__c so that workplace investigation records remain permanently hidden from every manager sitting above the record creator in the role hierarchy.
Deselect the 'Grant Access Using Hierarchies' checkbox in the Sharing Settings for Internal_Audit__c.
An energy company manages major infrastructure projects using a custom object called Project__c. The OWD is set to Private. Executive leadership requires that whenever a project's Risk_Level__c field is set to 'Critical', the Safety and Compliance team (a Public Group) must immediately receive Read/Write access to the project record, regardless of who owns it. What is the most maintainable declarative solution?
Create a Criteria-Based Sharing Rule on Project__c where Risk_Level__c equals 'Critical', sharing with the Safety and Compliance Public Group as Read/Write.
Create an Owner-Based Sharing Rule on Project__c that shares every project with the Safety and Compliance Role, because owner-based sharing rules recalculate automatically in real time whenever Risk_Level__c is set to 'Critical'.
Build a Record-Triggered Flow that creates a manual share record for each individual safety engineer.
Change the Organization-Wide Default of Project__c to Public Read/Write and apply a Restriction Rule.
An app builder is asked to resolve an issue where European account executives can view accounts owned by North American account executives. The current Organization-Wide Default for Account is set to 'Public Read Only'. The sales director requests a sharing rule to block European reps from accessing North American accounts. What must the app builder explain to the sales director?
A Criteria-Based Sharing Rule can be configured with a negated 'not equal to' operator on the Region field so that European users are actively blocked from viewing North American account records.
Sharing rules can only expand access beyond the baseline; the Account OWD must first be set to Private before using sharing rules to selectively open access.
The role hierarchy must be restructured so European roles are positioned below North American roles.
Account records must be converted to a custom object to enable negative sharing rules.
Sections you finish are checked off in the contents.