Study guide

Study guide for chapter 13 of the Securing Salesforce: Sharing and Visibility course. Read the six modules first; this page helps you check what stuck.

About this study guide. It’s built only from this course’s own content and the published Salesforce exam guide’s list of objectives. It is never based on real exam questions, and it doesn’t claim to know what’s on the exam. If you’ve taken the exam, please don’t send me questions from it: the certification agreement forbids sharing them, and memorizing answers is the wrong way to become an architect anyway.

This chapter teaches one objective from the exam section Implications of Security Model Choice (18% of the exam): testing the sharing model. The exam guide aligns to Winter ‘23, and some of the tools have arrived since then, so those are in their own list at the end. Know both, and know which date each belongs to.

For the Exam

Tick them off as you go. Each one links to where it’s taught.

Three users (supports IMP-3)

I know why a sharing test needs three users: the owner, a user who should see the record, and one who shouldn’t. (Why three)
I know the null test, and that Private means only the owner and the users above them in the hierarchy. (Start with the null test)
I know to test the side effects: the managers up the hierarchy, the access level, and every door, not just “can see”. (The side effects)
I know which changes rerun the tests: the owner, a user’s role, a new user, and the field a rule shares on. (Test again when something changes)

Test plans (supports IMP-3)

I know to test each subsystem’s permission sets on their own, then each persona as a real user, then the records. (Built in blocks, tested in blocks)
I know to build test users the way real ones are built, and to write the expected result before testing. (Write the plan before you test)

Run-as tests (supports IMP-3)

I know System.runAs works only in test methods, and enforces the user’s sharing and object and field permissions inside the block, whatever the test class’s sharing mode. (The rules worth knowing)
I know a method called inside the block keeps its own class’s sharing mode, that runAs ignores license limits, and that it allows mixed DML in a test. (The rules worth knowing)
I know tests can’t see org data by default, so they create their own users and records, and a permission set group needs Test.calculatePermissionSetGroup. (Build the users the test needs)
I know a run-as test can’t see pages, list views, search or logins. (What run as can’t see)
I know you can’t test criteria-based sharing with Apex, so those rules are tested as real users. (The test plan)

The evidence (supports IMP-3)

I know View Summary on the user shows their permissions, and Access Granted By shows where one comes from. (What can this user do?)
I know the Sharing Hierarchy lists who has access to a record and the reason, and its limits: only access above the default, users a restriction rule blocks, merged reasons. (Who can see this record, and why?)
I know UserRecordAccess answers a user’s access to up to 200 records, ignores restriction rules, and only returns records the person running it can read. (Can this user see these records?)
I know the share table holds rows and row causes, but not the role hierarchy, View All, sharing sets or child access to cases and contacts. (Which rows exist, and why?)

Troubleshooting (supports IMP-3)

I know the order: object permissions, then the org-wide default, then the grants, then what takes access away. (The walk, in order)
I know Controlled by Parent sends you to the parent, and a manual share is lost when the owner changes, by default. (The default and the grants)
I know View All Records and View All Data override sharing but not field-level security. (Can’t see a field)
I know the traps: the parent account behind a case, automation that changes the owner, private contacts and opportunities. (The traps)
I know guest users get access only through guest user sharing rules, and high-volume users through sharing sets and share groups. (External users)

What changed since the exam’s Winter ‘23 alignment (dated, beyond the exam today)

I know that since Summer ‘24, a public group has its own Public Group Access Summary: the sharing rules, list views and folders it’s used in. (Where is this group used?)
I know that since Spring ‘26, role and group changes can be recalculated in the background, so a test that moves a user may need to wait. (What reruns the tests)
I know Salesforce now suggests asking Agentforce in Setup who can see a record and why, and that its answer is checked with the evidence tools. (The evidence)

Beyond the Exam

The exam is the floor, not the ceiling. These are the habits from this chapter that an architect needs, whether or not a question ever asks about them.

