Permissions par rôle
Rôles vs profils vs permission sets vs permission set groups — la confusion est célèbre. Beaucoup d'orgs finissent avec un fourre-tout d'accès périmés que personne n'ose nettoyer.
Ce que les utilisateurs disent vraiment
✕La gestion des profils est tirée par les demandes utilisateur plutôt que par un design top-down — les gens demandent de nouvelles permissions, jamais d'en retirer, donc les profils accumulent des accès inutiles et créent un risque d'audit.
Source : Salesforce Admins, guide profils et permissions ↗✕Même les admins expérimentés butent sur la frontière entre rôles, profils et permission sets — Salesforce lui-même appelle ça l'incompréhension la plus fréquente et la plus douloureuse de son modèle de sécurité.
Source : DESelect, rôles vs profils Salesforce ↗✕Créer un nouveau profil à chaque demande d'accès lance des chantiers de nettoyage qui durent des années et rend l'onboarding du staff et des partenaires incohérent.
Source : Gearset, des profils aux permission sets ↗
On remplace ce modèle de sécurité à quatre couches par ce dont la plupart des équipes ont vraiment besoin : trois ou quatre rôles nommés (rep, manager, ops, admin), chacun adossé à quelques lignes de policy code revues dans git. L'onboarding tient en un dropdown ; l'offboarding, en un clic ; un audit est une requête SQL — pas une jungle de permission set groups héritée du jour où l'admin qui l'a construite s'en va.