Profiles control what a user can do — which objects and fields they can read or edit, and which system actions they’re allowed to perform. Roles control which records a user can see based on the role hierarchy and the org’s sharing model. A profile is required on every user; a role is optional. Mixing the two up is the most common conceptual error in junior Salesforce security interviews.
The split: “what you can do” vs “what you can see”
| Dimension | Profile | Role |
|---|---|---|
| Purpose | Permission to perform actions on objects, fields, and system features | Position in the role hierarchy — drives record visibility |
| Required? | Yes — every user has exactly one | No — roles are optional |
| Affects access to | Objects (CRUD), fields (FLS), apps, tabs, Apex, system permissions, login hours, IP ranges | Records owned by users below in the hierarchy, plus role-based sharing rules |
| Cardinality | One profile per user, many users per profile | One role per user, many users per role |
| Default in a new org | Standard profiles shipped (System Admin, Standard User, etc.) | No default roles — admin builds the hierarchy |
| Sharing impact | None directly | Drives “Grant Access Using Hierarchies” — managers automatically see records owned by direct reports |
| License coupling | A profile is tied to a license type | A role is license-independent |
Why this distinction exists
Salesforce’s security model is built in layers, and profiles and roles answer two different questions:
Q1: Can this user open the Account object at all? → Profile (CRUD)
Q2: Which specific Account records can this user see? → OWD + Role + Sharing rulesIf a profile says “no Read on Account,” the role hierarchy is irrelevant — the user can’t see the object. If the profile grants Read on Account but the OWD is Private and the user has no role above the owner, they still see nothing. Both layers must permit access.
A concrete scenario
Imagine a sales org with two reps, Alice and Bob, plus their manager Maya:
- All three have the same profile: Standard User (Read/Create/Edit on Account, Opportunity, Lead, Contact).
- Maya has the role Sales Manager; Alice and Bob have the role Sales Rep under Maya.
- OWD for Opportunity is Private.
Result:
- Alice and Bob can open the Opportunity tab (profile allows it).
- Alice can only see opportunities she owns. She cannot see Bob’s.
- Maya can see her own opportunities and every opportunity owned by Alice and Bob, because “Grant Access Using Hierarchies” is enabled for Opportunity.
Swap profiles: if you change Alice’s profile to Read Only, she can still see the same records, but she can no longer edit them. The role determined which records; the profile determined what she can do to them.
Common interview follow-ups
- Is role mandatory? No. A user can exist without a role. Without a role they’re not in the hierarchy, so on Private OWDs they only see records they own or that have been explicitly shared with them.
- Can a user have multiple roles? No. Exactly one role per user. (Compare this to permission sets, which are multi-assigned.)
- Can two users share the same role? Yes. Roles are like job buckets — many users typically sit in the same role node.
- Which one drives the role hierarchy? The role, obviously — but interviewers ask this to check you don’t confuse it with the management chain on the User record (the
ManagerIdfield), which is unrelated to the role hierarchy. - What if I assign someone a profile and forget the role? They’ll be able to log in and use objects per the profile, but on Private OWDs they’ll only see records they own or have explicit shares to — they’re outside the hierarchy.
Verified against: Salesforce Help — User Permissions and Access and Role Hierarchy. Last reviewed 2026-05-17.