Three users, every time. The user who shouldn’t see it is the one who tells you if it’s secure.
Null test first. If nothing is shared and they still see it, find out why before you share anything.
Write the expected result before you log in.
Make the permission set tests part of done, owned by the team that built the subsystem.
Assert what users see, not that code ran or a row exists.
Record the evidence beside each test, with the tool and the date, and check it with a second tool.
Troubleshoot in the same order every time, and end every fix with the three users.
Rerun the plan when owners, roles, rules or users change, and on every release that touches sharing.

Words to Know

Term	In one line
Three users	The owner, a user who should see the record, and a user who shouldn’t
Null test	Proving nobody sees a record before anything is shared
Side effects	Access the share gave beyond the user you meant: managers above, other doors, other requirements
Persona	A kind of user, built from a permission set group and the roles and groups a real one gets
Test plan	A table of checks and expected results, written before anyone tests
Run as	`System.runAs`, which runs part of an Apex test as another user
User Access Summary	View Summary on a user: their permissions, groups and queues in one place
Access Granted By	The action that shows which profile, permission set or group grants a permission
Sharing Hierarchy	The record action that lists who has access and the reason for each
UserRecordAccess	The object you query for a user’s access to a set of records
Public Group Access Summary	View Summary on a public group: where it’s used in sharing
Evidence	What a test recorded to show why a user can or can’t see a record

Check Yourself

Short scenarios in the style of the course. Decide your answer before you open it.

1. A rule shares accounts with the East team. You log in as an East team member and see the accounts. Is it tested?

Half. You’ve proved the positive. Now log in as a user who shouldn’t see them, a West team member, and check they don’t, on the page, in list views, reports and search. And check the side effects: the East member’s manager, and the access level. Reread Why three and The side effects.

2. Before sharing anything, a test user in another department already sees the private records. What now?

Stop and find out why. The null test failed: something else is opening the records, a rule, a team, a role above the owner, or a permission. Any test after this would pass for the wrong reason. Reread Start with the null test.

3. A team changes the Maintenance Read permission set. Which tests do you run again?

That permission set’s own tests, and then every persona whose group includes Maintenance Read. Because the blocks have names, the list is a lookup. Reread What to test again.

4. A run-as test calls a `without sharing` class and the user sees records they shouldn't. Is runAs broken?

No. runAs enforces the user’s sharing in the test, but a method you call keeps its own class’s sharing mode. The test has found what the class really does. Reread The rules worth knowing.

5. You want an Apex test that proves a new criteria-based sharing rule. What do you do?

You can’t: Salesforce says you can’t test criteria-based sharing using Apex. Test the rule as real users, in their own sessions, and record the Sharing Hierarchy’s reason as the evidence. Reread The test plan.

6. UserRecordAccess says a user can read a record, but they get an error opening it. What could it be?

A restriction rule. UserRecordAccess doesn’t consider restriction rules. Check the record’s Sharing Hierarchy: when you click View, it says if a restriction rule blocks the user. Reread Can this user see these records?.

7. A user says they can't see a case. Their object permissions are fine and cases are Controlled by Parent. Where next?

The parent. With Controlled by Parent, start the walk again on the account: its default, its grants, and what takes access away. Reread The default and The traps.

8. An auditor with View All Data says they can't see a salary field. Is that a sharing problem?

No. View All Data opens every record, but it doesn’t override field-level security. Check the user’s Field Permissions in View Summary. Reread Can’t see a field.

9. Someone can see records they shouldn't. Where do you start?

With their permissions: View Summary and Access Granted By, looking for View All Records or View All Data. Then the record’s Sharing Hierarchy, for the reason. Fix the cause, not the user. Reread Can see what they shouldn’t.

10. A test moves a user into a new role and checks their access straight away, and it fails since a recent release. Why?

Since Spring ‘26, role and group changes can be recalculated in the background, so the access may not be there yet. Let the recalculation finish before the check. Reread What reruns the tests.

Explore

Salesforce Certified Platform Sharing and Visibility Architect Exam Guide (opens in a new tab), Salesforce Help (checked 2026-11-07)

The official list of objectives and their weights. Always check the current version before you book an exam.