View, Normal, Power and Admin

Module 3 of 7 in the chapter Profiles, Permission Sets and Permission Set Groups, chapter 3 of Securing Salesforce: Sharing and Visibility. Each module stands on its own.

The question this module answers: How do you bundle permission sets into one thing per kind of user, how do you take a permission away, and what do you need to know about how groups are calculated?

Let me start with the question I most want you to be able to answer about any user. What can this person do?

With a profile and a pile of permission sets, the honest answer is often “let me get back to you.” You open the profile, then each permission set, and you add it up in your head. Module 2 called that the Lego nightmare. Permission set groups are how you get the answer back on one page.

A group is the job

A permission set is one task. A permission set group is a bundle of tasks, and Salesforce says what to bundle by: “Use a permission set group to bundle permission sets together based on user job personas or roles.” Users assigned the group “receive the combined permissions of all the permission sets in the group.” A permission set can be in more than one group, and when you change the permission set, the change reaches every group that includes it (Permission Set Groups (opens in a new tab), Salesforce Help, checked 2026-11-01).

So a job title, the thing that used to be a profile, becomes a group. The tasks inside it stay small and reusable.

Back to Paul. Paul is a pilot, and in module 2 we built two permission sets: View Airports and View Navigational Aids. Now we make a Pilot group with both, and assign Paul the group. Paul’s profile is a light Staff Pilot profile, cloned from Minimum Access - Salesforce, which only says how pilots get in. Everything Paul can do comes from the group.

The group also gives you room to grow. When pilots need their training records, you build a permission set for that task and add it to the Pilot group. Every pilot has it the next time the group is calculated, and nobody’s profile changes.

Click to enlarge

View, normal, power and admin

How many levels? I usually think there are three or four levels of access to any area of work. View only. A normal user. A power user. And administration. So I think view, normal, power and admin.

Take the airline’s flight operations. Someone in finance needs to view flights and run reports on them. A dispatcher or a pilot is a normal user: they work their own flights every day. A chief pilot is a power user: they change many records at once and see across the whole fleet. And someone administers the area: they set it up and keep it running. Four levels for one area. At a minimum, three: view, normal and admin. Power when the area needs it.

That’s not a Salesforce rule. It’s a shape I’ve found works. Some areas only need two levels; a very sensitive one might need five. But if you start there, you’ll find most of your levels quickly, and you’ll notice when someone asks for a fifth that’s really a person, not a level.

Click to enlarge

Each team ships its permission sets

Here’s where those levels come from in a real org. When a team builds an application or a subsystem, a couple of objects, their screens, maybe an integration, it should also build the permission sets for it. At a minimum, I expect three for every subsystem: a read-only one for the lowest level, one for the typical user, and one for the admin of that subsystem. A fourth, for power users, when the subsystem needs it.

So the team that builds flight operations delivers Flight Operations Read, Flight Operations User and Flight Operations Admin, along with its objects and screens. The team that builds maintenance delivers Maintenance Read, User and Admin. In Paul’s airline, View Airports is exactly this: the read-only permission set of the airports subsystem. Nobody has to work out the access later from a pile of objects, because the people who built the objects already said who should use them and how.

Then a user is an assembly. A pilot’s group isn’t built from scratch. It’s assembled across the subsystems a pilot works in: Flight Operations User, Maintenance Read, Crew Scheduling User. A maintenance supervisor’s group takes Maintenance Admin and Flight Operations Read. Each subsystem’s levels are the blocks; each persona’s group is the assembly across them. That fits the two levels Salesforce gives you, more on that below in No groups inside groups: the group is the job, and the permission sets are the areas and tasks.

This buys you two things. When the flight operations team adds a field, it decides in the same release which of its permission sets gets it, and every group that includes them picks it up. And when someone asks what a pilot can do in maintenance, the answer is one name: Maintenance Read.

So make it part of done. A subsystem isn’t finished until its permission sets are.

Click to enlarge

One page for one person

This is where the group earns its place. On a permission set group, the Combined permissions section is “a centralized view of all the permissions included in permission sets that make up your permission set group,” and View Summary on the group’s detail page shows its object, user, field and custom permissions (Permission Set Groups and Combined Permissions View (opens in a new tab), Salesforce Help, checked 2026-11-01).

So the question “what can this person who has this group do?” has one place to look. Know the one catch: the combined view “doesn’t reflect permissions that were muted or permission changes that don’t have an updated status” (same page). The next two sections explain both.

The mute button

Here’s the part people like. Sometimes a group is almost right. The pilots need everything in their permission sets except one administrative field, File Name, that only the operations team uses. Before groups, you’d clone the whole permission set to remove one field, and now you have two that drift apart.

Instead, you press mute. Like watching TV: you don’t turn it off, you mute it. A muting permission set sits inside the group and turns off selected permissions for the group’s members. It was the first time Salesforce gave us removal; everything else adds.

The rules, in Salesforce’s words (Muting Permission Sets (opens in a new tab), Salesforce Help, checked 2026-11-01):

• “You can have up to one muting permission set per permission set group.” You can mute object, field and user permissions and other access settings.
• The muting “affects only users assigned to the permission set group.” If the same user gets the same permission “via a profile, permission set, or different permission set group, the user still has these permissions despite the muting permission set.”
• It’s also useful for managed packages: when a package update adds a field you’re not ready to give out, you can mute it in the group and still take the update.

