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 konnen, halten Sie Profile schlank und behandeln Sie jedes Profil-Deployment als Uberlagerung statt als vollstandigen Ersatz. Horen Sie dann bewusst auf, umgebungsspezifische Teile zu versionieren, denn der meiste Profil-Larm 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 kontextabhangig. Die zuruckgegebene .profile-Datei enthalt nur Sicherheitseinstellungen fur 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 Uberlagerung. Berechtigungen, die nicht in der Datei stehen, werden in der Ziel-Org nicht entfernt, und eine Berechtigung abzuschalten verlangt ausdrucklich den Wert false im XML. Eine fehlende Zeile heisst "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 geandert, und andert das die Strategie?

Salesforce hatte angekundigt, Berechtigungen in Profilen ab Spring '26 abzuschalten. Am 6. Juni 2026 wurde diese Durchsetzung abgesagt, mit Verweis auf Kundenruckmeldungen und verbliebene Funktionslucken, wahrend Salesforce weiterhin ein von Permission Sets gefuhrtes Sicherheitsmodell empfiehlt (Salesforce Hilfe).

Praktisch gelesen: Die Frist ist weg, die Richtung nicht. Profile bleiben unterstutzt, 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 zusammenfuhren.

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

Ein abgerufener Permission Set ist eine grosse XML-Datei mit jeder Objekt-, Feld- und Benutzerberechtigung. Zwei Admins an zwei unabhangigen Feldern kollidieren in derselben Datei. Salesforce liefert dafur 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 ausfuhren: sf project convert source-behavior --behavior decomposePermissionSetBeta2 --dry-run.
3. Dann echt ausfuhren. Ihre sfdx-project.json wird aktualisiert, damit das Verhalten fur alle gilt, und die vorhandene Quelle wird an Ort und Stelle umgewandelt.
4. Die Umwandlung in einem eigenen Branch committen, ohne funktionale Anderung. Niemand kann einen Diff prufen, der Formatumstellung und echte Anderungen mischt.

Derselbe Mechanismus deckt Custom Labels, Workflows, Freigaberegeln und External Service Registrations ab. Beachten Sie die Lucke: Profile stehen nicht auf der Liste der zerlegbaren Typen. Objekte und Objektubersetzungen werden standardmassig zerlegt, der Rest ist optionale Beta, und Profile bleiben eine Datei.

Was sollten Sie nicht mehr versionieren?

Die Halfte des Schmerzes ist hausgemacht. Das Folgende gehort ausserhalb 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 Datensatze, keine Metadaten. Wer welchen Satz hat, ist Daten und gehort in einen Seeding-Schritt, nicht in Git.
• Berechtigungen auf Standardobjekten, die Sie nie andern 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 befordert.

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 wahlen und aufnehmen, was es in der Produktion tatsachlich gewahrt, nicht in der abgedrifteten Sandbox.
2. Permission Sets nach Aufgabe schneiden, nicht nach Stellenbezeichnung. Aufgabenformige Satze werden wiederverwendet, titelformige fur jede neue Bezeichnung dupliziert.
3. Die neuen Satze zusatzlich zum Profil zuweisen und sonst nichts andern. Zugriff ist additiv, in dieser Phase verliert niemand etwas.
4. Die verschobenen Berechtigungen in einem eigenen Release aus dem Profil entfernen, mit ausdrucklichen false-Werten, damit das Deployment sie wirklich abschaltet.
5. Mit einem Benutzer dieses Profils in einer Sandbox prufen und den Berechtigungs-Snapshot von vorher aufbewahren, bis das geschehen ist.

Schritt drei und vier gehoren nie in dasselbe Release. Additive und subtraktive Berechtigungsanderungen haben vollig 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 zusammenfuhrbare Dateien, und Salesforce empfiehlt ein von ihnen gefuhrtes Modell. Profile behalten Sie fur Grundeinstellungen wie Lizenz, Standard-Datensatztypen und Seitenlayouts.

Werden Berechtigungen in Profilen abgeschafft?

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

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

Weil ein Profil-Retrieve nur Einstellungen fur die Metadaten derselben Anfrage zuruckgibt. Andert sich der Paketinhalt, andert 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.