A profile in Salesforce is a required collection of settings and permissions that defines what a user can do in the org — which objects they can read or edit, which fields they can see, which apps and tabs they can open, which Apex classes and Visualforce pages they can run, and which system-level actions (like Modify All Data or View Setup) they’re allowed to perform. Every user must be assigned exactly one profile.
What a profile actually controls
Salesforce bundles a wide set of permissions inside a single profile. The most commonly tested categories:
| Category | Examples |
|---|---|
| Object permissions | Read, Create, Edit, Delete, View All, Modify All — per object |
| Field-level security (FLS) | Read / Edit access per field on every object the user can access |
| App and tab visibility | Which standard/custom apps appear in the App Launcher; which tabs are default-on, default-off, or hidden |
| Record type and page layout assignments | Which record types and page layouts a profile sees on each object |
| System permissions | View Setup and Configuration, API Enabled, Modify All Data, Manage Users, Customize Application, etc. |
| Login hours and login IP ranges | When and from where users with this profile can log in |
| Apex and Visualforce access | Which classes and pages the profile can execute |
| Connected App access | OAuth scopes the profile is allowed to grant |
| Custom permissions | Project-specific flags consumed by formulas, validation rules, or Apex |
”One profile per user” — what that really means
Every user record has a required ProfileId field. You cannot save a user without assigning a profile, and you cannot assign more than one. If a user needs additional permissions beyond what their profile grants, you add them via permission sets and permission set groups, which are additive on top of the profile.
This is the modern Salesforce best practice: minimal profile, permission sets for everything else. Salesforce has been signaling for several releases that profile management of permissions will be deprecated in favor of permission sets — but the profile itself (as the license + login-hours + IP-range container) isn’t going away.
Standard vs custom profiles
- Standard profiles ship with the org: System Administrator, Standard User, Read Only, Solution Manager, Marketing User, Contract Manager, Chatter Free User, plus license-specific ones like Customer Community User. Salesforce does not let you delete standard profiles, and most of their settings are read-only. You can edit a small subset (tab settings, app visibility) but you can’t change their object permissions.
- Custom profiles are clones of a standard profile that you can fully edit. The clone inherits its license type from the parent — a custom profile cloned from Salesforce Platform Standard User cannot be assigned to a user who needs a full Salesforce license, and vice versa.
Real admin scenario
“A sales rep needs temporary access to delete leads for a one-time data cleanup. What’s the right approach?”
Wrong answer: edit their profile to grant Delete on Lead. That changes the profile for every user assigned to it.
Right answer: create a permission set called “Lead Deletion (Temporary)” that grants Delete on Lead, assign it to that one user, and unassign it when the cleanup is done. The profile stays untouched, and your audit trail clearly shows who had the extra permission and when.
Common interview follow-ups
- Can a user have multiple profiles? No. Exactly one profile per user.
- Can two users share the same profile? Yes, and they usually do — that’s the whole point of profiles.
- Is the profile mandatory? Yes — you cannot create a user without selecting one.
- Can you delete a standard profile? No.
- Can you modify a standard profile? Only tab and app visibility settings, plus assignment of record types and page layouts. Object/field permissions on standard profiles are read-only.
Verified against: Salesforce Help — Profiles and Standard Profiles. Last reviewed 2026-05-17.