Salesforce profiles are the settings every user gets by default. A profile sets a user's apps, record types, page layouts, login hours and IP ranges, and can grant object, field and system permissions. Every user has exactly one profile, tied to their user licence. Permission sets add access on top of the profile, and roles decide which records a user can see.
This guide was first published in 2020 as "What is Profile in Salesforce". It has been rewritten for 2026 and now also covers roles versus profiles, permission sets, and Salesforce's latest position on moving permissions off profiles.
What is a profile in Salesforce?
Trailhead's Data Security module describes the profile as the place for a user's default settings. A profile controls:
- Defaults: assigned apps, the default record type for each object, and which page layout a user sees.
- Login restrictions: login hours and trusted IP ranges.
- Object permissions: read, create, edit, delete, view all and modify all for each object.
- Field-level security: which fields a user can see and edit.
- System permissions: broad rights such as View All Data and Modify All Data.
Every user must have one profile, no more and no fewer, and the profile must match their user licence.
To view or edit one, go to Setup → Profiles and click its name. Many orgs use the enhanced profile user interface, which opens an overview page with a Find Settings box for searching objects, permissions and settings; an org uses either the enhanced or the original interface, not both, which is why the Edit button sometimes seems to be missing.
Standard and custom profiles
Standard profiles come with Salesforce and can't have their object permissions changed; custom profiles are clones you can edit. Salesforce provides standard profiles such as Standard User, Marketing User and System Administrator. You can't change a standard profile's object permissions; clone it and edit the clone instead. The System Administrator profile includes View All Data and Modify All Data, which override sharing settings, so give it to as few people as possible.
The profile Salesforce points you to for most users is Minimum Access - Salesforce, or a clone of it: it grants almost nothing, so access is added deliberately with permission sets.
Profiles for integration users
Integrations and other non-human users need a profile too, and they easily end up with more access than they need. For API-only integrations, Salesforce provides the Salesforce Integration user licence with the Minimum Access - API Only Integrations profile. Salesforce's Developers blog on the Salesforce Integration user explains that this profile enables API access and restricts the user to API access only, and that both settings are locked. The Salesforce Admins guidance on configuring your integration user recommends one integration user per integration, a bare profile and access through permission sets.
Profiles vs permission sets
A profile holds a user's defaults and there is only one per user; permission sets add access for specific tasks and a user can have many.
| Profile | Permission set | |
|---|---|---|
| How many per user | Exactly one | Any number |
| Purpose | Defaults: apps, record types, page layouts, login hours, IP ranges | Access for a task: objects, fields, tabs, Apex classes, features |
| Can grant object and field access | Yes | Yes |
| Can remove access | Only by editing the profile | No; it only adds. A muting permission set inside a group can switch permissions off |
| Grouping | None | Permission set groups bundle sets into a persona, such as Sales Rep |
| Best practice | Keep it minimal | Use for all object and feature access |
The difference matters as an org grows. With profiles alone, every small variation of a job ("sales rep who can also export reports") needs another cloned profile, and orgs end up with dozens that nobody can audit. With permission sets, each set covers one task, a permission set group bundles them per persona, and a user gets the base profile plus the groups they need.
What is the difference between a role and a profile?
This is the most common confusion in Salesforce security. A profile decides what a user can do; a role decides which records they can see.
| Profile | Role | |
|---|---|---|
| Controls | Objects, fields, apps, features | Record visibility |
| Example | Can edit Opportunities | Can see the opportunities owned by their team |
| Required | Yes, every user has one | No, a user can have no role |
| Structure | Flat list | A hierarchy |
Trailhead's roles unit explains that the role hierarchy works with organization-wide defaults: users can access records owned by or shared with users below them in the hierarchy. Roles don't have to copy the org chart; each role stands for a level of data access. For custom objects, you can turn off Grant Access Using Hierarchies so managers don't automatically see their team's records.
Profiles also decide which record types a user can pick and which objects they can use at all; see what Salesforce objects are. Put together, a user can open a record only if their profile or permission sets give access to the object and the sharing model (organization-wide defaults, roles, sharing rules) gives access to that record.
Is Salesforce retiring permissions on profiles?
No longer. As of November 2026, profiles keep their permissions. Salesforce had planned to retire permissions on profiles in the Spring '26 release, with permission sets taking over. That plan has been dropped: Salesforce Help's article Permissions in Profiles Retirement Cancelled (published 6 June 2026) says the retirement was cancelled based on customer feedback and remaining feature gaps, and that profiles continue to support permissions. The same article says Salesforce still recommends a permission set-led security model.
So nothing breaks if your org still grants access through profiles, but the advice for new work is unchanged: keep profiles for defaults, put access in permission sets.
How to move permissions from profiles to permission sets
Inventory your profiles, design personas, build task-based permission sets and groups, then move users in tested waves.
- Inventory. List your profiles, how many active users each has, and which permissions differ between them.
- Design personas. Group users by job (sales rep, sales manager, service agent) and the tasks they share.
- Build permission sets per task, such as "Manage Opportunities" or "Export Reports", and bundle them into a permission set group per persona.
- Create a minimal base profile from Minimum Access - Salesforce, keeping only defaults: apps, record types, page layouts, login hours and IP ranges.
- Test in a sandbox with real users' combinations; our sandbox guide covers which one to use.
- Move users in waves, then remove the old permissions from profiles and retire unused cloned profiles.
Common profile mistakes
The usual mistakes are too many admins, too many cloned profiles and using profiles to solve sharing problems.
- Giving System Administrator to power users who only need a few extra permissions.
- Cloning a profile for every small variation instead of adding a permission set.
- Expecting a role to grant edit access: roles only open up records; the profile or permission sets decide what can be done with them.
- Granting Modify All or View All on an object to fix a sharing problem, which bypasses the sharing model entirely; fix it with sharing rules instead.
- Assigning a full user profile to an integration that only needs the API.
Our Salesforce security guide covers the day-to-day habits that keep access tight.
Getting help
Moving a mature org from profile-based access to permission sets is mostly analysis and testing. Techila is a Salesforce Summit Partner; our Salesforce managed services team reviews and redesigns access models. Talk to us about yours.
Frequently asked questions
What is a profile in Salesforce?
A profile is the collection of settings and permissions every user is given. It sets default apps, record types, page layouts, login hours and IP ranges, and can grant object, field and system permissions. Each user has exactly one profile, tied to their user licence.
What is the difference between a role and a profile in Salesforce?
A profile controls what a user can do: which objects, fields, apps and features they can use. A role controls which records they can see, through the role hierarchy: users can access records owned by or shared with users below them.
What is the difference between profiles and permission sets?
Each user has one profile but can have many permission sets. Permission sets only add access, so Salesforce recommends a minimal profile for defaults and permission sets, grouped into permission set groups, for object and feature access.
Is Salesforce retiring permissions on profiles?
No longer. Salesforce had planned to retire permissions on profiles in Spring '26, but cancelled the retirement based on customer feedback. Profiles still support permissions, and Salesforce still recommends a permission set-led model.
Can you edit a standard profile in Salesforce?
Not its object permissions. Standard profiles such as Standard User and System Administrator can't have their object permissions changed. Clone the profile and edit the clone, or better, add access with permission sets.