Salesforce Platform Sharing and Visibility Architect Practice Exam
Prepare for the architect-level security exam across all four domains — permissions to objects and fields, access to records, access to other data, and the implications of security model choice. Scenario questions, instant feedback in Learn mode, a full timed simulation in Exam mode, and every explanation linked to Salesforce’s own documentation.
Start 24-hour free trial →Sharing and Visibility Architect exam at a glance
- Vendor
- Salesforce
- Credential
- Salesforce Certified Platform Sharing and Visibility Architect
- Exam code
- None — Salesforce uses named credentials
- Level
- Architect (advanced)
- Questions
- 60 scored multiple-choice/multiple-select (plus up to 5 unscored)
- Duration
- Approximately 105 minutes
- Passing score
- Approximately 67% (confirm on Salesforce)
- Cost
- $400 USD registration; $200 USD retake
- Recommended experience
- 2–3 years on the Salesforce platform designing security/sharing models
- Part of
- Prerequisite for the Application Architect credential; on the B2B Solution Architect / CTA path
Source: Salesforce Trailhead — Platform Sharing and Visibility Architect credential and the official exam guide. Confirm current details before scheduling.
About the Sharing and Visibility Architect certification
The Salesforce Certified Platform Sharing and Visibility Architect credential validates your ability to design secure, scalable data-access models on the Salesforce platform — from object- and field-level permissions through org-wide defaults, role hierarchy, sharing rules, teams, territories, and programmatic Apex sharing. It’s an advanced, architect-level exam aimed at people who translate complex security requirements into maintainable technical designs for orgs with thousands of users and strict data-isolation needs.
The exam is heavily scenario-based: you’re given a business situation — a financial-services org that must keep Accounts private but roll visibility up to managers, a healthcare org using territory management, a 50,000-user org whose sharing recalculation runs for 24 hours — and asked which combination of mechanisms produces the right access with the least risk. Its defining challenge is the interaction of mechanisms: how OWD, role hierarchy, sharing rules, manual sharing, implicit sharing, and Apex sharing combine to determine one user’s effective access. It’s also a gateway credential — a prerequisite for the Application Architect designation and part of the path toward Certified Technical Architect. PowerKram maps each question to one of the four exam domains and links every explanation to Salesforce’s own documentation. For where this sits in the Salesforce ecosystem, see our Salesforce definitive guide.
Exam domains and weighting
Salesforce’s exam guide organizes the exam into four domains. Access to Records dominates at 39% — the sharing model itself — so OWD, role hierarchy, sharing rules, and Apex sharing deserve the deepest study. Confirm the current weighting on Salesforce’s exam guide, which can change between versions.
The sharing model: organization-wide defaults, role hierarchy and Grant Access Using Hierarchies, ownership- and criteria-based sharing rules, manual sharing, teams, territory management, implicit sharing, and Apex managed sharing.
Object-level (CRUD) and field-level security via profiles and permission sets, record types and page layouts as UI-level controls, and balancing least-privilege access with usability.
Access controls for data that isn’t standard/custom object records — folders, reports and dashboards, content and files, Chatter, Knowledge, and access for external and guest users.
Designing for maintainability and large data volumes, license limitations that constrain sharing solutions, sharing recalculation and performance, and validating and unit-testing the sharing model.
Source: Salesforce Platform Sharing and Visibility Architect exam guide (Access to Records 39%, Permissions to Objects & Fields 27%, Access to Other Data 21%, Implications of Security Model Choice 13%). Confirm the current weighting on Salesforce’s guide.
Who this exam is for
It’s an advanced credential for people who own Salesforce security and sharing design:
- Technical and solution architects designing enterprise-scale access models.
- Advanced administrators managing complex sharing across large, regulated orgs.
- Senior developers implementing Apex managed sharing and custom sharing logic.
- Security and compliance leads translating regulatory requirements into platform controls.
It pairs naturally with the Identity and Access Management Architect credential (authentication and identity, alongside this exam’s authorization focus) and the Data Architect credential, and it’s a stepping stone on the B2B Solution Architect path. Advanced admins often reach it after Platform Administrator II. For the roles this credential supports, see the solution architect career guide.
What this practice exam delivers
Score by domain
Every question is tagged to one of the four exam domains — permissions, access to records, access to other data, security-model implications — so your report shows exactly where to focus, with the heavyweight Access to Records domain front and center.
Learn mode
Immediate feedback after each question with a full explanation of why the right design is right and the others wrong — built for the “which mechanism, and why not the others” reasoning the architect exam demands.
Exam mode
A timed run that mirrors the 60-question format and the ~67% bar, so pacing feels familiar on test day.
Source-linked explanations
Every answer links to Salesforce’s own documentation for the topic — so you learn OWD, sharing rules, FLS, and Apex sharing from the source, not just a memorized letter.
Sample Sharing and Visibility Architect practice questions
Ten free scenario questions across the four domains, each with a full explanation and a source link to Salesforce documentation. The complete bank is available with the 24-hour trial.
A financial services company has set the OWD for the Account object to Private. Sales reps should see only their own Accounts, but managers should see all Accounts owned by their subordinates.
Which setting ensures managers have the appropriate access?
- Create a criteria-based sharing rule that shares records up the hierarchy
- Verify that ‘Grant Access Using Hierarchies’ is enabled for the Account object
- Create a sharing rule for managers to access subordinates’ records
- Assign a permission set with ‘View All’ on Accounts to managers
Show answer & explanation
Correct: B. ‘Grant Access Using Hierarchies’ automatically gives users in higher roles access to records owned by lower roles — the built-in mechanism for manager rollup, enabled by default for standard objects.
Why not the others: a sharing rule (C) is redundant with hierarchy access; criteria-based rules (A) can’t dynamically target “up the hierarchy”; and a ‘View All’ permission set (D) is overly broad, exposing every Account, not just subordinates’.
Source: Salesforce Trailhead — Control Access to Records → Further reading: PowerKram — Identity & Access Architect →A company needs to share Opportunity records with a cross-functional review committee that changes quarterly, granting read/write access to all Opportunities over $1 million.
What sharing mechanism should the architect implement?
- Manual sharing by each Opportunity owner
- A permission set with object-level read/write access
- A criteria-based sharing rule granting read/write to a public group containing committee members
- An Apex sharing class that runs quarterly
Show answer & explanation
Correct: C. A criteria-based sharing rule automatically shares records matching the criteria (amount > $1M) with a public group, and updating group membership each quarter handles the changing committee — declarative and low-maintenance.
Why not the others: manual sharing (A) doesn’t scale; a permission set (B) can’t restrict to a criterion like amount; and an Apex sharing class (D) adds code maintenance for something declarative handles.
Source: Salesforce Trailhead — Create Sharing Rules →A healthcare company using Enterprise Territory Management needs clinical reps to see only patient records in their territory, while regional directors see records across all territories in their region.
How should the architect configure this?
- Implement Apex managed sharing with territory logic
- Create separate profiles for each territory
- Use sharing rules based on a territory field
- Set OWD to Private, enable territory-based access, and use the territory hierarchy for rollup visibility
Show answer & explanation
Correct: D. Enterprise Territory Management integrates with the sharing model: a Private OWD plus territory assignments and the territory hierarchy grant reps their territory and roll access up to regional directors automatically.
Why not the others: profiles (B) don’t control record-level access; territory-field sharing rules (C) are far less maintainable than native territory management; and Apex sharing (A) adds complexity for something the platform does natively.
Source: Salesforce Trailhead — Control Access to Records →A security audit reveals that 5,000 Account records are manually shared with ‘All Internal Users’, bypassing the Private OWD.
What should the sharing architect do?
- Change the OWD to Public Read Only
- Delete the All Internal Users public group
- Hide the sharing button from all page layouts
- Remove the manual sharing records in bulk programmatically, and implement properly scoped sharing rules for the access that is actually needed
Show answer & explanation
Correct: D. The over-broad manual shares should be removed in bulk and replaced with sharing rules scoped to the real requirement — restoring the intent of the Private OWD without surrendering security.
Why not the others: changing OWD to Public (A) abandons the security model; ‘All Internal Users’ (B) is a system group that can’t be deleted; and hiding the sharing button (C) prevents new shares but leaves the 5,000 existing ones in place.
Source: Salesforce Trailhead — Create Sharing Rules →A large enterprise with 50,000 users experiences sharing recalculation taking over 24 hours after adding a new sharing rule.
What should the architect recommend to reduce recalculation impact?
- Switch all OWD to Public Read/Write
- Replace sharing rules with Apex managed sharing
- Flatten the role hierarchy
- Defer activation to off-hours and optimize group membership and role-hierarchy depth
Show answer & explanation
Correct: D. Scheduling recalculation for off-hours (deferred sharing maintenance) and reducing group-membership and role-hierarchy complexity cut the computation the platform must perform — the standard large-data-volume approach.
Why not the others: Public Read/Write (A) eliminates security; Apex managed sharing (B) has its own recalculation cost; and flattening the hierarchy (C) is impractical and breaks legitimate rollup.
Source: Salesforce Trailhead — Data Security module → Further reading: PowerKram — Enterprise Architect career →A consulting company wants Contact records related to an Account to be visible to anyone who has access to the Account.
Which setting controls this behavior?
- Set the Contact OWD to ‘Controlled by Parent’
- Set the Contact OWD to Public Read Only
- Create a sharing rule to share Contacts with Account viewers
- Enable a lookup sharing setting on the Contact-Account relationship
Show answer & explanation
Correct: A. ‘Controlled by Parent’ makes the child Contact inherit the parent Account’s sharing, so anyone with Account access gets matching access to its Contacts — exactly the requirement.
Why not the others: Public Read Only (B) is too broad; a separate sharing rule (C) adds needless complexity; and there is no “lookup sharing setting” (D) on the relationship.
Source: Salesforce Trailhead — Control Access to Objects →A pharmaceutical company needs field-level restrictions: sales reps can see ‘Prescription Volume’ but must not see ‘Compliance Notes’ on the same page layout.
How should the architect enforce this?
- Create two different page layouts
- Use Dynamic Forms with a visibility rule
- Configure field-level security to hide Compliance Notes for the sales rep profile
- Remove the field from the sales rep record type
Show answer & explanation
Correct: C. Field-level security is enforced everywhere — UI, API, reports, and SOQL — so hiding Compliance Notes via FLS for the rep profile is the only control that truly restricts access, not just the display.
Why not the others: page layouts (A) remove a field visually but not via API; record types (D) don’t control field visibility; and Dynamic Forms (B) respect FLS but aren’t the security control themselves — FLS is the primary enforcement.
Source: Salesforce Trailhead — Control Access to Fields → Further reading: PowerKram — Platform Administrator II →A company has an Apex managed sharing reason ‘Project_Team_Share’ that grants Project record access. Users report intermittent access issues when added to new project teams.
What is the most likely cause?
- The sharing reason is not configured correctly
- The Apex sharing is being overridden by a more restrictive sharing rule
- The group-membership cache has not yet refreshed after the users were added
- The Apex sharing records are inserted in a future method that has not completed
Show answer & explanation
Correct: C. Salesforce caches group-membership calculations, so there can be a short delay between adding users to a group and the sharing model reflecting it — producing exactly this intermittent, timing-related access pattern.
Why not the others: a misconfigured reason (A) would fail consistently, not intermittently; sharing rules and Apex shares are cumulative, not overriding (B); and Apex share inserts are synchronous unless deliberately coded as future (D).
Source: Salesforce Trailhead — Data Security module →An architect is designing the sharing model for a custom ‘Claim’ object. Claims adjusters see only their claims, team leads see all claims in their team, and executives see all claims.
What OWD and sharing model should the architect implement?
- OWD Public Read Only with role hierarchy for write access
- OWD Private, role hierarchy for team-lead visibility, and ‘View All’ on Claims for executives
- OWD Private, role hierarchy for team-lead visibility, and ‘View All Data’ for executives
- OWD Public Read/Write with field-level security for sensitive fields
Show answer & explanation
Correct: B. Private OWD limits adjusters to their own claims, role hierarchy grants team leads visibility to their team, and object-level ‘View All’ on Claims gives executives read access to all claims — without the dangerous org-wide ‘View All Data’ system permission.
Why not the others: ‘View All Data’ (C) is far too broad, exposing every object; Public Read Only (A) lets adjusters see others’ claims; and Public Read/Write (D) abandons record isolation.
Source: Salesforce Trailhead — Control Access to Objects → Further reading: PowerKram — B2B Solution Architect →A company relies on implicit sharing through Account relationships. A user with Account access can see related Contacts but should not see related Opportunities.
How should the architect restrict Opportunity visibility?
- Set Opportunity OWD to Private and disable Grant Access Using Hierarchies
- Change Opportunity OWD from Controlled by Parent to Private
- Create a restriction rule on the Opportunity object
- Verify the Opportunity OWD is Private and review any sharing rules or other mechanisms granting broader access
Show answer & explanation
Correct: D. Opportunity has its own independent OWD (it is not ‘Controlled by Parent’), and implicit sharing already grants some Account-based access. The right move is to confirm the OWD is Private and audit the sharing rules and other mechanisms that might be widening access.
Why not the others: Opportunity isn’t ‘Controlled by Parent’, so (B) describes a state that doesn’t exist; disabling Grant Access Using Hierarchies (A) breaks legitimate manager rollup; and a restriction rule (C) isn’t the primary control for this implicit-sharing scenario.
Source: Salesforce Trailhead — Overview of Data Security → Further reading: PowerKram — Solution Architect career →Keep going: study guides and career paths
Sharing and Visibility Architect is a gateway credential on the Salesforce architect track. Two PowerKram hubs back this exam.
Deep dive: where the exam concentrates, the mechanism interactions, and a study plan
Where the exam sits and what it costs
This is an advanced, architect-level credential: 60 scored questions (plus up to five unscored) in roughly 105 minutes, with an approximate 67% pass mark, registered at $400 with a $200 retake, proctored onsite or online. Salesforce recommends two to three years of platform experience designing security and sharing. It’s a prerequisite for the Application Architect designation and a building block toward Certified Technical Architect, which is part of why it carries weight beyond the sharing topic itself. Salesforce can revise details, so confirm on the exam guide. Pair with Identity & Access Architect →
Where the exam concentrates
Access to Records is the dominant domain at 39% — the sharing model itself — so that is where most candidates win or lose. Know OWD settings and their downstream effects, Grant Access Using Hierarchies, ownership- vs criteria-based sharing rules, manual sharing, teams, territory management, implicit sharing, and Apex managed sharing. Permissions to Objects and Fields (27%) covers CRUD and FLS via profiles and permission sets. The remaining two domains — Access to Other Data (21%) and Implications of Security Model Choice (13%) — cover non-record data (reports, content, Chatter, external users) and the design trade-offs of maintainability, license limits, and recalculation performance.
The recurring theme: mechanism interaction
The signature difficulty is that access is cumulative: OWD sets the floor, and role hierarchy, sharing rules, manual shares, teams, and Apex shares each only ever grant more access, never less. Questions frequently present a scenario where several mechanisms interact — a Private OWD with implicit sharing, a criteria rule plus a permission set, an Apex share plus a group-membership delay — and ask you to reason about the effective result. Draw the model out: OWD, then each grant on top of it. Distinguishing ‘View All’ (object) from ‘View All Data’ (system) and understanding ‘Controlled by Parent’ are common exam traps.
Realistic study plan
Follow the Architect Journey: Sharing and Visibility trail and, above all, build. In a Developer org, create a complex model with multiple roles, criteria-based sharing rules, teams, and Apex managed sharing, then test access from several user perspectives — the diagnostic experience is what the exam rewards. Front-load Access to Records, then round out permissions, other-data access, and security-model implications. Use PowerKram Learn mode with the sourced documentation links to close gaps, then finish in Exam mode across all four domains under time. Architect career paths →
Frequently asked questions about the Sharing and Visibility Architect exam
What is the exam format and passing score?
What domains does the exam cover, and which is heaviest?
Is this exam a prerequisite for other Salesforce certifications?
What experience is recommended?
What's the single hardest part of the exam?
Start your free 24-hour Sharing and Visibility Architect practice trial
Full access to 1,800+ questions across all four domains, both study modes, and source-linked explanations. No credit card required.
Start free trial →