Profile und Permission Sets in der Versionsverwaltung managen

Kurze Antwort: Legen Sie Permission Sets als eigentliche Quelle der Wahrheit in die Versionsverwaltung, zerlegen Sie sie, damit zwei Personen sie ohne Merge-Konflikt bearbeiten können, halten Sie Profile schlank und behandeln Sie jedes Profil-Deployment als Überlagerung statt als vollständigen Ersatz. Hören Sie dann bewusst auf, umgebungsspezifische Teile zu versionieren, denn der meiste Profil-Lärm im Repository wird von niemandem gelesen.

Warum sind Profile in Git so schwierig?

Zwei dokumentierte Verhaltensweisen machen Profile anders als jede andere Datei im Repository.

• Ein Retrieve ist kontextabhängig. Die zurückgegebene .profile-Datei enthält nur Sicherheitseinstellungen für die anderen Metadatentypen, die in derselben Anfrage genannt sind. Fordern Sie das Profil allein an, bekommen Sie fast nichts; fordern Sie es mit 40 Objekten an, bekommen Sie eine andere Datei (Metadata-API-Dokumentation).
• Ein Deploy ist eine Überlagerung. Berechtigungen, die nicht in der Datei stehen, werden in der Ziel-Org nicht entfernt, und eine Berechtigung abzuschalten verlangt ausdrücklich den Wert false im XML. Eine fehlende Zeile heißt "keine Meinung", nicht "aus".

Zusammengenommen erzeugt dasselbe Profil je nach Person und Paketinhalt einen anderen Diff. Deshalb sind Profil-Diffs die meistdiskutierten und am wenigsten vertrauten Dateien in den meisten Salesforce-Repositories.

Was hat sich 2026 geändert, und ändert das die Strategie?

Salesforce hatte angekündigt, Berechtigungen in Profilen ab Spring '26 abzuschalten. Am 6. Juni 2026 wurde diese Durchsetzung abgesagt, mit Verweis auf Kundenrückmeldungen und verbliebene Funktionslücken, während Salesforce weiterhin ein von Permission Sets geführtes Sicherheitsmodell empfiehlt (Salesforce Hilfe).

Praktisch gelesen: Die Frist ist weg, die Richtung nicht. Profile bleiben unterstützt, niemand muss also hastig migrieren. Wenn Sie aber entscheiden, wo Sie Ihre Versionsdisziplin investieren, investieren Sie sie in Permission Sets. Sie sind additiv, sie zerlegen sich und sie lassen sich zusammenführen.

Wie zerlegt man Permission Sets, damit sie nicht mehr kollidieren?

Ein abgerufener Permission Set ist eine große XML-Datei mit jeder Objekt-, Feld- und Benutzerberechtigung. Zwei Admins an zwei unabhängigen Feldern kollidieren in derselben Datei. Salesforce liefert dafür in der CLI Source-Behavior-Optionen, die die Datei in je eine Datei pro Berechtigungsgruppe aufteilen (Salesforce DX Developer Guide).

1. Zuerst alles committen. Der Vorgang schreibt Dateien neu, starten Sie also mit einem sauberen Arbeitsbaum.
2. Als Trockenlauf ausführen: sf project convert source-behavior --behavior decomposePermissionSetBeta2 --dry-run.
3. Dann echt ausführen. Ihre sfdx-project.json wird aktualisiert, damit das Verhalten für alle gilt, und die vorhandene Quelle wird an Ort und Stelle umgewandelt.
4. Die Umwandlung in einem eigenen Branch committen, ohne funktionale Änderung. Niemand kann einen Diff prüfen, der Formatumstellung und echte Änderungen mischt.

Derselbe Mechanismus deckt Custom Labels, Workflows, Freigaberegeln und External Service Registrations ab. Beachten Sie die Lücke: Profile stehen nicht auf der Liste der zerlegbaren Typen. Objekte und Objektübersetzungen werden standardmäßig zerlegt, der Rest ist optionale Beta, und Profile bleiben eine Datei.

