Approval Gates und Audit Trails für Salesforce-Deployments einrichten

Kurze Antwort: Ein Approval Gate ist eine Regel, die eine Promotion blockiert, bis eine benannte Person, die nicht der Autor ist, freigibt. Zum Audit Trail wird es, wenn die Freigabe am exakten Commit und der Ziel-Org festgehalten ist und danach nicht mehr geändert werden kann. Einmal pro Umgebung konfiguriert, sammeln Sie nie wieder Screenshots.

Was macht ein Approval Gate prüfbar?

Ein Gate, das nur in Gewohnheiten existiert, ist keine Kontrolle. Vier Eigenschaften machen daraus einen Nachweis:

• Erzwungen. Die Promotion ist ohne Freigabe technisch unmöglich, nicht nur unerwünscht.
• Zugeordnet. Der Freigeber ist eine authentifizierte Identität, kein Name in einem Ticket.
• Gebunden. Die Freigabe zeigt auf einen konkreten Commit und eine konkrete Ziel-Org und lässt sich nicht für andere Inhalte wiederverwenden.
• Unveränderlich. Niemand, auch keine Admins, kann den Datensatz nachträglich anpassen.

Fehlt eine davon, hält der Auditor die gesamte Kontrolle für unzuverlässig, egal wie gut der Prozess auf einer Folie aussieht.

Wer gibt was frei, in welcher Umgebung?

Die meisten Teams sichern gar nichts oder alles ab, und beides scheitert. Sichern Sie nach Risiko und schreiben Sie es auf:

• Feature- oder Scratch-Org: kein Gate. Hier zählt Tempo, und nichts stromabwärts vertraut darauf.
• Integration oder QA: nur automatisierte Prüfungen. Tests, Coverage und statische oder KI-gestützte Code-Reviews müssen bestehen. Keine menschliche Freigabe.
• UAT oder Staging: ein menschlicher Freigeber, meist der Tech Lead, plus die automatisierten Prüfungen. Hier sind Designfehler noch billig.
• Produktion: zwei Freigeber. Ein technischer Reviewer, der nicht der Autor ist, plus der Business Owner des betroffenen Prozesses. Ergänzen Sie ein Release-Fenster, damit Freigaben nicht freitags um 23 Uhr eingesammelt werden.
• Produktions-Hotfix: ein Freigeber, mit verpflichtendem Work Item innerhalb von 24 Stunden. Definieren Sie den Weg, statt so zu tun, als werde er nie genutzt.

Zwei Freigaben in der Produktion sind keine Bürokratie. Es ist die kleinste Konfiguration, die einer SOX-artigen Prüfung der Funktionstrennung standhält, und sie kostet etwa fünf Minuten.

Wie konfigurieren Sie die Gates?

1. Nehmen Sie Menschen die Deploy-Rechte in der Produktion. Nur die Integrationsidentität der Pipeline hält dort Modify Metadata und Modify All Data. Diese eine Änderung macht jedes weitere Gate real, weil es keinen Umweg mehr gibt.
2. Aktivieren Sie Branch Protection auf dem Branch, der auf die Produktion zeigt. Fordern Sie Pull Requests, mindestens ein genehmigendes Review, und deaktivieren Sie Selbstfreigabe.
3. Machen Sie Prüfungen verbindlich, nicht beratend. Apex-Tests, Coverage-Schwelle, statische Analyse oder automatisierte Code-Reviews müssen blockierende Status Checks sein. Eine ignorierbare Prüfung ist kein Gate.
4. Ergänzen Sie eine Freigabe auf Umgebungsebene für die Produktion. Branch Protection deckt den Merge ab, das Umgebungs-Gate den Deploy. Sie wollen beides, weil sie unterschiedliche Auditorenfragen beantworten.
5. Verwerfen Sie veraltete Freigaben bei neuen Commits. Sonst lässt sich ein freigegebener Pull Request nachträglich ändern, was die Bindung oben still bricht.
6. Benennen Sie Freigabegruppen nach Rolle, nicht nach Person. Menschen gehen. Rollen sind das, wogegen der Auditor prüft.

Jede gängige Salesforce-DevOps-Plattform unterstützt dieses Muster, darunter Copado, Gearset, AutoRABIT, Flosum, Blue Canvas und Serpent, ebenso GitHub oder GitLab vor der CLI. Es zählt die Konfiguration, nicht das Logo.

