One of Something

Module 1 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: What is a Salesforce profile for today, what still has to live on it, and how many profiles does an org really need?

Let me ask you a question. How many profiles does your org have?

When I ask that in a class, I get answers like 12, 40, and once, at a large telecom company, about 200. Then I ask the next question: how many of those profiles exist only because one team needed one extra checkbox?

That’s the story of the profile. For a long time it was where everything went, and that’s exactly why it got out of hand.

How profiles got out of hand

In the early days of Salesforce, the profile was the main way to say what a user could do. It held how they logged in, and it held what they could do once they were in: which apps, tabs, objects and fields, which page layouts, which permissions. Everything.

The trouble is that a profile is one per user. So when the sales team in one region needed one extra permission, you couldn’t add it to just those people. You cloned the profile. Then another team needed something slightly different, and you cloned it again. That’s profile proliferation: many profiles that are almost the same, each one created for a specific circumstance, and nobody quite sure anymore what the differences are.

Then Salesforce gave us permission sets. A permission set is a group of capabilities you can add to a user on top of their profile, and a user can have many of them. That changed the question. Instead of “which profile is this person?”, it became “what’s the smallest profile this person needs, and which permission sets do they add?”

I’ll be honest: I always wished I could add permission sets to a profile, so the profile could carry them for everyone who has it. Salesforce didn’t go that way. You add permission sets to users. So the design work moved. The profile got lighter, and the building blocks moved into permission sets and permission set groups, which the rest of this chapter covers.

One profile per user, one license per profile

Two facts about the profile shape everything else.

First, every user has exactly one profile. They can have many permission sets and permission set groups, but only one profile. That’s why the profile is the right home for anything a user can only have one of.

Second, every profile is tied to a user license. Salesforce says it directly: “Every profile belongs to exactly one user license type.” And on a custom profile, “you can edit all permissions and settings except the user license” (Profiles (opens in a new tab), Salesforce Help, checked 2026-11-01). So a profile built for the Salesforce license can’t be given to a user with a Salesforce Platform license. Module 6 covers licenses.

Click to enlarge

What still lives on the profile

When you put a profile and a permission set side by side, a lot of the settings look the same. Object permissions, field-level security, app permissions, Apex class access: you can set them in both places. But some settings are exclusive to the profile. You won’t find the session settings, the password policies, the login hours or the login IP ranges on a permission set.

Here’s the rule of thumb I use. Something you can have many of will probably end up on a permission set. Something you can only have one of will probably be on the profile. One default app. One default record type for each object. One password policy. One session timeout. One set of login hours. Those are the profile’s job. Everything you can have many of, the access itself, belongs in permission sets.

Salesforce now draws the same line. It had announced that permissions on profiles would be retired, starting in Spring ‘26, and then cancelled the retirement “based on customer feedback and remaining feature gaps.” Profiles still support permissions, but Salesforce recommends “a least-privilege model using profiles for baseline settings and permission sets for access control.” On the profile: default assigned apps, default record types and page layouts, login hours, login IP ranges, password policies and session settings. Its best practice is to “Avoid adding permissions directly to profiles where possible” (Permissions in Profiles Retirement Cancelled (opens in a new tab), Salesforce Help, published 2026-06-06, checked 2026-11-01). Chapter 1, module 4 tells the story of that date and what it teaches about retirement dates in general.

In my class, I put it this way: the profile should become more about authentication and less about authorization. It’s the container for how you get in. Once you’re in, what you can do is the permission sets’ work. The front-door chapter, module 5, shows the door’s settings that stay on the profile.

My old grid, checked again

A few years ago I went through a profile and a permission set setting by setting and built a grid: every setting, whether you could set it on the profile, on the permission set, or both, and where I guessed each one would end up once permissions left the profile. I’ve checked it again against Salesforce’s guidance today.

The line held. Every setting I guessed would stay on the profile because it has a single answer is on Salesforce’s list for the profile today: the user license, the defaults, page layout assignment, the session settings, the password policies, the login hours, the login IP ranges and the default Experience Cloud site.

One guess didn’t hold. I thought the administrative and general user permissions, the big lists of checkboxes, would stay on the profile. Salesforce now recommends user permissions, app and system, in permission sets too (Permissions in Profiles Retirement Cancelled (opens in a new tab), checked 2026-11-01). So the answer is simpler than I expected: if it’s access, it goes in a permission set.

