Study guide
2.2 Record-Level Sharing Architecture
Salesforce Certified Platform App Builder Exam
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Platform Architecture, Boundaries & Extensions
1.1 Declarative vs. Programmatic Architecture & Limits 1.2 AppExchange Solutions & Package Selection 1.3 Core CRM Standard Objects & Capabilities
2 Chapter 2: Security, Access & Analytics
2.1 Object-Level & Field-Level Security 2.2 Record-Level Sharing Architecture 2.3 Advanced Sharing & Scoping Solutions 2.4 Reports, Custom Report Types & Dynamic Dashboards
3 Chapter 3: Data Model Architecture & Relationships
3.1 Custom Objects & Custom Field Types 3.2 Master-Detail & Lookup Relationships 3.3 Many-to-Many Relationships & Junction Objects 3.4 Schema Builder & Data Architecture Visualization
4 Chapter 4: Data Management & External Integrations
4.1 Field Type Conversions & Data Loss Considerations 4.2 Data Import Wizard vs. Data Loader 4.3 Salesforce Connect, External Objects & Indirect Lookups
5 Chapter 5: Declarative Formulas & Validation Rules
5.1 Cross-Object Formulas & Advanced Formula Functions 5.2 Roll-Up Summary Fields & Calculation Rules 5.3 Validation Rules & Error Handling Strategies
6 Chapter 6: Salesforce Flow Architecture & Design
6.1 Flow Fundamentals & Flow Trigger Types 6.2 Record-Triggered Flows: Fast Field Updates vs. Actions 6.3 Screen Flows & Guided User Interactions 6.4 Flow Execution Architecture, Bulkification & Fault Paths
7 Chapter 7: Complex Automation & Approval Processes
7.1 Multi-Step Approval Processes & Approver Routing 7.2 Approval Actions, Rejections & Record Locking 7.3 Automation Selection Strategy & Legacy Migration Patterns
8 Chapter 8: Lightning App Builder & Page Customization
8.1 Lightning Record, Home & App Pages 8.2 Standard, Custom & AppExchange Lightning Components 8.3 Custom Buttons, Web Links & Quick Actions
9 Chapter 9: Dynamic UI, Record Types & Mobile Experience
9.1 Dynamic Forms & Conditional Component Visibility 9.2 Dynamic Actions & Page Interaction Patterns 9.3 Record Types, Business Processes & Picklist Control 9.4 Salesforce Mobile App Customization & Compact Layouts
10 Chapter 10: Application Lifecycle Management & Sandboxes
10.1 Application Lifecycle Management (ALM) Stages & Governance 10.2 Sandbox Types, Capacity & Refresh Cycles 10.3 Sandbox Strategy for Development, Testing & Training
11 Chapter 11: Deployment Tools & Packaging Strategies
11.1 Inbound & Outbound Change Sets 11.2 Change Set Dependency Tracking & Deployment Sequencing 11.3 Managed vs. Unmanaged Packages & Distribution
12 Current Exam Blueprint, Agentforce & Flow Operations
12.1 Current Exam Facts, Official Weights & Study Mapping 12.2 AgentExchange: Extending an Org with the Agentforce Marketplace 12.3 Agentforce Automation for App Builders 12.4 Flow Approval Processes, Monitoring & Troubleshooting
2.2 Record-Level Sharing Architecture
Key Takeaways Explain This Topic AI
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.
Last updated: October 2026
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.