La gestion des habilitations est l'un des sujets les plus récurrents — et les plus mal maîtrisés — sur les projets Salesforce Sales Cloud. La confusion entre profils, rôles, permission sets et sharing rules génère des problèmes de sécurité, des accès incorrects et des architectures difficiles à maintenir. Voici une vue claire et opérationnelle de chaque concept.
Avant tout, il faut comprendre que Salesforce sépare deux types d'accès fondamentalement différents :
Mélanger ces deux dimensions est la principale source de confusion. Un profil ne contrôle pas quels enregistrements on voit — il contrôle ce qu'on peut faire avec les enregistrements qu'on voit.
Chaque utilisateur Salesforce doit avoir un profil. C'est la couche de permissions minimale et non négociable. Le profil définit :
💡 Bonne pratique : ne créez pas un profil par utilisateur. Créez des profils par métier (Commercial, Manager Commercial, Admin, Read-Only…) et affinez avec des permission sets. Un trop grand nombre de profils devient rapidement ingérable.
Les permission sets permettent d'accorder des droits supplémentaires à des utilisateurs spécifiques sans changer leur profil. C'est le mécanisme recommandé par Salesforce pour gérer les cas particuliers.
Exemple concret : tous les commerciaux ont le profil "Commercial". Trois d'entre eux ont besoin d'accéder au module de prévision avancée. Plutôt que de créer un nouveau profil "Commercial + Prévisions", on crée un permission set "Accès Prévisions" qu'on assigne aux trois utilisateurs concernés.
Les Permission Set Groups (disponibles depuis quelques versions) permettent de regrouper plusieurs permission sets en un seul objet assignable. Sur des organisations complexes, c'est le pattern recommandé — on assigne un groupe plutôt que plusieurs permission sets individuels, ce qui simplifie la gestion et les audits.
⚠️ Attention : les permission sets ne peuvent qu'ajouter des droits — ils ne peuvent pas en retirer. Si un profil accorde un droit qui ne devrait pas être là, la correction doit se faire sur le profil lui-même, pas via un permission set.
Les rôles définissent la position de chaque utilisateur dans l'organigramme Salesforce. La règle fondamentale : un utilisateur voit toujours les enregistrements des utilisateurs qui lui sont subordonnés dans la hiérarchie, selon les paramètres OWD (Organization-Wide Defaults) de chaque objet.
Exemple : un Directeur Commercial voit les opportunités de tous ses commerciaux. Un commercial ne voit que les siennes (si l'OWD est "Private") ou celles de son équipe (si l'OWD est "Public Read Only").
Les Organization-Wide Defaults (OWD) définissent le niveau de visibilité par défaut pour chaque objet :
Les sharing rules permettent ensuite d'ouvrir la visibilité au-delà des OWD dans des cas spécifiques — sans passer par la hiérarchie des rôles. Deux types :
| Besoin | Solution |
|---|---|
| Définir ce qu'un utilisateur peut faire (créer, modifier, supprimer) | Profil |
| Accorder un accès supplémentaire à quelques utilisateurs | Permission Set |
| Un manager voit les données de son équipe | Rôle |
| Partager des enregistrements entre équipes non hiérarchiques | Sharing Rule |
| Restreindre la visibilité par défaut d'un objet | OWD (Private) |
| Masquer certains champs à certains utilisateurs | Field-Level Security (Profil) |
| Grouper plusieurs permission sets en un | Permission Set Group |
💡 Principe directeur : commencez toujours restrictif (OWD Private, profil minimal) et ouvrez au cas par cas avec des permission sets et des sharing rules. Il est beaucoup plus difficile de restreindre des droits accordés que d'en ajouter progressivement.
Le modèle de sécurité Salesforce est puissant mais nécessite une architecture réfléchie dès le départ. Profils pour les droits de base, permission sets pour les exceptions, rôles pour la hiérarchie de visibilité, sharing rules pour les partages transversaux — chaque mécanisme a son rôle précis. Les confondre génère des architectures fragiles qu'on ne peut plus faire évoluer proprement. C'est l'un des premiers points d'audit que j'effectue quand j'arrive sur une instance existante.
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.
Architecture des habilitations, audit de sécurité, implémentation — je peux vous accompagner. Réponse sous 24h.Permission architecture, security audit, implementation — I can support you. Reply within 24 hours.
Parlons de votre projet →Let's talk →