How to Pass the Salesforce Sharing and Visibility Architect Exam

The first time I sat down with a real Sharing and Visibility Architect practice scenario, I read a paragraph about a customer community, a role hierarchy, and a few million records, picked the answer that felt clean, and got it wrong. Not because I didn't know sharing. Because I answered the question I wanted to see instead of the one on the screen.

That is the whole exam, honestly. The Salesforce Certified Platform Sharing and Visibility Architect exam is not testing whether you can define an OWD. It is testing whether you can read a dense, deliberately noisy scenario, find the one constraint that eliminates half the options, and pick the architecturally correct answer over the merely workable one. If you have passed the Admin or Platform Developer exams, some of that muscle memory will actively hurt you here.

This is a concept-by-concept map of where people trip, what actually fixes it, and how to rehearse before you spend $400.

The exam facts, verified

Let's get the logistics straight so you are not studying for the wrong test.

• Official name: Salesforce Certified Platform Sharing and Visibility Architect (it used to be the Sharing and Visibility Designer).
• 60 scored questions, plus up to 5 unscored ones you can't identify.
• 120 minutes.
• Passing score is 67%, which is roughly 41 of 60 scored questions correct.
• $400 USD to register, $200 for a retake.
• Formats are multiple-choice and multiple-select (the "choose 2" and "choose 3" ones).
• Proctored, either at a test center or online.
• No hard prerequisite, but Salesforce suggests roughly 2 to 3 years on the platform and 1 to 2 years focused on security and sharing.

One thing worth knowing for motivation: this credential is active, it is not on Salesforce's 2027 retirement list, and it is a stepping stone toward Application Architect, System Architect, and eventually CTA. It is a keeper.

The domain weightings tell you where to spend your hours:

• Access to Records: 39%.
• Permissions to Standard/Custom Objects and Fields: 27%.
• Access to Other Data (reports, dashboards, folders, list views, files, Chatter): 21%.
• Implications of Security Model Choice (large data volumes, performance, licensing): 13%.

Access to Records is nearly 40% of the exam. If your study time isn't weighted the same way, rebalance it now. And as you work through the traps below, keep our free Sharing and Visibility Architect practice exam open in another tab: every one of them shows up there in scenario form, which is the only way this material really sticks.

The traps, one at a time

Here is where the debriefs all converge. Same concepts, same mistakes, over and over.

Skew: ownership, account, and lookup

Ownership data skew is when a single user or queue owns more than about 10,000 records on one object. Think integration users, catch-all API profiles, or a lead-routing user quietly owning millions of Leads. Every time that owner moves in the role hierarchy, or a related sharing rule changes, Salesforce synchronously recalculates sharing for all those records. Lock contention. Timeouts.

The trap answer is "adjust the OWD" or "grant more permissions." Wrong. The fix is to distribute ownership and remove the skewed user from the role hierarchy entirely. A user outside the hierarchy doesn't trigger those cascading recalculations.

Account data skew is the parent-side cousin: one Account owns hundreds of thousands of child records. Salesforce locks the parent Account during child DML to keep roll-ups and sharing consistent, so heavy concurrent child writes throw UNABLE_TO_LOCK_ROW. The fix is a data-model change: spread those children across multiple or regional parent Accounts.

Lookup skew is when a huge share of child records all point at the same parent through a lookup, slowing queries and saves. Same theme: too many things hanging off one record.

The theme: skew is a data distribution problem, and the answer is almost never a sharing setting.

Deferred sharing calculation vs. granular locking

These two get swapped constantly, and the exam knows it.

Deferred sharing calculation is for one-time bulk events: a legacy CRM migration, an annual territory realignment, a merger, a big role hierarchy rewrite. You suspend recalculation during the operation, then resume and process it in one batch instead of triggering a cascade on every single insert.

Granular locking is for ongoing high concurrency. By default Salesforce locks the entire group-membership table when you update a Public Group, Queue, or Role. Granular locking lets it lock only the affected parts, so multiple admins can edit groups at once without total gridlock.

The tell: "one-time load" or "migration" points to deferred. "Multiple admins" or "concurrent updates" points to granular locking. Read for that word.

Apex sharing keywords

This one bites developers who think they already know it.

• with sharing enforces the running user's record-level access. It does not enforce field-level security or object (CRUD) permissions. People forget that second sentence and lose points.
• without sharing runs in system context and ignores record-level sharing. It's for background automation that legitimately needs everything.
• inherited sharing is the recommended secure default for reusable utility classes. The class inherits the mode of whoever called it, so it doesn't break a system batch job that needs full access, and it doesn't accidentally leak data when a UI component calls it.

And because with sharing alone doesn't cover fields, enforcing FLS and CRUD means Schema describe methods, stripInaccessible, or WITH SECURITY_ENFORCED in your SOQL. The architecturally clean pattern for a Lightning Web Component controller is with sharing for records plus WITH SECURITY_ENFORCED for fields.

Apex managed sharing vs. manual sharing

