Permission management is one of the most recurring, and most poorly understood, topics on Salesforce Sales Cloud projects. Confusion between profiles, roles, permission sets and sharing rules generates security issues, incorrect access and architectures that are difficult to maintain. Here's a clear, operational view of each concept.
First, understand that Salesforce separates two fundamentally different types of access:
Mixing these two dimensions is the main source of confusion. A profile doesn't control which records you see, it controls what you can do with the records you see.
Every Salesforce user must have a profile. It's the minimum, non-negotiable permission layer. The profile defines:
💡 Best practice: don't create one profile per user. Create profiles by job function (Sales Rep, Sales Manager, Admin, Read-Only…) and refine with permission sets. Too many profiles quickly becomes unmanageable.
Permission sets allow granting additional rights to specific users without changing their profile. This is Salesforce's recommended mechanism for handling special cases.
Concrete example: all sales reps have the "Sales Rep" profile. Three of them need access to the advanced forecasting module. Rather than creating a new "Sales Rep + Forecasting" profile, create a "Forecasting Access" permission set and assign it to those three users.
Permission Set Groups (available since recent versions) allow grouping multiple permission sets into a single assignable object. On complex organisations, this is the recommended pattern, assign a group rather than multiple individual permission sets, simplifying management and audits.
⚠️ Warning: permission sets can only add rights, they cannot remove them. If a profile grants a right that shouldn't be there, the fix must be made on the profile itself, not via a permission set.
Roles define each user's position in the Salesforce org chart. The fundamental rule: a user always sees records owned by users below them in the hierarchy, according to each object's OWD (Organization-Wide Defaults) settings.
Example: a Sales Director sees all opportunities from their sales reps. A sales rep only sees their own (if OWD is "Private") or their team's (if OWD is "Public Read Only").
Organization-Wide Defaults (OWD) define the default visibility level for each object:
Sharing rules then open visibility beyond OWD in specific cases, without going through the role hierarchy. Two types:
| Need | Solution |
|---|---|
| Define what a user can do (create, edit, delete) | Profile |
| Grant additional access to specific users | Permission Set |
| Manager sees their team's data | Role |
| Share records across non-hierarchical teams | Sharing Rule |
| Restrict default object visibility | OWD (Private) |
| Hide certain fields from certain users | Field-Level Security (Profile) |
| Group multiple permission sets into one | Permission Set Group |
💡 Guiding principle: always start restrictive (Private OWD, minimal profile) and open access case by case with permission sets and sharing rules. It's much harder to restrict previously granted rights than to progressively add them.
Salesforce's security model is powerful but requires a well-thought-out architecture from the start. Profiles for base rights, permission sets for exceptions, roles for visibility hierarchy, sharing rules for cross-team sharing, each mechanism has its precise role. Confusing them generates fragile architectures that can no longer evolve cleanly. It's one of the first audit points I check when arriving on an existing instance.
Permission architecture, security audit, implementation, I can support you. Reply within 24 hours.
Let's talk →