A profile sets a user’s baseline access and a handful of org-level settings, and every user has exactly one. A permission set adds access on top of that baseline, and a user can hold as many as the job requires. Salesforce recommends keeping profiles thin and building everything else from permission sets and permission set groups, a model that is easier to audit and easier to change.
In June 2026 Salesforce cancelled the planned retirement of permissions on profiles, so profiles keep working the way they always have. The security reasoning behind the original plan still applies, though. This guide explains what each tool controls, which settings still live on the profile, how to build a least-privilege model, and how to audit who has access to what. If you run an org on your own or with a small team, the Cirra AI page for Salesforce admins shows how routine access work gets delegated to the AI client you already use.
What is a profile in Salesforce?
A profile is the one required access container on every user record. It decides which objects the user can create, read, edit and delete, which fields they can see, which apps they land in, and which system permissions they hold. It also carries settings that no other feature controls yet.
Two facts shape everything else about profiles:
- Each user has exactly one profile, so two people who need slightly different access need two profiles, or one profile plus extra permission sets.
- Every profile has a permission set record behind it. You can see this when you query permission data with SOQL, and it is why one access question can be answered from either side.
What is a permission set?
A permission set is a collection of settings that extends access without touching the profile. It can grant object permissions, field-level security, system permissions, access to Apex classes and connected apps, custom permissions, tab settings and record types beyond the default. Users can hold many permission sets at once, and permission sets only add access. If a permission appears in a permission set but not in the profile, the user gets it.
Permission sets are also where licensing shows up. A user needs the right user license and, for some features, a permission set license before an assignment takes effect.
Permission sets vs profiles: a side-by-side comparison
| Profile | Permission set | |
|---|---|---|
| How many per user | Exactly one | As many as needed |
| Role | Baseline access | Adds access only |
| Object and field permissions | Yes | Yes |
| System permissions | Yes | Yes |
| Login hours and login IP ranges | Yes | No |
| Default apps and default record types | Yes | No |
| Page layout assignments | Yes | No |
| Bundles into groups | No | Yes, through permission set groups |
| Best use | Thin baseline for a user type | Task-sized access you can reuse |
Salesforce’s notice describes profiles as the home for app defaults, login policies and page layouts. Confirm the full list of profile-only settings in your org’s Setup before you design around it, because Salesforce changes what permission sets can control from release to release.
What Salesforce decided in 2026
For several years the plan was to retire permissions on profiles, with Spring ’26 as the target. On June 6, 2026 Salesforce published a notice that the enforcement is cancelled based on customer feedback and remaining feature gaps. Salesforce’s announcement says profiles continue to support permissions.
The same notice keeps the recommendation in place. Salesforce still advises a least-privilege model where the profile holds baseline settings such as app defaults, login policies and page layouts, while permission sets carry object permissions, field-level security and user permissions, and permission set groups combine permission sets by job role. It also points admins to User Access Policies for automating permission set assignments.
For your org this means two things. No deadline forces a migration this year. A good reason to start one anyway is that every cloned profile adds another place where access can drift.
Permission set groups and muting
A permission set group bundles several permission sets so you can assign one thing per job role. Users in the group receive the combined permissions of every permission set inside it, and a change to one permission set flows through to every group that contains it.
Muting handles the exceptions. Inside a group you can mute specific permissions without editing the underlying permission sets, which lets you reuse a permission set for most roles and remove one capability for a single role. Each group also shows a calculation status of Outdated, Updating or Updated. A group that still reads Updating has not finished recalculating, so wait for Updated before you test what a user can do.
How to build a least-privilege permission model
Follow this sequence whether your org has 5 profiles or 50.
- Inventory first. List every profile, its user count and the permission sets already in use. Profiles with no active users can be retired. Profiles that differ by one or two settings are candidates to merge.
- Pick a baseline profile. Salesforce’s notice recommends the Minimum Access - Salesforce profile as a starting point, so users start with almost nothing and receive access through permission sets.
- Write permission sets around tasks. Name them for what they allow, such as Quote Editor or Case Escalation, and avoid job titles. A task-sized permission set can be reused in several groups.
- Assemble groups by role. Build one group per persona, such as Sales Rep or Support Agent, from the task-sized sets. Use muting for the one-off differences.
- Keep profile-only settings on the baseline. Login hours, login IP ranges, default apps, default record types and page layout assignments live on the profile, so plan a small number of profiles for those differences.
- Migrate in a sandbox. Assign the new groups to a test user, compare what that user can do against the old profile, and fix gaps before touching production.
- Move users in batches. Switch users to the baseline profile once their groups are assigned, and keep the old profile until the last user has moved.
- Document the model. Record what each permission set allows and who owns it.
How to audit who has access to what
The question admins hear most is who can see a given field. Permission data is queryable, and because every profile has a permission set behind it, one query covers both.
To list every permission set and profile that grants access to a field:
SELECT Parent.Label, Parent.Profile.Name, PermissionsRead, PermissionsEdit
FROM FieldPermissions
WHERE SobjectType = 'Account' AND Field = 'Account.AnnualRevenue'Rows where Parent.Profile.Name has a value come from a profile. The rest come from permission sets.
To list the users who hold a particular permission set:
SELECT Assignee.Name, PermissionSet.Label
FROM PermissionSetAssignment
WHERE PermissionSet.Name = 'Quote_Editor'Run both before you remove a permission set. The first shows what the set grants and the second shows which users will feel the change.
Common problems and how to fix them
A user has the permission set but cannot do the thing. Check the user license and any required permission set license first. Then check whether the permission set sits inside a group where that permission is muted.
A change to a permission set does not show up for users in a group. Open the group and read the calculation status. Outdated or Updating means the combined permissions are still being rebuilt.
You need to take access away from one person. A permission set cannot remove access. Muting inside a permission set group applies to everyone assigned that group, so it only fits when the whole group should lose the permission. For one person, remove the assignment that grants the access or move them to a group that leaves it out, then check their profile and other assignments for the same permission.
The org has a single enormous permission set. Split it by task. A permission set that does everything cannot be reused and cannot be audited.
A cloned profile has drifted from its original. Compare the two permission records with a query like the one above and decide which differences are intentional.
Where Cirra AI fits
Building and auditing this model involves a lot of repetitive Setup work. Cirra AI is the first commercial Salesforce Admin MCP Server. It is hosted, and it connects your Salesforce org to the AI client you already use, including Claude, ChatGPT and Cursor. You describe the change, and Cirra AI makes it in your org as the connected user.
For permissions, that covers creating and assigning permission sets, creating and cloning profiles, setting field-level security, provisioning users with the access they need, and answering questions such as who can see a field. The permission set management use case walks through those tasks in more detail.
The guardrails matter for access work in particular. Cirra AI connects through Salesforce OAuth and can only do what the connected user is allowed to do in Salesforce. You can also set optional guardrails per org, and Cirra AI documents every change it makes. Following the model above, you would make permission changes in a sandbox first and deploy to production through your usual process. For more on why AI access to an org deserves the same discipline as human access, read the Cirra AI piece on least privilege for AI agents in Salesforce.
Cirra AI supports Salesforce Enterprise Edition and up. Start Free Trial to try it on your own org, or use Learn More to see what the Salesforce Admin MCP Server can do.
FAQ
What is the main difference between permission sets and profiles?
A profile is the single baseline every user must have. A permission set adds access on top of the baseline, and a user can hold many of them. Permission sets cannot remove access that a profile grants.
Is Salesforce retiring profiles?
No. Salesforce cancelled the planned retirement of permissions on profiles in June 2026 and says profiles continue to support permissions. Salesforce still recommends moving access into permission sets and permission set groups.
Can a Salesforce user have more than one profile?
No. Each user has exactly one profile. To give a user extra access, assign permission sets or a permission set group.
What is a permission set group?
A permission set group bundles several permission sets into one assignable package, usually matched to a job role. Users receive the combined permissions of everything in the group, and muting lets you remove specific permissions inside the group without changing the permission sets themselves.
Which settings can only be controlled on a profile?
Salesforce’s notice names app defaults, login policies and page layouts as profile territory. In practice that includes login IP ranges, login hours, default apps and record types, and page layout assignments. Check your org’s Setup for the current list, because Salesforce changes what permission sets can control from release to release.
Which should I use, a profile or a permission set?
Use a thin profile for the baseline and for the profile-only settings above, and use permission sets and permission set groups for everything else. That keeps access easy to audit, and each new role needs a new group rather than a new profile.
How do I find out who has access to a field in Salesforce?
Query FieldPermissions in SOQL and read the Parent relationship, which returns both permission sets and the permission set behind each profile. You can also ask Cirra AI who can see a field from your connected AI client, and it runs the lookup as the connected user.
