Prove the Positive and the Negative

Module 1 of 6 in the chapter Testing the Security Model, chapter 13 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: You’ve built a sharing rule. How do you prove it gives the right people access, and nobody else?

Most people test sharing once. They log in as the person who should see the record, they see it, and they call it done. That’s half a test.

In chapter 1 I gave you my habit: three users. In chapter 4 we used it on one field. This module grows it into a way to prove a whole sharing requirement: every user it touches, every action, every door, and what happens when something changes.

Why three

You need three users in order to really do a good test. In class I put it this way: one to own, one to share, and then, what are the side effects?

• The owner, or the administrator who sets it up. The record is theirs; they’ll see it whatever you do.
• The user you’re sharing with. They prove the positive: the share works.
• The user you’re not sharing with. They prove the negative: the share didn’t go further than you meant.

Two users can only prove the positive. It’s the third user who tells you whether it’s secure.

Start with the null test

Before you share anything, prove that nothing is shared. In my class demo, I set accounts to Private, then logged in as two users, Alpha and Beta, each in their own browser session: one in an incognito window, one in a second browser, so each keeps its own login. Then I asked the room: as Alpha, how many accounts will I see? Guess before I click. The answer is none. That’s the null test.

Why does it matter? Because Private means something precise: “Only the record owner, and users above that role in the hierarchy, can view, edit, and report on those records” (Organization-Wide Default Access Settings (opens in a new tab), Salesforce Help, checked 2026-11-07). If Alpha already sees accounts before you’ve shared a thing, something else is opening them: a rule, a team, a role above the owner, a permission. Your test would pass for the wrong reason.

Then share one account with Alpha, and refresh both. Alpha sees it. Beta still sees nothing. You’ve proved the positive and the negative. And while I do it, I watch the account share table: before the share, one count; after it, one more row, with its row cause. Delete the share, and the count goes back. The row is the evidence (where to look).

Click to enlarge

The side effects

The demo shows one share. A real requirement has more around it, and those are the side effects you test for.

Up the hierarchy. When I set accounts to Private in class, I asked who could still see them. The owner, someone said. And anybody above them in the hierarchy. That’s the side effect most people forget. Share a record with a user, and their manager may see it too, if Grant Access Using Hierarchies is on for that object. So test the manager of the user you shared with, and the manager of the user you didn’t: one should see it, one shouldn’t.

The access level. Seeing a record isn’t the whole answer. Did you mean Read Only or Read/Write? Open the record as the positive user and try to edit it. Try to delete it, and to change its owner. A test that only checks “can see” misses a share that gives too much.

Every door. A user who can’t open a record on its page shouldn’t find it anywhere else. As the negative user, look for it in a list view, a report and global search. That’s chapter 4’s bleed checklist, used on a record instead of a field.

The second requirement. A share you add for one reason can open a door for another. If the record was meant to be confidential to one team, test a user from every other team that might reach it, not just one.

Test again when something changes

A sharing model that passes on day one can fail on day ten, because sharing moves when people and records move. The course has shown you the changes that matter. Each one is a test to run again:

• The owner changes. Manual shares go, unless the org keeps them; team members and sharing reasons of your own behave differently (What survives an owner change).
• A user changes role or joins. Rules and the hierarchy recalculate, and code needs its trigger on the user (the user trigger).
• The record changes. A criteria-based rule shares on a field value. Change the value, and the share should come or go.

So the three users aren’t a one-time check. They’re a script you run on day one, and again every time one of these happens.

Test knowledge. Know why testing sharing needs three users: the owner, a user who should see the record, and one who shouldn’t. Know the null test, that Private means only the owner and the users above them in the hierarchy, and that a share can reach the managers above the user it’s shared with. Know to test the access level and every door, not just “can see”. A likely area, not a known question.

What an architect decides here

• For each sharing requirement, the three users, written down: the owner, who should see it, and who shouldn’t.
• The managers to test above each of them, for objects that grant access through the hierarchy.
• The access level each user should have, and the actions to try: view, edit, delete, transfer.
• The doors to check as the negative user: the page, list views, reports and search.
• Which changes rerun the tests: owner changes, role changes, new users and field values that rules share on.

Beyond the exam: what AI changes. An agent is one more user, so it gets the same three-user test. Ask it as a user who should see a record, and as one who shouldn’t, and compare the answers. A negative test for an agent is a question it should refuse or answer without the record. And because an agent answers in sentences, check that the record isn’t in the answer in a summary, a count or a name. Chapter 20 covers agents.

Explore

• Organization-Wide Default Access Settings (opens in a new tab), Salesforce Help (checked 2026-11-07)