Salesforce Sharing & Visibility Architect Study Guide (Winter '26)
Your complete guide to passing the Sharing & Visibility Architect exam — OWD design, role hierarchy, sharing rules, Apex sharing, territory management, and performance.
Written and reviewed by Krishna Mohan — ADM-201, PD1, PD2, App Builder & Consultant certified. Updated for Winter '26. Methodology · Contact
Exam Sections & Weightings
What Each Section Tests
Sharing Model Design
Designing the organisation-wide default (OWD) sharing model: Public Read/Write, Public Read Only, Private, Controlled by Parent. Role hierarchy and its implicit sharing. Sharing rules (criteria-based and ownership-based). Manual sharing. Account Teams, Opportunity Teams, and Case Teams for collaborative access.
Programmatic Sharing
Apex Managed Sharing: creating Share objects, assigning access levels (Read, Edit, All), Apex sharing reasons. When declarative sharing is insufficient and programmatic sharing is required. Sharing object naming convention (ObjectName + __Share). Maintaining Apex shares across ownership changes.
Performance & Scalability
Sharing recalculation: when it triggers, impact on system performance, deferral strategy. Ownership skew and its impact on sharing rule calculations. Large sharing groups and their performance implications. Monitoring sharing jobs in Setup. High-volume portal users (HVPU) and their sharing model restrictions.
Territory Management
Enterprise Territory Management: territory hierarchy, territory types, assignment rules. Differences from role hierarchy: territory assignment is non-hierarchical, supports multiple assignments. Account and opportunity access via territories. Territory model states (planning, active, archived). When to use territories vs roles.
Compliance & Field Access
Field-level security (FLS) vs record-level security — understanding that FLS controls field visibility independently of record access. Object permissions: CRUD controls. Profile vs permission set hierarchy for access control. Restriction rules and scoping rules (newer feature to restrict/grant record visibility without sharing recalculation).
10-Week Study Plan
Scenario Strategy Tips
- 1.OWD is the floor: Sharing can only open access above OWD — it can never restrict below it. If a scenario requires restricting access below what OWD would grant, use restriction rules or change the OWD setting itself.
- 2.Apex sharing for complex rules: If a sharing rule scenario cannot be expressed with criteria-based or ownership-based rules (e.g., "share with user who owns the related object two levels up"), the answer is Apex Managed Sharing.
- 3.HVPU vs standard users: High-Volume Portal users do not have a role and cannot be in sharing groups. They use account-based or contact-based access instead. If a question involves high-volume external users, standard sharing rules do not apply.
- 4.Ownership skew degrades performance: When one user owns millions of records and their OWD is Private, sharing recalculation when that user's role changes is extremely slow. The fix is to use a separate integration user profile designed for bulk ownership, or re-architect using Public Read OWD with restriction rules.
Mock Exam Benchmark
Aim for 75%+ on practice exams before scheduling. The sharing model section (35%) is scenario-heavy — you will be given complex multi-user access requirements and must select the most appropriate sharing architecture. Drawing out the access model before selecting an answer helps significantly.
Top 10 Concepts to Review
- All OWD settings and their implications for each standard object
- Role hierarchy: implicit access, hierarchical vs non-hierarchical objects
- Sharing rules: criteria-based vs ownership-based, limitations (no OR conditions)
- Manual sharing: who can create, when it is removed, relationship to OWD
- Apex Managed Sharing: Share objects, access levels, custom sharing reasons
- Sharing recalculation: what triggers it, deferral, performance impact
- Ownership skew: definition, symptoms, and mitigation strategies
- Territory Management vs role hierarchy: when to use each
- Restriction rules: use cases, limitations, comparison to Private OWD
- High-Volume Portal Users: sharing model restrictions, account-based access
Frequently Asked Questions
- What is the Salesforce Sharing & Visibility Architect certification?
- The Sharing & Visibility Architect certification validates expertise in designing record-level security models for complex Salesforce orgs. It covers OWD settings, role hierarchy, sharing rules, manual sharing, Apex Managed Sharing, territory management, and performance implications of each design choice. The exam has 60 questions, ~110-minute time limit, ~68% passing score, and a $400 fee.
- What is the difference between OWD, role hierarchy, and sharing rules?
- OWD (Organisation-Wide Default) sets the baseline record access for all users. Private OWD = users can only see their own records by default. Role hierarchy grants access upward — managers see records of their subordinates. Sharing rules extend access to specific groups of users beyond what OWD and role hierarchy provide. All three work together: OWD is the floor, role hierarchy and sharing rules open access above it.
- What is Apex Managed Sharing and when is it needed?
- Apex Managed Sharing allows Apex code to programmatically insert records into the Share object (e.g., AccountShare, OpportunityShare) to grant specific users or groups access to records. It is needed when declarative sharing rules cannot express the required logic — for example, when access depends on complex business rules, related record data, or dynamic conditions that change frequently. Apex shares are maintained separately from declarative shares and survive sharing recalculation if you use a custom Apex sharing reason.
- What is the difference between territory management and role hierarchy?
- Role hierarchy is a strict hierarchical structure — each user has one role, and managers automatically see subordinates' records. Territory management is a flexible matrix structure — a user can be assigned to multiple territories, and territories can overlap. Territory management is better for complex sales territory models where geographic or industry segmentation doesn't fit neatly into a hierarchy. Both can coexist in the same org.
- What are restriction rules and scoping rules?
- Restriction rules (Winter 2021+) allow you to restrict which records a user can see, even if they would otherwise have access via OWD or sharing. Use case: limit a user to only see their own region's records despite a Public Read/Write OWD. Scoping rules control which records appear in list views, related lists, and lookups for a user. Both avoid performance-costly sharing recalculations by filtering at query time rather than maintaining share records.
What Comes After This Certification?
After this certification, consider: Application Architect, System Architect, or Technical Architect (CTA).
Exam Section Difficulty Heatmap
Which sections are a gimme vs which ones trap confident candidates. Use this to prioritise your final-week revision.
| Exam Section | Difficulty | Study Tip |
|---|---|---|
| Sharing Model | Hard | OWD, role hierarchy, sharing rules, and manual share — order and interaction are key. |
| Visibility and Security | Trap ⚠ | Profiles vs permission sets vs OWD — candidates often choose the wrong layer. |
| Data Access Patterns | Hard | LDV and sharing recalculation — know when sharing is recalculated. |
| Best Practices | Moderate | Security and performance best practices — standard recommendations. |
Difficulty based on analysis of common candidate errors across each exam section.
Ready to Practice?
Test yourself with free Sharing & Visibility Architect practice questions.
Start Free Practice Questions