Salesforce User Profiles vs Permission Sets: What to Use in 2026

Updated June 2026. Rewritten for the permission-set-led security model Salesforce now recommends, including where profiles still apply and how the migration actually works.

Salesforce user profiles are not going away, but their job is shrinking, and if you are setting up access the old way in 2026 you are building yourself a migration headache. Profiles used to be where you controlled almost everything a user could see and do. That responsibility is moving to permission sets, and getting ahead of the shift now saves a painful cleanup later.

We are Osher Digital, a Brisbane consultancy that builds and maintains Salesforce orgs alongside our wider AI and automation work. We have inherited enough tangled permission models to have strong opinions about how to set this up cleanly. This guide covers what profiles still do, how to create and manage them, how they now relate to permission sets, and the migration Salesforce wants every admin planning for.

What Salesforce User Profiles Do, and No Longer Do

A profile is assigned to every user, and each user has exactly one. Historically a profile controlled object permissions, field-level security, system permissions, app access, login hours, IP ranges, page layouts and record type defaults. That is a lot of responsibility loaded onto one object, which is precisely the problem Salesforce is now unwinding.

The direction of travel: profiles are being narrowed to defaults and settings that genuinely belong to one-per-user. Think login hours, IP ranges, default record types, app and page layout assignments. The permission grants, object-level, field-level, system and app permissions, are moving to permission sets and permission set groups, where they can be layered and reused.

One important clarification, because it has caused real confusion. Salesforce announced an end-of-life for permissions on profiles, originally targeted at the Spring ’26 release, and then postponed it. They are no longer enforcing that date. Profiles will keep working for now. But the recommendation has not softened: all of Salesforce’s investment is going into permission sets, and the smart play is to build that way regardless of when the old behaviour finally switches off.

Creating and Managing Salesforce User Profiles

The mechanics are unchanged. In Setup, under Profiles, you can create a new profile or, more commonly, clone an existing one and adjust it. Cloning is the usual path because building a profile from nothing means setting hundreds of permissions by hand.

Here is the discipline that matters in 2026: keep new profiles lean. Set the per-user defaults on the profile, then grant the actual capabilities through permission sets. Resist the old habit of cloning the System Administrator profile, trimming a few things, and calling it a role. That anti-pattern is how orgs end up with forty near-identical profiles that nobody dares touch.

Creating a user and assigning a profile

To create a user in Salesforce, go to Setup, then Users, then New User. You assign a profile at creation, since every user needs one, then layer permission sets for their specific access. The steps in brief:

1. In Setup, open Users and select New User.
2. Enter the name, email and username, and choose the user licence and a lean profile.
3. Save, which triggers the activation email to the new user.
4. Assign the permission sets or permission set groups that grant their real capabilities.
5. Confirm their role (separate from profile) for record sharing in the hierarchy.

To clone a user in Salesforce, open an existing user record and use the Clone action, which copies the profile, role and most settings as a starting point, then adjust. It is a fast way to onboard someone into an identical position, though you still review the permission set assignments rather than trusting the copy blindly.

To deactivate a user in Salesforce, open the user record and uncheck Active. You cannot delete users, by design, because they are tied to historical records. Deactivating frees the licence and preserves the audit trail. Reassign their open records and ownership first, or you orphan a pile of data.

Salesforce User Profiles vs Permission Sets

The mental model that keeps an org clean: the profile is the baseline, permission sets are the add-ons. A user gets one profile carrying their defaults, then any number of permission sets stacking on the specific things they can do.

The advantage is reuse. If twelve people across four profiles all need access to a custom Projects object, you grant it once in a permission set and assign that set to all twelve, instead of editing four profiles and hoping they stay in sync. Permission set groups take this further, bundling several permission sets into a role-shaped package you assign in one move, with muting permission sets to subtract specific grants where a group gives slightly too much.

People also confuse profiles with roles, which are unrelated. A profile controls what a user can do; a role controls which records they can see through the sharing hierarchy. You need both, and they answer different questions. Our explainer on whether roles determine field visibility untangles that one in detail.

Planning the Migration to Permission Sets

Even with the deadline postponed, the migration is worth starting now while it is voluntary rather than forced. The work is mostly auditing, and audits are far calmer when nothing is on fire.

