Profiles, Permission Sets and Permission Set Groups

תוכן זה אינו זמין עדיין בשפה שלך.

Chapter 3 of Securing Salesforce: Sharing and Visibility, Part 1: The Front Door and the Offices. New to the course? Start with chapter 1.

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

For a long time, the honest answer was “let me get back to you.” You opened the profile, then every permission set, and added it up in your head. This chapter is about building access so that the answer is quick, and so that it stays right as people join, move and leave.

In chapter 1’s building, chapter 2 was the front door. This chapter is the offices: which objects, fields, tabs and apps a user can get into. Which records they see inside comes later, in the file cabinets.

The ideas in this chapter

The profile is one of something. One profile per user, one user license per profile. Keep it light: the door and the defaults. Salesforce cancelled the retirement of permissions on profiles, but its advice is the same: avoid putting permissions there.
Count the doors. You need one profile for each different way in: the license, the door rules and the defaults. Not one for each job title.
Permission sets are building blocks. Size them by task, not by job title. Small, but not too small: split only what’s ever given apart.
Know the kinds and the limits. Custom, standard, from packages, and the hidden one inside every profile. 1,000 you create, 100 per group, dated.
A group is the job. Bundle permission sets by persona. View, normal, power and admin is a good place to start.
Each team ships its permission sets. Every subsystem comes with at least three: read-only, user and admin. A persona’s group is the assembly across subsystems.
The mute button. One muting permission set per group, and it works only inside that group. A nice feature; the groups are the critical part.
No groups inside groups, and groups are calculated. Wait for Updated, and use permission sets, not groups, in Apex tests.
Access can end on its own. An expiring assignment, or a session-based permission set that sleeps until a flow wakes it. The group decides whether it sleeps.
The most powerful access can’t expire. Temporary admin access needs a process, not a feature.
Give access by rule. User access policies replace adding dozens of permission sets by hand. Active policies act only when a user record changes, so catch today’s users up first.
Locks and rings of keys. A permission set asks to open locks; the license decides whether the user holds the key.
Know where to look. The user’s summary, the bundle’s summary, Object Access and the Field Access Summary.

The picture

Here’s the picture the whole chapter is built on. A user has exactly one profile and many permission sets.

Click to enlarge

The rule I give every class fits on one line. If a user can only have one of something, it’s on the profile. If they can have many of something, it’s on a permission set.

The path through this chapter

Seven modules, each standing on its own.

Profiles Today: One of Something. How profiles got out of hand; one profile per user, one license per profile; what still lives on the profile; my old grid checked again, and a full grid of every capability; Minimum Access - Salesforce; how many profiles you need; and moving off the profile.
Permission Sets: Lego Blocks, Not Too Small. By task, not job title; the Lego nightmare; Paul the pilot and the airport planner; whether a permission set should carry a license; the kinds of permission sets; and the limits, dated.
Permission Set Groups: View, Normal, Power and Admin. Paul’s Pilot group; four levels of access; each team ships its permission sets; one page for one person; the mute button; no groups inside groups; and how groups are calculated.
Access That Ends: Expiring and Session-Activated. Covering for a sick office admin; what happens on the date; the access that can’t expire; session-based permission sets; Paul and the runway; and the trap of a sleeping set in an awake group.
Assigning at Scale: User Access Policies. A rule instead of a checklist; manual and active policies; the one-time move off a profile; why active policies wait for a change; and designing the way out.
Licenses, Delegation, and Seeing a User’s Access. Locks and rings of keys; the user licenses you’ll meet; permission set licenses; delegated administration; and where to look when a user can’t see something.
One Grant, Three Ways In: People, Integrations and Agents. Every way in is a user; the integration user, its API-only profile and the apps it may use; as itself or as the person; the agent user, and who may use an employee agent; what the grant opens.

The order is the order you’d build it in. A light profile, then the right-sized blocks, then the bundles, then access that ends, then a rule that gives it all out, with the license underneath the whole time.

Click to enlarge

Then check what stuck with the study guide.

What an architect decides here

How many profiles the org needs, and the one-of-something reason each one exists: a license, a way in, or defaults.
The size of a permission set: one task each, split only where it’s ever given apart.
The personas, and which subsystems and levels each persona’s group assembles.
That every team that builds a subsystem ships its permission sets, at least read-only, user and admin, as part of done.
Where muting is allowed, and when a lot of muting means the permission sets need to be split.
Which temporary access expires, which is session-based, and how admin-level access is granted and removed, since it can’t expire.
Which personas get a user access policy, how today’s users are caught up, and how access is removed when someone leaves a persona.
Which license each kind of user gets, before anyone builds a permission set.
Who can hand out access: the central team, delegated admins, and partner admins, and what each one can’t do.
How support answers “I can’t see it,” from the user down to the field.

Beyond the exam: what AI changes. Two things. Making a permission set now takes one sentence to the Setup agent, so the Lego nightmare can arrive faster; the sizing rule is still yours. And agents log in too. Give each kind of agent a light profile for the door, its own permission set group, and access that ends when the task is done. Then “what can it do?” has the same one-page answer as for a person. Chapter 20 goes further.

Explore

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

Permissions in Profiles Retirement Cancelled (opens in a new tab), Salesforce Help (checked 2026-11-01)
Guidelines for Creating Permission Sets and Permission Set Groups (opens in a new tab), Salesforce Help (checked 2026-11-01)

Next: Object and Field Security: What Users Can Touch