Manual sharing is a declarative one-off grant, and it gets silently dropped when the record owner changes. That's the gotcha the exam builds whole questions around.

Apex managed sharing uses a custom Apex sharing reason and survives an owner change. So when a scenario says "the access must persist even if ownership changes," that's your signal.

For dynamic access driven by a many-to-many junction object (grant when a user is added to the junction, revoke when they're removed), the right pattern is an Apex trigger on the junction that inserts or deletes rows in the target __Share table. Criteria-based sharing rules read fields on the record itself and can't see related junction records, so they're the wrong tool here even though they look tempting.

Communities, Sharing Sets, and Share Groups

External users are a whole separate rulebook, and it's a favorite exam trap.

High-volume Customer Community licenses do not support the role hierarchy (it's a performance protection). That single fact removes role-based access, standard sharing rules, and manual sharing from the table for those users. When you see "Customer Community license," cross those options out immediately.

So how do those users get access? Sharing Sets, which map a lookup on the community user's Contact or Account to a field on the target record (for example, access to every Case tied to their Account). Share Groups extend a Sharing Set's access to other internal or external users. And Partner Community users can get Super User access to see records owned by others in their role or below.

Internal vs. external OWD

You can set the internal org-wide default more permissive than the external one. Classic scenario: internal staff must see all records, external partners must not see each other's. The answer is Default Internal Access = Public Read Only, Default External Access = Private. No trigger, no sharing rule. People overbuild this one.

Implicit sharing

So many "why can this user see this record?" questions are just implicit sharing, not a misconfiguration.

Grant a user access to a child record (Opportunity, Case, Contact) and they get implicit Read on the parent Account. And an Account owner implicitly gets access to child records owned by other people on that Account. Learn these two directions cold; they defuse a surprising number of trick questions.

Role hierarchy vs. lateral access

The role hierarchy grants vertical access, up the management chain. It does not grant lateral access across unrelated departments. When a scenario needs, say, auditors across several departments to read all Opportunities over $1M, the declarative answer is a Public Group plus a criteria-based sharing rule on the Amount field.

And for ad-hoc lateral sharing, remember Account, Opportunity, and Case Teams, which also help you dodge the limit of 300 sharing rules per object.

Why this exam feels different

Where Admin and Developer exams ask "what does this feature do," this one buries the question inside a noisy paragraph of org structure, license limits, and performance symptoms. The wording is the whole game, and constraint keywords steer the answer:

• "Customer Community license" removes role hierarchy and sharing rules.
• "Millions of records" signals a performance answer: defer, granular locking, or skew.
• "Must survive an owner change" signals Apex managed sharing.
• "Only when a field is populated" signals a criteria-based rule.
• "Across related objects" signals Apex.

And the multiple-select questions are sneaky: they'll offer four technically workable options and ask for the two that are architecturally optimal and scalable. The house rule is that declarative beats code unless scale, complexity, or security forces code.

Resources that work, and ones that waste your time

What passers actually use:

• Focus on Force is the most-recommended resource, precisely because it explains why the wrong answers are wrong architecturally, which is exactly the skill the exam grades.
• The official Trailhead "Architect Journey: Sharing and Visibility" trailmix is the baseline. But reading is not enough. Spin up a Developer Edition org and actually build a role hierarchy, a Sharing Set, and an Apex managed share. Then watch a manual share vanish when you change the owner. That one experiment teaches more than a chapter of notes.
• Timed, scenario-style practice exams build the reading stamina you need for 120 dense minutes.

What to skip: generic Udemy architect packs are often outdated, and exam dumps are unreliable and against Salesforce policy. The exam constantly tweaks the license and volume constraints, which is exactly what dump-memorizers miss. You can't memorize your way past a constraint you didn't notice.

A timeline and exam-day tactics

If you're an experienced admin who already works with enterprise sharing, plan 6 to 8 weeks. If you're a developer light on declarative security, plan 10 to 12 weeks. Get hands-on early instead of saving the org-building for the end.

On exam day:

• Read for the limiting constraint first, then evaluate options against it, instead of reading top to bottom and getting seduced by the first plausible answer.
• Sketch box-and-arrow diagrams of the role hierarchy and record ownership on scratch paper for each scenario. Passers swear this stops inheritance mistakes.
• Bank time. Knock out easy recall questions in 30 to 45 seconds so you have room for the dense ones.
• Flag and move on when a scenario overwhelms you. Come back with a clearer head.

Rehearse before you book

The single best predictor I've seen: people who consistently score above 85% on timed practice exams before booking tend to walk in calm and walk out passed. Not because 85% is the passing line (it's 67%), but because hitting it repeatedly means you've stopped guessing and started reading for constraints.

So do the rehearsal. We built a free Sharing and Visibility Architect practice exam for exactly this. Run it timed, treat every miss as a debrief, and don't book the real one until you're clearing 85% on a bad day.

That is the same habit we bring to building at Bridge GPT: rehearse against real constraints, and don't ship (or book) until the plan survives contact with reality. Read the constraint first. Everything else follows.

Good luck. Go draw some boxes and arrows.