And there’s a row my grid didn’t have, because the feature didn’t exist. Which Agentforce employee agents a user can work with is set as Enabled Agent Access, on a permission set or a profile. For an agent on an Experience Cloud site, Salesforce points you to permission sets: sites “often share a single profile across many external users with the same license,” so “To restrict agent access to specific users instead of everyone on a shared profile, use a permission set” (Manage Employee Agent Access (opens in a new tab), Salesforce Help, checked 2026-11-01). The rule fits the new row too: many of something, a permission set.

Click to enlarge

Here’s the grid itself, rebuilt with current data and made complete: every capability a profile or a permission set can hold today. The list comes from Salesforce’s own definitions of the two in the Metadata API, the format Salesforce uses to move them between orgs, plus two settings Salesforce Help documents on the profile and permission set pages: connected app access and the default Experience Cloud site. The last column says where Salesforce recommends each one; where Salesforce doesn’t name a capability, it follows the rule from above.

Capability	Profile	Permission set	Where it belongs
How the user gets in
User license	Required, exactly one	Optional: a user license or a permission set license	Profile
Login hours	Yes	No	Profile
Login IP ranges	Yes	No	Profile
Password policies	Yes	No	Profile
Session settings	Yes	No	Profile
Login flows	Yes	No	Profile
Defaults and screens
Default app	Yes	No	Profile
Default record type	Yes	No	Profile
Page layout assignment	Yes	No	Profile
Default Experience Cloud site	Yes	No	Profile
Access
Object permissions	Yes	Yes	Permission sets
Field permissions (field-level security)	Yes	Yes	Permission sets
User permissions, app and system	Yes	Yes	Permission sets
Apps, beyond the default	Yes	Yes	Permission sets
Tabs	Yes	Yes	Permission sets
Record types, beyond the default	Yes	Yes	Permission sets
Apex classes	Yes	Yes	Permission sets
Visualforce pages	Yes	Yes	Permission sets
Custom permissions	Yes	Yes	Permission sets
Connected app access	Yes	Yes	Permission sets
Flows	Yes	Yes	Permission sets, by the rule
Custom metadata types	Yes	Yes	Permission sets, by the rule
Custom settings	Yes	Yes	Permission sets, by the rule
External data sources, per user	Yes	Yes	Permission sets, by the rule
Service presence statuses (Omni-Channel)	Yes	Yes	Permission sets, by the rule
Agent access (Agentforce employee agents)	Yes	Yes	Permission sets, for a shared site profile
Enhanced summary access	Yes	Yes	Permission sets, by the rule
Data category visibility (Knowledge)	Yes	Yes, also on permission set groups and roles	Permission sets, by the rule
Permission sets only
External credential principals	No (not in the profile’s metadata)	Yes	Permission sets
Email-to-Case routing addresses	No	Yes, when the address is Controlled by Permission Set (enforced in Lightning Experience only)	Permission sets
Session activation required	No	Yes, also on permission set groups	Permission sets

Checked 2026-11-01 against PermissionSet (opens in a new tab) and Profile (opens in a new tab) in the Metadata API Developer Guide, Winter ‘27 (API version 68.0); “where it belongs” from Permissions in Profiles Retirement Cancelled (opens in a new tab); the newer rows from Manage Employee Agent Access (opens in a new tab), Data Category Visibility (opens in a new tab) and Controlled by Permission Set Behavior on Email-to-Case Routing Address (opens in a new tab), Salesforce Help. Password policies and session settings are stored with the profile as their own types.

Around the two sit the tools that bundle, subtract, unlock and assign them. Each has its own module in this chapter.

Tool	What it does	Module
Permission set groups	Bundle permission sets for one kind of user	3
Muting permission sets	Take permissions away inside one group	3
Assignment expiration	End an assignment on a date	4
Session-based permission sets	Turn on only for one session	4
User access policies	Assign by criteria, on create or update	5
Permission set licenses	Unlock features the user license doesn’t include	6
Delegated administration	Let a delegated admin assign chosen profiles and permission sets	6

A grid like this goes out of date, as mine did. So here’s how to check it yourself in any org. Open a profile and a permission set side by side in the enhanced profile user interface and look for each setting in both. Or install the User Access and Permissions Assistant and convert a test profile into a permission set: whatever it leaves behind is what only the profile can hold.

The middle column is the one to watch. Those settings still work on a profile, and that’s exactly how profile proliferation starts again. Salesforce’s advice is to “Avoid adding permissions directly to profiles where possible,” and I agree.

Start from Minimum Access - Salesforce

So what should a new profile look like? As close to empty as you can make it.