Was muss der Deployment-Datensatz enthalten?

Wenn ein Auditor zehn Releases zieht, muss jedes auf einen Datensatz auflösen mit:

• dem Work Item und seiner fachlichen Begründung,
• dem Commit-SHA und dem Metadaten-Diff,
• den Identitäten der Freigeber mit Zeitstempeln und ob der Autor darunter ist,
• dem Testergebnis und der Coverage zum Zeitpunkt des Deployments, nicht dem heutigen Wert,
• der Ziel-Org, der Deploy-ID und dem Ergebnis, inklusive Teilfehlern,
• jedem Ausnahmekennzeichen, etwa einem Break-Glass-Release.

Speichern Sie das außerhalb der Org. Datensätze, die nur in Salesforce leben, laufen ab, und Audit-Zyklen sind jährlich.

Warum native Salesforce-Logs allein nicht reichen

Sie lohnen sich, aber kennen Sie die Kanten:

• Setup Audit Trail hält 180 Tage, zeigt in der UI nur die jüngsten Einträge und erfasst keine Vorher- und Nachher-Werte. Laden Sie die CSV planmäßig oder fragen Sie das Objekt SetupAuditTrail ab.
• Field History Tracking ist auf 20 Felder pro Objekt begrenzt, behält rund 18 Monate in der UI und 24 über die API und kann Formel-, Roll-up-Summary- und Auto-Nummer-Felder nicht verfolgen. Field Audit Trail mit Shield verlängert die Aufbewahrung per Richtlinie.
• Keines von beiden sagt, ob eine Änderung freigegeben war. Sie halten fest, dass sich etwas geändert hat, nicht dass es erlaubt war.

Diese letzte Zeile ist der Grund, warum der Pipeline-Datensatz der Hauptnachweis ist und die Org-Logs die Bestätigung.

Wie verhindern Sie Änderungen, die das Gate umgehen?

Der häufigste Befund ist keine schlechte Freigabe, sondern eine Änderung, die nie durch die Pipeline lief: ein Admin, der dienstagnachmittags eine Validierungsregel in der Produktion anpasst. Schließen Sie das mit drei Gewohnheiten.

1. Lassen Sie Drift-Erkennung planmäßig laufen und vergleichen Sie die Produktions-Org mit dem Branch. Alles, was in der Org steht und in Git fehlt, ist entweder eine nicht freigegebene Änderung oder eine Lücke in Ihrer Erfassung.
2. Gleichen Sie wöchentlich mit dem Setup Audit Trail ab. Jeder Eintrag muss auf ein Deployment oder eine dokumentierte Ausnahme zeigen.
3. Behandeln Sie wiederkehrenden Drift als Prozessfehler. Wenn Admins die Pipeline dauerhaft umgehen, ist sie für ihre Arbeit zu langsam. Beheben Sie die Reibung, nicht die Menschen.

Laufen diese drei, hört das Jahresaudit auf, ein Projekt zu sein. Weitere Konfigurationsleitfäden finden Sie in unserer SF-Guides-Bibliothek.

FAQ

Wie viele Freigeber braucht ein Produktions-Deployment?

Zwei sind der praktische Standard: ein technischer Reviewer, der nicht der Autor ist, plus der Business Owner des betroffenen Prozesses. Für einen dokumentierten Hotfix reicht einer.

Darf der Autor seine eigene Änderung freigeben?

Nein. Das bricht die Funktionstrennung und ist das Erste, was ein Auditor prüft. Deaktivieren Sie Selbstfreigabe im Branch Protection, damit die Regel erzwungen und nicht erinnert wird.

Bremsen Approval Gates Releases?

Selten, wenn Sie nach Umgebung abstufen. Untere Umgebungen bleiben ohne Gate und nur mit automatisierten Prüfungen, der menschliche Schritt passiert einmal, dort wo ein Fehler wirklich teuer ist.

Reicht der Setup Audit Trail als Nachweis?

Nein. Er hält 180 Tage, lässt Vorher- und Nachher-Werte aus und zeigt, dass sich etwas geändert hat, nicht dass es freigegeben war. Nutzen Sie ihn zur Bestätigung Ihrer Pipeline-Datensätze.