Was sollten Sie nicht mehr versionieren?

Die Hälfte des Schmerzes ist hausgemacht. Das Folgende gehört außerhalb des Repositories oder hinter eine bewusste Ausnahme.

• Berechtigungen aus Managed Packages. Objekt- und Feldberechtigungen mit Namespace tauchen je Org mit Paketversionen auf und wieder ab. Sie zu versionieren garantiert dauerhafte Phantom-Diffs.
• Login-IP-Bereiche und Anmeldezeiten. Das ist meist Umgebungsrichtlinie, kein Release-Inhalt, und unterscheidet sich zu Recht zwischen Sandbox und Produktion.
• Zuweisungen von Permission Sets. Das sind Datensätze, keine Metadaten. Wer welchen Satz hat, ist Daten und gehört in einen Seeding-Schritt, nicht in Git.
• Berechtigungen auf Standardobjekten, die Sie nie ändern wollen. Wenn Ihr Prozess sie nicht verwaltet, erzeugt das Abrufen nur Diff-Volumen.
• Profile, die Sie nicht deployen. Die meisten Orgs schleppen geerbte Profile mit, die seit Jahren niemand angefasst hat. Versionieren Sie die, die Ihre Pipeline wirklich befördert.

Schreiben Sie diese Ausnahmen als Regel ins Repository, nicht als Stammeswissen in die CLI-Historie einer Person. Eine Regel im Shell-Alias von jemandem bricht beim ersten Retrieve eines neuen Kollegen.

Wie verschiebt man Berechtigungen sicher von Profilen zu Permission Sets?

1. Ein Profil wählen und aufnehmen, was es in der Produktion tatsächlich gewährt, nicht in der abgedrifteten Sandbox.
2. Permission Sets nach Aufgabe schneiden, nicht nach Stellenbezeichnung. Aufgabenförmige Sätze werden wiederverwendet, titelförmige für jede neue Bezeichnung dupliziert.
3. Die neuen Sätze zusätzlich zum Profil zuweisen und sonst nichts ändern. Zugriff ist additiv, in dieser Phase verliert niemand etwas.
4. Die verschobenen Berechtigungen in einem eigenen Release aus dem Profil entfernen, mit ausdrücklichen false-Werten, damit das Deployment sie wirklich abschaltet.
5. Mit einem Benutzer dieses Profils in einer Sandbox prüfen und den Berechtigungs-Snapshot von vorher aufbewahren, bis das geschehen ist.

Schritt drei und vier gehören nie in dasselbe Release. Additive und subtraktive Berechtigungsänderungen haben völlig verschiedene Rollback-Geschichten, und ihre Vermischung ist der Weg zur Aussperrung am Montagmorgen. Weitere Release-Playbooks stehen in unserer SF-Guides-Bibliothek.

FAQ

Sind Profile oder Permission Sets die Quelle der Wahrheit?

Permission Sets. Sie sind additiv, zerlegen sich in zusammenführbare Dateien, und Salesforce empfiehlt ein von ihnen geführtes Modell. Profile behalten Sie für Grundeinstellungen wie Lizenz, Standard-Datensatztypen und Seitenlayouts.

Werden Berechtigungen in Profilen abgeschafft?

Nein. Die für Spring '26 geplante Abschaltung wurde am 6. Juni 2026 abgesagt. Die Migration folgt jetzt Ihrem Zeitplan statt einer Frist.

Warum ändert sich mein Profil-Diff, obwohl ich nichts angefasst habe?

Weil ein Profil-Retrieve nur Einstellungen für die Metadaten derselben Anfrage zurückgibt. Ändert sich der Paketinhalt, ändert sich die Datei. Reparieren Sie das Retrieve-Manifest, nicht die Datei.

Lassen sich Profile wie Permission Sets zerlegen?

Heute nicht. Die Source-Behavior-Optionen decken Permission Sets, Custom Labels, Workflows, Freigaberegeln und External Service Registrations ab. Profile bleiben eine Datei, ein weiteres Argument, sie schlank zu halten.