Chapter 1 made this the first habit of least privilege: start from the Minimum Access - Salesforce profile and add upward, rather than cloning a standard profile and inheriting a lot of open doors you haven’t thought about. Salesforce’s own guidance says the same: assign the Minimum Access - Salesforce profile, or a clone of it, and “use permission sets and permission set groups to grant users only the permissions that they require” (Profiles (opens in a new tab), checked 2026-11-01).

Notice when it says to clone: when the default settings differ. That’s the reason a second profile should exist. Not because one team needs one more permission, but because a group of users needs a different answer to a one-of-something question: a different login policy, a different session timeout, a different default app.

The page layout matrix: the older way

There’s one place where the profile still shapes what people see, and it shows how much has changed.

Page layouts are assigned by profile. On an object with record types, you get a matrix: profiles down one side, record types across the top, and a page layout in every cell. For years, that matrix was our main way of giving different users different screens. If sales and service needed different screens for the same record type, they needed different profiles, and that drove a lot of the proliferation.

Today, Lightning record pages give you another way. You can activate a page by app, by record type and by profile, and inside the page, Dynamic Forms can show and hide fields and sections “based on record data, user details, and device type.” Salesforce lists what that saves you: it can “Reduce the number of page layouts and record types you need” (Activate Lightning Record or Home Pages (opens in a new tab) and Break Up Your Record Details with Dynamic Forms (opens in a new tab), Salesforce Help, checked 2026-11-01). So the screen is no longer a reason on its own to have another profile.

One warning, and chapter 4 goes deep on it. Showing or hiding a field on a page is about the screen, not about security. Who can see the field at all is field-level security, and that belongs in permission sets.

How many profiles do you need?

People want a number. I get asked for one in almost every class, and I’m careful with it, because no one number is right for every org. Salesforce doesn’t give one either. What it gives is the reason not to have too many: building access from permission sets by job “saves you from creating hundreds of different profiles” (Admin Best Practices for User Management (opens in a new tab), Salesforce Admins blog, 2022-04-19, checked 2026-11-01).

So instead of a number, here’s a way to count. Remember what the profile is for now: it’s one of something, the rules for how a group of users comes in the front door. You need one profile for each different way in, and a way in is a combination of three things:

• The license. Every profile belongs to exactly one user license type, so a Salesforce user, a Platform user, an integration user and an external user can never share a profile.
• The door. Login IP ranges, login hours, password policies and session settings. Staff who connect only from the company’s offices, a team that works only in the daytime, administrators with shorter sessions: each different set of door rules is a different profile. Chapter 2 covers each of these settings.
• The defaults. The default app, the default record types and the page layout assignments can still be set only on the profile. Lightning page activation and Dynamic Forms remove a lot of this, but not all of it.

Everyone who comes in the same way shares a profile. Once they’re in, you make the access individual with permission sets and permission set groups. Sets of ways in the front door first; then the access, person by person.

Now the numbers people quote make sense. A small org with one license and one set of door rules might need two or three profiles. On the Salesforce Admins podcast, one admin described taking his org from 11 profiles to 2, and the second stayed only because of “page layouts and then default assignments for apps and also record types” (Reduce Salesforce Profiles for Greater Efficiency (opens in a new tab), Salesforce Admins podcast, 2024-09-19, checked 2026-11-01). A large global company with Salesforce, Platform, integration and external licenses, and different IP rules for different regions, can need 30 or 40. That’s fine, if every one of them is a different door.

What isn’t fine is a profile for a job title. Another post on the same blog says it plainly: “If you have 25 users and 30 custom profiles, you have too many profiles” (Get Agentforce Ready: Move From Profiles to Permission Sets (opens in a new tab), Mike Reynolds, Salesforce Admins blog, 2025-01-15, checked 2026-11-01). If two profiles have the same license, the same door and the same defaults, they’re one profile, and the difference between them belongs in a permission set.

Back to that large telecom company. About 15,000 users and about 200 profiles. Their goal was to get to about 10 and move everything else into permission sets. Some people thought that was extreme, and they asked me whether 10 was crazy. My answer was to count their doors. Once the access is stripped out, most of the company comes in the same way, so most people can share a standard user profile. What used to separate one profile from the next, “office admin”, “sales manager”, “service lead”, moves into permission set groups, which module 3 covers.

