Salesforce DictionarySalesforce DictionarySalesforce DictionarySalesforce DictionaryData visibility vs feature access
A Role in Salesforce is a record-sharing concept, not a job-title concept. The Role assigned to a User decides which records the User can see by default through the Role Hierarchy, independent of what their Profile lets them do. A Sales Rep Profile says "this user can read and edit Opportunity records." The Sales Rep's Role says "this user can see Opportunities owned by themselves and by anyone whose Role rolls up underneath theirs in the hierarchy." Together, Profile and Role decide both capability and visibility. The Salesforce permission model splits authorization (Profile + Permission Sets) from visibility (Role + Sharing Rules). The split is intentional: a sales manager who can edit any Opportunity (Profile-level capability) should only see Opportunities owned by their team (Role-level visibility), not by every team in the company. Building those two layers independently gives admins enough flexibility to model real organizations where a Service Manager and an Account Executive carry the same Profile (both can edit Cases) but see entirely different record sets (the Service Manager sees their team's Cases; the Account Executive sees their owned Accounts and the Cases that hang off them).
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.
| Dimension | Role | Profile |
|---|---|---|
| Purpose | Controls which records a user can see | Controls which features and objects a user can access |
| Hierarchy | Yes - role hierarchy shares records upward | No hierarchy |
| Record Access | Determines sharing and visibility | Determines CRUD permissions on objects |
| Required | Optional | Required - every user must have one |
| Scope | Data access only | Object, field, app, tab, and system permissions |
When you need to control record visibility based on organizational hierarchy.
When you need to define what actions a user can perform on objects and features.
Other side-by-side breakdowns you might find useful