Skip to content
SteveTechArcSteveTechArc Courses

Testing the Security Model

Chapter 13 of Securing Salesforce: Sharing and Visibility, Part 2: The File Cabinets: Sharing Records. New to the course? Start with chapter 1.

Chapters 6 to 12 built the file cabinets: who owns what, who sits above them, the rules, the teams, the code, and the data that isn’t a record. This chapter asks the question every one of them leaves open. How do you know it works?

Most people test sharing once, as the person who should see the record. That’s half a test. A sharing model is only as good as the proof that it works, for the people who should see a record and, more important, for the people who shouldn’t.

The ideas in this chapter

Section titled “The ideas in this chapter”
  • Three users. One to own, one to share, and the side effects. Two users only prove the positive; the third tells you if it’s secure.
  • Start with the null test. Prove that nothing is shared before you share anything.
  • Test the blocks, then the people. Each team’s permission sets at each level, then each persona’s assembled group as a real user, then the records.
  • Write the expected result first. If you write it after you test, you’ll write down whatever happened.
  • Keep the proof running. Run-as tests prove what each user sees, in code, on every deployment.
  • Evidence answers why. View Summary, the Sharing Hierarchy, UserRecordAccess and the share table, each with something it doesn’t show.
  • Troubleshoot in order. The object, the default, the grants, then what takes access away.
  • Prove the fix, and test again when the owner, a role or a rule changes.

The picture

Section titled “The picture”

Here’s where the chapter starts: one sharing requirement, tested properly.

A test for one sharing requirement A test for one sharing requirement. The null test, before anything is shared: the users who shouldn't see the record see nothing; if they do, something else is already open. The positive: the user it's shared with sees it, at the access level you meant, read or edit. The negative: the user it isn't shared with still sees nothing, on the page, in list views, reports and search. The side effects: the owner's manager, up the role hierarchy, and anyone else the share reached; then test again after a change. Footnote: two users only prove the positive; the third tells you if it's secure. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-SVA-TA-01", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} The null test before anything is shared Users who shouldn't see it see nothing If they do, something else is open The positive the user it's shared with Sees the record At the level you meant: read or edit The negative the user it isn't shared with Still sees nothing Not in list views, reports or search The side effects everyone else it reached The managers up the hierarchy Test again after a change Two users only prove the positive. The third tells you if it's secure. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

And here’s how you show your work: four questions, four places to look, and what each one misses.

Four questions, four places to look Four questions, four places to look. What can this user do: View Summary on the user, with Access Granted By on any permission; it doesn't show records. Who can see this record, and why: the Sharing Hierarchy, with a reason for each user; it doesn't list users who only have the org-wide default, and it can list users a restriction rule blocks. Can this user see these records: a UserRecordAccess query, up to 200 records; it ignores restriction rules and only returns records the person running it can read. Which rows exist, and why: the share table and its row causes; the role hierarchy, View All, sharing sets and child access to cases and contacts aren't rows. Footnote: no one tool tells the whole story; check each answer with a second one. {"author": "Steve Simpson", "blueprint": "1.0.0", "builder": "standard 1.58.0", "built": "2026-11-04", "id": "DGM-SVA-TA-04", "rights": "\u00a9 2026 Twinshark LLC. All rights reserved.", "template": "comparison 0.5.0", "theme": "stevetecharc 1.4.0"} What can this user do? View Summary on the user Object, user and field permissions Access Granted By on any permission Misses: which records Who can see this record? the Sharing Hierarchy Each user and the reason Misses: access from the default alone Can list users a restriction rule blocks Can this user see these? a UserRecordAccess query Read, edit, delete, up to 200 records Misses: restriction rules Only returns what the runner can read Which rows exist? the share table Rows and their row causes Misses: hierarchy, View All, sharing sets No row doesn't prove no access No one tool tells the whole story. Check each answer with a second one. © 2026 Twinshark LLC · stevetecharc.com
Click to enlarge

The path through this chapter

Section titled “The path through this chapter”

Six modules, each standing on its own.

  1. Three Users: Prove the Positive and the Negative. Why three; the null test; the side effects up the hierarchy, the access level and every door; what to test again when something changes.
  2. Persona Test Plans: Test the Permission Sets, Then the People. Each subsystem’s permission sets at each level; each persona as a real user; the plan as a table, with the expected result written first.
  3. Run As in Apex Tests: Keep the Proof Running. What runAs enforces and what it doesn’t; building test users; the three users in code; what a run-as test can’t see.
  4. The Evidence: Who Can See It, and Why. View Summary and Access Granted By; the Sharing Hierarchy and its reasons; UserRecordAccess; the share table; the Public Group Access Summary.
  5. Why Can’t This User See the Record?. Salesforce’s troubleshooting path in four steps; the other direction; fields; the traps; external users.
  6. Checkpoint 2: Build It, Then Prove It. Steve Trucking’s internal model finished with a rule per partner, manifests shared in a flow, and files on their records, then proved persona by persona. Try the challenge first.

Then check what stuck with the study guide.

What an architect decides here

Section titled “What an architect decides here”
  • For each sharing requirement, the three users, written down, with the managers above them and the doors to check.
  • For each subsystem, the permission set tests its team ships, and for each persona, a test user built like a real one.
  • The test plan: its rows, the expected results, who signs off, and where it lives.
  • Which code and flows have run-as tests, for the user who should see and the user who shouldn’t, on both doors.
  • The evidence each test records, and which second tool confirms it.
  • The troubleshooting order the team follows, and that every fix ends with the three users.
  • What reruns the tests: owner changes, role changes, new users, new rules, and every release that touches sharing.

Beyond the exam: what AI changes. An agent is one more user, so it gets the same three users, the same row in the test plan and the same evidence. And Salesforce now suggests asking the Setup agent who can see a record and why. Use it to find the answer faster, then check it with the evidence tools before it goes in the plan. An answer from an agent is a claim; the test and the evidence are the proof. Chapter 20 covers agents.

Explore

Section titled “Explore”

Each module lists its own sources, each checked 2026-11-07. Two to start with:

Next: External Users: Sites, Communities, Licenses and Roles (coming soon)

Follow Me

© 2023–2026 Twinshark LLC. All rights reserved. · Content Use

Privacy notice

SteveTechArc is independent and is not affiliated with, sponsored by, or endorsed by Salesforce, Inc. Salesforce and related marks are trademarks of Salesforce, Inc.

Educational content, shared as is. Not professional, legal or financial advice. Salesforce changes several times a year, so check current Salesforce documentation before you rely on any platform detail.