Permission Set vs. Profile

Elke gebruiker heeft één profile; permission sets voegen daar extra toegang aan toe, en Salesforce raadt dat laatste aan.

Definitie

Profiles en permission sets bepalen allebei wat een Salesforce-gebruiker kan zien en doen, maar ze werken anders: elke gebruiker heeft precies één profile, dat de basisrechten voor objecten, velden en systeem instelt, terwijl permission sets additief zijn en een gebruiker er een willekeurig aantal van kan hebben om extra toegang toe te voegen zonder het profile te wijzigen. Salesforce promoot al jaren permission sets (en permission set groups, die meerdere sets bundelen) als het aanbevolen model, aangezien minimale profiles plus samenstelbare permission sets veel beter schalen dan tientallen bijna-identieke profiles onderhouden voor licht verschillende rollen. Migreren van profile-zware naar permission-set-gedreven toegangscontrole is op zichzelf een veelvoorkomend Salesforce DevOps-project, aangezien profiles en permission sets als aparte metadatatypes worden uitgerold en het ontwarren van jaren aan profile-wildgroei zorgvuldige planning vergt. Onze Salesforce DevOps-gids behandelt toegangscontrole als onderdeel van een bredere releasestrategie.

In de praktijk

Hoe het werkt in Serpent

Serpent rolt profile- en permission set-metadata uit als elk ander onderdeel, bijgehouden per Work Item en opgenomen in preflight-checks, zodat een toegangswijziging nooit stilletjes meelift met ongerelateerd werk. Org-vergelijking toont permissiedrift tussen sandboxes en productie, wat voor permission sets meer telt dan voor de meeste metadatatypes, aangezien toegangsbugs vaak onzichtbaar zijn totdat een gebruiker tegen een muur aanloopt. Serpent schrijft niet voor welk toegangsmodel je gebruikt, maar maakt beide controleerbaar en omkeerbaar met one-click rollback. Zie org management in Serpent voor hoe permissiewijzigingen worden bijgehouden.

Veelgestelde vragen