2.3 Advanced Sharing & Scoping Solutions
Key Takeaways
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).
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 == TRUEANDUser 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.
Ursa Major Solar hires third-party audit contractors to review contract records. Organization-Wide Defaults for Contracts are set to Public Read Only so sales teams can review contract terms. However, regulatory compliance mandates that external audit contractors must strictly have visibility into Contracts explicitly marked with Audit_Status__c = 'Assigned to External'. How can an app builder enforce this strict boundary without breaking visibility for internal sales users?
Create an Owner-Based Sharing Rule that shares assigned contracts with external contractors.
Configure a Scoping Rule on Contract that hides restricted records from contractor list views, report results, record detail pages, and all inbound API queries whenever Audit_Status__c is not 'Assigned to External'.
Implement a Restriction Rule on the Contract object targeting the contractor profile where Audit_Status__c = 'Assigned to External'.
Set up an Opportunity Team on all related deals to grant contractors conditional access.
Support supervisors at a telecommunications provider need to assemble cross-functional escalation groups consisting of a Tier 2 Engineer, a Network Architect, and a Customer Success Liaison for high-severity customer outages. These team members need explicit Read/Write access to the Case record, and supervisors want to add the entire pre-configured group in a single click. Which feature should the app builder configure?
Manual Sharing rules configured with a predefined Public Group.
Criteria-Based Sharing Rules based on Case Severity and Priority.
Opportunity Teams enabled on the customer Account record with predefined Opportunity Team Roles that grant Read/Write access to every related Case.
Case Teams with Predefined Case Teams and designated Case Team Roles.
A senior enterprise sales representative manually shares 15 confidential Opportunity records with an external financial consultant, granting Read Only access. The following month, the sales representative leaves the company, and the system administrator transfers ownership of all the representative's accounts and opportunities to a new account executive. What happens to the financial consultant's access to the manually shared opportunities?
The financial consultant loses access immediately because manual shares are automatically deleted upon ownership transfer.
The financial consultant retains access because manual shares remain attached to the record until manually revoked.
The financial consultant's Read Only access is automatically upgraded to Read/Write because manual shares always inherit the sharing settings of the incoming owner whenever record ownership is transferred between internal users.
The financial consultant retains access only if they are positioned above the new owner in the role hierarchy.
Sections you finish are checked off in the contents.