Permission Set vs. Profile

Chaque utilisateur a un seul profile ; les permission sets ajoutent un accès supplémentaire par-dessus, et Salesforce recommande ces derniers.

Définition

Les profiles et les permission sets contrôlent tous deux ce qu'un utilisateur Salesforce peut voir et faire, mais ils fonctionnent différemment : chaque utilisateur a exactement un profile, qui définit les permissions de base sur les objets, les champs et le système, tandis que les permission sets sont additifs et un utilisateur peut en détenir un nombre quelconque pour ajouter des accès supplémentaires sans changer son profile. Salesforce pousse depuis des années les permission sets (et les permission set groups, qui regroupent plusieurs sets) comme le modèle recommandé, car des profiles minimaux plus des permission sets composables passent bien mieux à l'échelle que maintenir des dizaines de profiles quasi identiques pour des rôles légèrement différents. Migrer d'un contrôle d'accès dominé par les profiles vers un contrôle piloté par les permission sets est en soi un projet Salesforce DevOps courant, car les profiles et les permission sets se déploient comme des types de métadonnées séparés et démêler des années de prolifération de profiles demande une planification soignée. Notre guide Salesforce DevOps couvre le contrôle d'accès dans le cadre d'une stratégie de release plus large.

En pratique

Comment cela fonctionne dans Serpent

Serpent déploie les métadonnées de profile et de permission set comme n'importe quel autre composant, suivies par Work Item et incluses dans les vérifications de preflight, de sorte qu'un changement d'accès ne part jamais silencieusement aux côtés d'un travail sans rapport. La comparaison d'org révèle la dérive des permissions entre sandboxes et production, ce qui compte plus pour les permission sets que pour la plupart des types de métadonnées, puisque les bugs d'accès sont souvent invisibles jusqu'à ce qu'un utilisateur se heurte à un mur. Serpent n'impose pas quel modèle d'accès utiliser, mais rend les deux auditables et réversibles grâce au rollback en un clic. Voir la gestion des orgs dans Serpent pour savoir comment les changements de permissions sont suivis.

Questions fréquentes