Two warnings. First, don’t cut the number of profiles while you’re moving the permissions off them. The same post warns against it, for a good reason: Lightning record pages, page layouts, apps and Experience Cloud membership all point to profiles, so merging profiles is its own project. Move the access first, then merge the doors. Second, watch the other end. If you go from 200 profiles to thousands of tiny permission sets, you haven’t solved the problem, you’ve moved it, and module 2 is about that trap.

Click to enlarge

Moving off the profile

If your org has a lot of access on its profiles today, you don’t have to move it all at once. Salesforce’s own migration steps are sensible: plan and document your current permissions model, design permission sets and groups based on user roles, use user access policies to automate assignments, test thoroughly in a sandbox, and roll out to production after validation (Permissions in Profiles Retirement Cancelled (opens in a new tab)).

Salesforce also offers an app on AppExchange, the User Access and Permissions Assistant, that can convert a profile with a Salesforce license into a permission set you can edit. Know what it can’t move: defaults such as default apps, tabs and record types, page layout assignments, and login IP ranges and login settings “aren’t supported in permission sets and don’t convert” (Converting Profiles to Permission Sets (opens in a new tab), Salesforce Help, checked 2026-11-01). That’s the same list as before. What can’t move is exactly what should stay on the profile.

My advice to every client: start all new work this way now. Every new app, every new team, gets its access in permission sets and groups, not on a profile. Then move the old access over a piece at a time. It’s better to catch the wave than to be paddling hard behind it.

Watching the profiles you keep

A light profile still matters. It decides how people get in, and if someone adds a powerful permission to it, everyone with that profile gets it. So keep an eye on them.

• Profile list views. With enhanced profile list views, you can build a list view of profiles by any permission, and Salesforce’s own example is “a list view of all profiles with Modify All Data enabled” (Profiles (opens in a new tab)). Run that one now and then.
• Dependencies you can see. Since Summer ‘26, when you change a permission in the enhanced profile user interface, Salesforce shows you any other changes needed to keep dependent permissions in line. Before, those changes happened in the background and were visible only in the Setup Audit Trail.
• Alerts on critical changes. Also since Summer ‘26, transaction security policies can monitor, alert on and block changes to critical permissions on profiles (Summer ‘26 release notes: Permissions (opens in a new tab), checked 2026-11-01).
• Who can see profile names. Profile filtering is on by default and enforced in Winter ‘27: users see only their own profile name unless they have View All Profiles. Chapter 1, module 4 covers it.

What an architect decides here

• How many profiles the org needs, and the one-of-something reason each one exists: a different license, a different way of getting in, or different defaults.
• That every new profile starts from Minimum Access - Salesforce, or a clone of it.
• That new access goes into permission sets and permission set groups, not onto profiles.
• How the access already on profiles moves into permission sets, in what order, and how it’s tested.
• Whether different screens are handled by Lightning page activation and Dynamic Forms instead of more profiles.
• Who watches the profiles that remain, and how a powerful permission added to one would be noticed.

Beyond the exam: what AI changes. Agents log in too, and Salesforce now treats their access as something to watch: since Summer ‘26, it shows a banner when you edit permissions in a profile, permission set or permission set group that’s assigned to or created for an agent user. The rule from this module holds for them. Give an agent a light profile for how it gets in, and only the permission sets its job needs. Part 3 of this course covers agents.

Explore

• Profiles (opens in a new tab), Salesforce Help (checked 2026-11-01)
• 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)
• Converting Profiles to Permission Sets (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Get Agentforce Ready: Move From Profiles to Permission Sets (opens in a new tab), Mike Reynolds, Salesforce Admins blog, 2025-01-15 (checked 2026-11-01)
• Summer ‘26 release notes: Permissions (opens in a new tab), Salesforce (checked 2026-11-01)
• Manage Employee Agent Access (opens in a new tab), Salesforce Help (checked 2026-11-01)
• PermissionSet (opens in a new tab), Metadata API Developer Guide, Winter ‘27 (checked 2026-11-01)
• Profile (opens in a new tab), Metadata API Developer Guide, Winter ‘27 (checked 2026-11-01)
• Data Category Visibility (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Controlled by Permission Set Behavior on Email-to-Case Routing Address (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Activate Lightning Record or Home Pages (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Break Up Your Record Details with Dynamic Forms (opens in a new tab), Salesforce Help (checked 2026-11-01)
• Admin Best Practices for User Management (opens in a new tab), Salesforce Admins blog (checked 2026-11-01)
• Reduce Salesforce Profiles for Greater Efficiency (opens in a new tab), Salesforce Admins podcast (checked 2026-11-01)