Test the Permission Sets, Then the People

Module 2 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: Your org has dozens of personas and a hundred permission sets. Which do you test, and as whom?

Module 1 proved one sharing requirement with three users. A real org has many requirements, many personas, and permission sets coming from every team that builds something. You can’t test every person against every record. You need a plan, and the plan follows how the access was built.

Built in blocks, tested in blocks

In chapter 3 I gave you my rule: each team ships its permission sets. When a team builds a subsystem, it delivers at least three permission sets with it: a read-only one for the lowest level, one for the typical user, and one for the admin of that subsystem. Then each persona is an assembly: a pilot’s group takes Flight Operations User, Maintenance Read and Crew Scheduling User.

Testing follows the same shape. Test each subsystem’s permission sets at each level. Then test each persona’s assembled group as a real user. Two layers, in that order.

Click to enlarge

Layer 1: each permission set, at each level

Start small. For every subsystem, take each of its permission sets on its own and test what it lets a user do.

Read: the user can open the subsystem’s objects and see its fields. They can’t create, edit or delete. Try each one.
User: they can create and edit what the typical user works on. They still can’t do the admin’s tasks.
Admin: they can do everything the subsystem’s admin needs, and nothing outside the subsystem.

Use a test user with nothing else: a minimum-access base, plus the one permission set. That way, anything the user can do comes from the permission set you’re testing. Then check the paper answer as well: View Summary on the permission set shows “all object, user, field, and custom permissions that are enabled” (Seeing a user’s access). The summary tells you what it says; the test user tells you what it does.

This layer belongs to the team that built the subsystem. They know what Maintenance Read should allow, so they write the tests with the permission sets, and a subsystem isn’t finished until both pass.

Layer 2: each persona, as a real user

Then test the people. For each persona, build a test user the way a real one is built: the persona’s permission set group, plus the role, public groups and queues a real one gets. If your org assigns access with a user access policy, let the policy build the test user too. Then the test proves what a new pilot will really get on day one, not what you remembered to assign.

Now test as that user. This layer catches what the first one can’t:

The blocks together. Each permission set passed on its own. Does the assembly still work, or does one block need an object another block forgot?
What’s muted. A group can mute a permission inside it (the mute button). Check the muted permission is really gone for the persona.
The records. Permission sets open objects. Sharing opens records. So for each sharing requirement the persona is part of, run module 1’s three users, with this persona as the one who should see, or the one who shouldn’t.

Write the plan before you test

A test plan is a table, written before anyone logs in. One row per thing to check, and the answer you expect:

Persona	Check	Expected
Pilot	Open a maintenance record	Can view; can’t edit
Pilot	Create a crew schedule	Can create
Pilot	See another region’s flights	Can’t see
Maintenance Supervisor	Edit a maintenance record	Can edit
Maintenance Supervisor	Delete a flight	Can’t delete

Write the expected column first. If you write it after you test, you’ll write down whatever happened. The expected column comes from the design: the requirements, the permission sets each team shipped, and the sharing model. When a result doesn’t match, either the build is wrong or the design is, and both are worth knowing before go-live.

What to test again

The two layers also tell you what to test again after a change, and that’s where building in blocks pays off.

A team changes a permission set. Rerun that permission set’s tests in layer 1. Then rerun every persona whose group includes it, in layer 2. Because the blocks have names, the list of personas is a lookup, not a guess.
A persona’s group changes. Rerun that persona’s layer 2 tests.
A sharing rule or the hierarchy changes. Rerun module 1’s three users for every requirement the change touches, for every persona in them.

Test knowledge. Know that testing should cover both permissions and sharing: permission sets and groups decide what a user can do with objects and fields, and sharing decides which records. Know to test with users built like real ones, and to test the negative as well as the positive. A likely area, not a known question.

What an architect decides here

That every subsystem ships its permission set tests with its permission sets, and who in each team owns them.
The list of personas to test, and one test user for each, built the way real users are built.
The test plan’s rows and expected results, and who signs off on them.
Which tests run again after each kind of change: a permission set, a persona’s group, a sharing rule or the hierarchy.
Where the plan lives, so the next team can run it again.

Beyond the exam: what AI changes. Agents are personas too, and they should be assembled the same way: from the subsystems’ permission sets, with nothing extra. So give each agent’s user a row in the plan, with the same expected results as the persona it works for, or fewer. And add a check people don’t need: ask the agent for something its persona shouldn’t have, and expect it not to get it. Chapter 20 covers agents.

Explore

Every platform fact in this module is cited from the chapter 3 module that checked it:

Permission Set Groups, chapter 3 module 3
User Access Policies, chapter 3 module 5
Licenses and Seeing Access, chapter 3 module 6