Permission Set vs. Profile

Jeder Nutzer hat ein Profile; Permission Sets legen zusätzlichen Zugriff obendrauf, und Salesforce empfiehlt Letzteres.

Definition

Profiles und Permission Sets steuern beide, was ein Salesforce-Nutzer sehen und tun kann, aber sie funktionieren unterschiedlich: Jeder Nutzer hat genau ein Profile, das grundlegende Objekt-, Feld- und Systemberechtigungen festlegt, während Permission Sets additiv sind und ein Nutzer beliebig viele davon halten kann, um zusätzlichen Zugriff hinzuzufügen, ohne sein Profile zu ändern. Salesforce propagiert seit Jahren Permission Sets (und Permission Set Groups, die mehrere Sets bündeln) als empfohlenes Modell, da minimale Profiles plus komponierbare Permission Sets weit besser skalieren als Dutzende fast identische Profiles für leicht unterschiedliche Rollen zu pflegen. Die Migration von profile-lastiger zu permission-set-gesteuerter Zugriffskontrolle ist für sich genommen ein häufiges Salesforce-DevOps-Projekt, da Profiles und Permission Sets als separate Metadatentypen deployt werden und das Entwirren jahrelanger Profile-Wildwuchs sorgfältige Planung erfordert. Unser Salesforce-DevOps-Guide behandelt Zugriffskontrolle als Teil einer breiteren Release-Strategie.

In der Praxis

So funktioniert es in Serpent

Serpent deployt Profile- und Permission-Set-Metadaten wie jede andere Komponente, per Work Item nachverfolgt und in Preflight-Checks einbezogen, sodass eine Zugriffsänderung nie stillschweigend neben unrelated Arbeit ausgeliefert wird. Der Org-Vergleich zeigt Berechtigungs-Drift zwischen Sandboxes und Produktion, was bei Permission Sets mehr zählt als bei den meisten Metadatentypen, da Zugriffsfehler oft unsichtbar sind, bis ein Nutzer an eine Wand stößt. Serpent schreibt nicht vor, welches Zugriffsmodell Sie nutzen, macht aber beide mit One-Click-Rollback auditierbar und rückgängig machbar. Siehe Org-Management in Serpent dafür, wie Berechtigungsänderungen nachverfolgt werden.

Häufige Fragen