1. Audit your profiles. List what each one actually grants. You will find permissions nobody remembers adding and at least one profile assigned to a single person.
2. Group the common grants. The permissions that repeat across profiles become your first permission sets, organised by job function rather than by department.
3. Strip the profiles back to defaults. Once the grants live in permission sets, reduce profiles to login settings, record type defaults and layout assignments.
4. Use User Access Policies to automate assignment. This feature lets you write rules that find users matching a condition and assign them the right permission sets automatically, which is how you migrate hundreds of users without doing it by hand.

Test the whole thing in a sandbox first. The single most common mistake we see is a migration that silently removes an access someone relied on, discovered only when they cannot do their job on Monday. If you would rather not run this audit yourself, book a call and we will scope it with you.

The Permission Mistakes We See Most

A few patterns turn up again and again when we inherit an org:

• The over-cloned admin profile. Someone needed one extra permission, so they cloned System Administrator. Now several people have far more access than they should, and nobody is sure who.
• “Modify All Data” as a shortcut. Granted to dodge a sharing problem, it quietly hands a user the keys to everything. Almost never the right fix.
• Profiles named after people. “Sarah’s Profile” is a sign the model has broken down. Profiles and permission sets should describe functions, not individuals.
• No review cadence. Access granted for a project that ended a year ago is still live. Review assignments on a schedule, not when an auditor asks.

For the specific question of controlling which profiles can see an object, our walkthrough on object visibility by profile covers the exact steps.

When Salesforce User Profiles Are Not the Right Layer

Profiles are the wrong tool the moment access needs to vary independently of the per-user defaults. If two people share a profile but one needs access to a sensitive object, that grant belongs in a permission set, not a new profile. If access should be temporary, for a project or a secondment, permission sets are the only sane way to add and remove it cleanly.

And profiles are not security on their own. They control what a user can do to a type of record, not which records they see; that is the sharing model, with roles, sharing rules and record ownership. Treating profiles as your whole security story is how data ends up visible to people who should never have seen it. For a broader setup view, our Salesforce setup guide puts the pieces in order.

Frequently Asked Questions

How do I create a user in Salesforce?

In Setup, go to Users, then New User. Enter their name, email and username, choose a user licence and a lean profile, then save to send the activation email. After that, assign the permission sets that grant their actual access, since the modern approach keeps profiles minimal and puts capabilities in permission sets.

How do I deactivate a user in Salesforce?

Open the user record in Setup and uncheck Active. You cannot delete users because they are linked to historical records, so deactivating is the correct way to remove access while preserving the audit trail. Reassign their open records and ownership before you deactivate, or those records are left orphaned.

Can you clone a user in Salesforce?

Yes. Open an existing user record and use the Clone action, which copies the profile, role and most settings as a starting point for the new user. It speeds up onboarding someone into an identical position, but always review the permission set assignments afterwards rather than assuming the copy is exactly right.

Are Salesforce profiles being retired?

Not the profiles themselves. Salesforce planned to retire the ability to set permissions on profiles, targeted at Spring ’26, then postponed that and is no longer enforcing the date. Profiles continue to hold per-user defaults like login hours, record types and layouts. The clear recommendation is to manage permissions through permission sets going forward.

What is the difference between profiles and permission sets?

A profile is the one-per-user baseline carrying defaults such as login hours and record types. Permission sets are stackable add-ons that grant specific capabilities and can be assigned to many users and reused. The modern model keeps profiles lean and layers access through permission sets and permission set groups.

How many profiles can a user have?

Exactly one. Every user is assigned a single profile. This is the main reason permissions are moving to permission sets, which a user can hold any number of, allowing access to be layered and combined without creating a new profile for every variation.

Are profiles the same as roles?

No. A profile controls what a user can do, such as which objects and fields they can edit. A role controls which records they can see through the sharing hierarchy. They are independent and you configure both. Confusing the two is a common source of access problems.

How much does Salesforce permission cleanup cost in AUD?

A focused profile-to-permission-set audit and migration for a small to mid-sized org typically runs $5,000 to $20,000 AUD depending on how tangled the existing model is and how many users are involved. Ongoing admin support sits around $150 to $250 AUD per hour. The cost of getting access wrong, through a data exposure, is usually far higher.

Build new access the permission-set way, keep profiles lean, and start the audit while it is still optional. The orgs that do this now will barely notice when the old behaviour finally retires; the ones that wait will do it under pressure. If you want help untangling a permission model before it becomes a problem, get in touch with our team.