Study guide
2.3 Advanced Sharing & Scoping Solutions
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.3 Advanced Sharing & Scoping Solutions
Key Takeaways Explain This Topic AI
Manual Sharing allows individual record owners, users higher in the role hierarchy, or users with 'Modify All' to grant Read or Read/Write access to specific users or public groups.
All manual shares on a record are automatically dropped by the platform whenever record ownership is transferred to another user.
Restriction Rules contract record access by filtering records so users only see records matching defined user and record criteria; they apply after OWD, sharing rules, and role hierarchy.
Scoping Rules adjust default record filtering in list views, search, and reports without revoking underlying access or preventing users from opening records.
Opportunity Teams and Case Teams allow collaborative record access with customizable team roles and explicit access levels (Read-Only or Read/Write).
Last updated: October 2026
2.3 Advanced Sharing & Scoping Solutions
While Organization-Wide Defaults, the Role Hierarchy, and Sharing Rules satisfy the vast majority of enterprise record visibility requirements, complex business environments frequently demand more dynamic collaboration and specialized data isolation.
Salesforce addresses these requirements through four advanced architectural capabilities: Manual Sharing , modern Restriction Rules , Scoping Rules , and collaborative Record Teams (Opportunity Teams and Case Teams).
Manual Sharing: Ad-Hoc Peer Collaboration
Manual Sharing gives record owners and authorized supervisors the flexibility to share an individual record with colleagues who would not otherwise have access under OWD or sharing rules.
Who Can Manually Share a Record?
A user can manually share a record only if they meet at least one of the following criteria:
They are the Record Owner .
They are positioned above the record owner in the Role Hierarchy.
They hold "Modify All" object permission for that object.
They hold the system-level "Modify All Data" administrative permission.
Users can manually grant Read Only or Read/Write access to individual users, Public Groups, Roles, or Roles and Subordinates.
The Critical Ownership Transfer Trap
One of the most consequential behaviors tested on the Platform App Builder exam is what happens to manual shares during a record transfer:
Warning
When a record's ownership is transferred to a new user, all existing manual shares on that record are automatically deleted by Salesforce . If a team relied on manual shares for cross-departmental collaboration, those users will abruptly lose access. To preserve long-term collaboration across ownership transfers, app builders should use Opportunity Teams , Case Teams , or Criteria-Based Sharing Rules .
Restriction Rules: Contractive Security Architecture
Traditional Salesforce sharing architecture is strictly additive : every security component (OWD, role hierarchy, sharing rules, manual sharing) expands a user's access pool. However, certain strict regulatory frameworks (such as GDPR, HIPAA, or financial confidentiality standards) require the ability to contract or withhold record access from specific user groups.
Restriction Rules prevent users from seeing records that contain sensitive information. When a restriction rule is applied to a user, the records that they already have read access to (via sharing settings) are filtered so that they can only see records matching specified criteria .
Evaluation Order
Salesforce evaluates Restriction Rules after all standard sharing rules:
First, Salesforce computes the user's accessible records using OWD, the Role Hierarchy, and Sharing Rules.
Next, if a Restriction Rule applies to the user, Salesforce evaluates: Record Criteria == TRUE AND User Criteria == TRUE .
If a record in the accessible pool does not satisfy the criteria, it is hidden from the user. [All Records in System]
- │
- ▼
- [OWD + Hierarchy + Sharing Rules + Teams] ──> (Candidate Accessible Records)
- │
- ▼
- [Restriction Rule Filter]
- │
- ▼
- (Final Visible Records)
- Architectural Rules and Limits for Restriction Rules
Supported Objects : Custom objects, Contracts, Tasks, Events, TimeSheets, and External Objects.
Quantity Limit : You can configure only one active restriction rule per object per user .
Cannot Widen Access : A restriction rule can only reduce visibility. It can never grant access to a record that the user does not already have permission to view via sharing settings.
Administrative Bypass : Restriction rules are bypassed by View All Records/Modify All Records on the object, View All Data/Modify All Data, and system-mode code. Check licenses and object/adapter support before choosing this feature.
Scoping Rules: Directing User Focus Without Restricting Data
In large enterprises with millions of records across global business units, users can easily become overwhelmed by cluttered list views, search results, and sprawling report summaries. Scoping Rules allow administrators to control the default record scope that users see, helping them focus on what is relevant without revoking their underlying security access.
Restriction Rules vs. Scoping Rules
Dimension Restriction Rules Scoping Rules
Primary Purpose Enforce contractive data compliance and security Improve user productivity and reduce interface clutter
Effect on Access Restricts access : Users cannot open, view, or search filtered records Does not restrict access : Users can still access records via direct URLs or global search toggles
Search and Reports Records failing the rule are completely absent Records failing the rule are filtered out by default, but users can expand scope
User Override Users cannot bypass or toggle the rule Users can change the filter scope (e.g., select "Filter by Scope" in reports)
Tip
Remember the fundamental operational rule on the exam: Restriction Rules secure data; Scoping Rules reduce noise. If an audit or legal requirement requires that external contractors cannot see certain records, choose a Restriction Rule. If sales reps want their default search to show only accounts in their division, choose a Scoping Rule.
Collaborative Team Selling: Opportunity Teams
Complex business-to-business (B2B) deals rarely involve a single sales representative. Opportunity Teams (also known as Team Selling) allow opportunity owners to build a cross-functional deal team comprising solution engineers, legal counsel, executive sponsors, and financial analysts.
Capabilities of Opportunity Teams
Predefined Team Roles : Administrators configure custom roles matching organizational structures (e.g., Lead Qualifier, Technical Architect, Executive Sponsor).
Granular Record Access : The opportunity owner can grant each team member Read Only or Read/Write access to the specific opportunity.
Default Opportunity Teams : Users can configure their own Default Opportunity Team in their personal settings. With a single click (or automatically upon opportunity creation), the owner can attach their standard collaborators to new deals.
Opportunity Splits Integration : Opportunity Teams serve as the prerequisite framework for Opportunity Splits , enabling organizations to divide revenue and quota credit across multiple team members.
Case Teams: Coordinated Customer Support
Similar to Opportunity Teams, Case Teams allow customer support organizations to assemble multidisciplinary response units on complex customer service cases.
Key Components of Case Teams
Case Team Roles : Define the function of each member (e.g., Product Specialist, Tier 3 Support, Account Manager) and specify their record access level: Private , Read Only , or Read/Write .
Predefined Case Teams : Administrators can bundle groups of users into Predefined Case Teams. A support supervisor or an automated Case Assignment Rule can attach an entire predefined team to incoming high-priority cases instantly.
Contact Roles on Cases : Unlike Opportunity Teams, Case Teams allow external customer contacts to be added to the team, facilitating notifications and collaboration via Experience Cloud portals.
Official Source Check
Checked October 19, 2026: Restriction rule limitations and bypasses .