Salesforce DictionarySalesforce DictionarySalesforce DictionarySalesforce DictionaryBaseline access vs additive access
A Profile in Salesforce is the foundational permission record that every User must have. The Profile defines what objects a user can read, create, edit, or delete; what fields they can see and modify (field-level security); which tabs and apps appear in their UI; which page layouts and record types render for them; and dozens of system permissions that control specific behaviors (Export Reports, Manage Public List Views, View Setup). Every User in a Salesforce org has exactly one Profile, and that Profile is the floor of their permission set. The original Salesforce design treated Profile as the single source of truth for what a User could do. Admins built one Profile per role (Sales Rep, Sales Manager, Service Agent, Read-Only User) and cloned new Profiles whenever a new role emerged. That worked at small scale but produced an unmanageable proliferation in larger orgs: forty Profiles, each subtly different, each carrying its own copy of every object and field permission, and every time a new field shipped somebody had to touch all forty Profiles. The shift in Salesforce best practice over the last decade has been to flatten Profiles to the minimum (a thin permission floor) and layer Permission Sets on top to grant the actual capabilities a user needs. The Profile becomes a template; the Permission Sets become the menu of options assigned per user.
A Permission Set in Salesforce is an additive permission grant that layers on top of a User's Profile. Where a User has exactly one Profile, the same User can have many Permission Sets, each granting a specific capability: access to a custom object, edit rights on a specific field, the ability to run a specific feature, visibility into a particular tab. Permission Sets are how Salesforce's permission model handles "this user is mostly a Sales Rep but also needs to approve discounts" without forcing you to clone the entire Sales Rep Profile into a Sales-Rep-with-Approvals Profile. The Permission Set concept exists because Profile-only permission management does not scale. In an org with twenty Sales Reps who all need almost-the-same permissions plus one of three optional capabilities (Approval Rights, Forecast Adjustments, Mass Email), the Profile-only approach produces three Profiles per capability combination (eight Profiles for three boolean flags, all maintained in parallel). The Permission Set approach is one Profile (Sales Rep) plus three Permission Sets (Approver, Forecast Adjuster, Mass Emailer), assigned in any combination. The maintenance shrinks from updating eight Profiles when a new field ships to updating one Profile plus three Permission Sets. Once you have seen the scaling difference, the Profile-only pattern feels like a relic.
| Dimension | Profile | Permission Set |
|---|---|---|
| Assignment | One per user (required) | Multiple per user (optional) |
| Access Model | Sets baseline permissions | Adds permissions on top of Profile |
| Object Access | Full control of CRUD on objects | Grants additional CRUD beyond Profile |
| Login Settings | Controls login hours and IP ranges | Cannot control login restrictions |
| Best Practice | Keep minimal - use as a baseline | Layer extra access for specific needs |
Every user needs exactly one Profile for baseline login and default settings.
Grant additional permissions to specific users without changing their Profile.
Other side-by-side breakdowns you might find useful