Understanding Roles vs Profiles in Salesforce
Salesforce security and access management rely on a few core concepts. Two of the most commonly confused pieces are Roles and Profiles. Though they both relate to user access, they govern different layers of permissions. This post explains the differences, practical implications, and recommended best practices.
High-level summary
– Profiles control what a user can do (object and field-level permissions, app and tab visibility, login hours/IP restrictions).
– Roles control which records a user can see (record-level access through the role hierarchy and sharing settings).
Profiles — What they are and what they control
Profiles are the baseline permission sets assigned to every user. Every user must have exactly one profile. Profiles determine the following key items:
- Object permissions (Read, Create, Edit, Delete) and field-level security
- App, tab and record type assignments
- Page layouts and login restrictions (IP ranges, login hours)
- System permissions (e.g., “Manage Users”, “Modify All Data”)
Profiles are designed to represent job functions — for example, “Salesforce Sales User”, “System Administrator”, or “Read‑only User” — and are typically fewer in number than users.
Setup → Users → Profiles
Roles — What they are and what they control
Roles define the record-level access and are organized in a role hierarchy. They determine which records users can see via the role hierarchy and default sharing behavior. Key points:
- Roles enable upward record visibility: users higher in the hierarchy can see records owned by users below them (when sharing model allows).
- Roles are often aligned to organization reporting lines, e.g., “Sales Manager”, “Regional Director”.
- Roles do not grant object or field-level permissions — they only affect record visibility.
Setup → Users → Roles
How Profiles and Roles work together
Profiles determine what actions a user can perform (CRUD, FLS). Roles determine which records are visible to the user. Together they form a layered security model:
- Even if a user has object-level Edit permission via their profile, they still need record-level access (via ownership, role hierarchy, sharing rules, or manual sharing) to edit a specific record.
- Users can have the permission to view a field (profile), but if they cannot access the record (role/sharing), they won’t see it.
Common pitfalls and clarifications
- Profiles are mandatory (one per user); roles are optional (a user may have no role but still needs a profile).
- Do not use profiles to control record visibility — that’s what roles and sharing are for.
- Roles are not a replacement for permission sets. Permission sets are used to grant additional permissions beyond a user’s profile without creating multiple profiles.
Best practices
- Keep a small, manageable set of profiles that represent true job functions.
- Use permission sets to grant exceptions instead of creating many profiles.
- Design the role hierarchy to reflect business reporting lines to make sharing intuitive.
- Use public groups and sharing rules for cross-team sharing needs that don’t fit the hierarchy.
Quick example
Imagine a Sales team with the following needs:
- Sales Reps should be able to Create/Edit Opportunities they own — give them a “Sales Rep” profile with Opportunity CRUD and appropriate FLS.
- Sales Managers should see Opportunities owned by their reps — put managers above reps in the role hierarchy so they inherit visibility.
- A marketing user needs temporary access to Opportunities — grant a Permission Set with Read access to Opportunity rather than creating a new profile.
Summary
Profiles = What users can do (permissions). Roles = Which records users can see (visibility). Use profiles and permission sets for functional access, and roles, sharing rules, and groups for record-level access.