Muting reaches further than the one checkbox. Muting Read on an object also mutes Create, Edit, Delete, View All Records and Modify All Records, and muting Edit on Orders also mutes the Activate Orders permission that depends on it (Permission Set Group Muting Dependencies (opens in a new tab), Salesforce Help, checked 2026-11-01). Read the confirmation message when you save.

And one trap for deployments: “muting permission sets are not currently supported in change sets.” Deploy a group with a change set and its muting permission set stays behind, so you rebuild it by hand in the target org (Muting Permission Sets Are Not Included in Salesforce Change Sets (opens in a new tab), Salesforce Help, published 2025-12-24, checked 2026-11-01).

So how much should you use it? I think of muting as a nice feature, not a critical one. It’s a negative permission, and it only works inside its group. The groups are the critical part. If you find yourself muting a lot, the permission sets underneath are probably too big. Module 2 is about that.

No groups inside groups

Here’s something I wish Salesforce had built. I’d have loved a super group: one group for a person’s job title, made of groups for each area of work, made of permission sets, made of the individual switches. Three levels above the switches.

You can’t do that. A permission set group’s definition holds its permission sets and one muting permission set, and nothing else: no other group (PermissionSetGroup (opens in a new tab), Metadata API Developer Guide, Winter ‘27, API version 68.0, checked 2026-11-01). I understand why. Working out a user’s access at runtime would get much harder with groups inside groups. So permission set groups are good, but not great.

What it means for design: you have two levels, so use them well. The group is the job. The permission sets are the areas and tasks. The permissions inside them are the switches. If a person does two jobs, assign two groups. Don’t build a third group that copies both.

Click to enlarge

Groups are calculated

A group isn’t read live from its permission sets. Salesforce calculates its combined permissions and stores the result. “Whenever you add, delete, or edit a custom permission set in a permission set group, a calculation is applied,” and users keep “the combined permissions available in the group as of the last completed calculation.” Changes to Salesforce’s own standard permission sets in a group are calculated daily (Permission Set Group Status and Recalculation (opens in a new tab), Salesforce Help, checked 2026-11-01).

Each group shows a status:

• Updated: the combined permissions are current. You can assign users and edit the group.
• Outdated: the change is captured and waiting. You can edit the group, but you can’t change who’s assigned, and the users don’t have the change yet.
• Updating: it’s recalculating. You can’t assign users or edit the group until it’s done.
• Failed: the recalculation failed, and users don’t have the latest permissions. Check what was added most recently; an expired managed package can also cause it. There’s a Recalculate button on the group’s detail page.

That explains something a student once hit in my class: editing several permission sets in one group, one after another, quickly, and getting an error. The group was still updating from the first change, and while it’s updating, you can’t edit it. Wait for Updated.

Recalculation can take “from seconds to hours for large or complicated updates.” It’s slower with many permission sets in the group, complex permission sets, many assigned users, many changes at once, other work running at the same time such as deployments and Apex tests, and, from module 2, “permission sets without a required license” (same page).

Two rules for anyone who deploys:

• An update to a group during the deployment phase triggers a recalculation. Salesforce suggests adding permission sets and user assignments to groups in your test phase instead (Permission Set Group Considerations (opens in a new tab), Salesforce Help, checked 2026-11-01).
• In Apex tests, give test users permission sets, not groups. A group can be recalculating when you deploy your Apex code, “in which case the test users aren’t assigned the permissions included in the permission set groups” (same page).

Why Salesforce wants you to use groups

Groups aren’t only tidier. Salesforce recommends them for performance: “For better performance, we recommend assigning users permission set groups instead of many individual permission sets,” especially when many users have the same several permission sets. A group holds up to 100 permission sets, and a permission set in a group can still be assigned on its own when one person needs just that task (same page). Module 2 has the org-wide limits.

Two more kinds come later. A group can be session-based, so it’s off until something switches it on, and a session-based permission set put inside an ordinary group doesn’t need activation at all. Module 4 covers both. And user access policies, which assign groups automatically, are module 5.

What an architect decides here

• The personas: which kinds of users get a group, and which subsystems and levels each group assembles.
• That every team that builds a subsystem also ships its permission sets, at least read-only, user and admin, as part of done.
• That every group is built from task-sized permission sets, and that a person with two jobs gets two groups, not a copy.
• Where muting is allowed, and the point at which a lot of muting means the permission sets need to be split.
• How groups and their muting permission sets are deployed, given that change sets leave muting permission sets behind.
• Who watches group status after a deployment, and what happens when one fails.
• That Apex tests assign permission sets, not groups.

Beyond the exam: what AI changes. An agent is a persona too. Give each kind of agent its own permission set group, built from the same small permission sets, with nothing extra. Then the question you most need to answer about an agent, “what can it do?”, has the same one-page answer as for a person: the group’s combined view. Part 3 of this course covers agents.

Explore

• Permission Set Groups (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Muting Permission Sets (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Permission Set Group Muting Dependencies (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Permission Set Group Status and Recalculation (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Permission Set Group Considerations (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Permission Set Groups and Combined Permissions View (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Muting Permission Sets Are Not Included in Salesforce Change Sets (opens in a new tab), Salesforce Help (checked 2026-11-01)
• PermissionSetGroup (opens in a new tab), Metadata API Developer Guide (checked 2026-11-01)