Approval gates en audit trails instellen voor Salesforce-deployments

Kort antwoord: een approval gate is een regel die een promotie blokkeert tot een benoemd persoon die niet de auteur is aftekent. Het wordt een audit trail zodra die goedkeuring is vastgelegd bij precies die commit en die doelorg, en achteraf niet meer te wijzigen is. Richt dat eenmalig per omgeving in en u hoeft nooit meer screenshots te verzamelen.

Wat maakt een approval gate auditbaar?

Een gate die alleen in iemands gewoontes bestaat is geen control. Vier eigenschappen maken er bewijs van:

• Afgedwongen. De promotie is technisch onmogelijk zonder de goedkeuring, niet alleen afgeraden.
• Toegewezen. De goedkeurder is een geauthenticeerde identiteit, geen naam die in een ticket is getypt.
• Gebonden. De goedkeuring wijst naar een specifieke commit en een specifieke doelorg, zodat die niet hergebruikt kan worden voor een andere lading.
• Onveranderlijk. Niemand, ook beheerders niet, kan het record achteraf aanpassen.

Ontbreekt er een, dan beschouwt een auditor de hele control als onbetrouwbaar, hoe mooi het proces er op een slide ook uitziet.

Wie keurt wat goed, in welke omgeving?

De meeste teams zetten of nergens een gate of overal, en beide falen. Gate op risico, en leg het vast:

• Feature- of scratch org: geen gate. Snelheid telt hier zwaarder, en niets stroomafwaarts vertrouwt erop.
• Integratie of QA: alleen geautomatiseerde checks. Tests, dekking en statische of AI-code review moeten slagen. Geen menselijke aftekening.
• UAT of staging: een menselijke goedkeurder, meestal de tech lead, plus de geautomatiseerde checks. Hier zijn ontwerpfouten nog goedkoop.
• Productie: twee goedkeurders. Een technische reviewer die niet de auteur is, plus de business owner van het geraakte proces. Voeg een releasevenster toe zodat goedkeuringen niet om 23:00 op vrijdag worden verzameld.
• Productiehotfix: een goedkeurder, met een verplicht work item achteraf binnen 24 uur. Definieer het pad in plaats van te doen alsof het niet gebruikt wordt.

Twee goedkeuringen in productie is geen bureaucratie. Het is de kleinste inrichting die functiescheiding onder SOX-achtige toetsing overleeft, en het kost ongeveer vijf minuten.

Hoe richt u de gates in?

1. Haal deployrechten weg bij mensen in productie. Alleen de integratie-identiteit van de pipeline heeft daar Modify Metadata en Modify All Data. Deze ene wijziging maakt elke andere gate echt, want er is geen omweg.
2. Zet branch protection aan op de branch die naar productie wijst. Eis pull requests, eis minstens een goedkeurende review en zet zelfgoedkeuring uit.
3. Maak de checks verplicht, niet adviserend. Apex-tests, dekkingsdrempel, statische analyse of geautomatiseerde code review moeten blokkerende status checks zijn. Een check die genegeerd kan worden is geen gate.
4. Voeg een goedkeuring op omgevingsniveau toe voor productie. Branch protection dekt de merge, de omgevingsgate dekt de deploy. U wilt beide, want ze beantwoorden verschillende auditvragen.
5. Verval goedkeuringen bij nieuwe commits. Anders kan een goedgekeurde pull request na aftekening nog worden aangepast, wat de gebondenheid hierboven stilletjes breekt.
6. Benoem goedkeurdersgroepen per rol, niet per persoon. Mensen vertrekken. Rollen zijn waar de auditor tegen toetst.

Elk gangbaar Salesforce DevOps-platform ondersteunt dit patroon, waaronder Copado, Gearset, AutoRABIT, Flosum, Blue Canvas en Serpent, net als kaal GitHub of GitLab voor de CLI. De inrichting telt, niet het logo erop.

Wat moet het deployrecord bevatten?

Als een auditor tien releases steekproefsgewijs pakt, moet elke release oplossen naar een record met:

• Het work item en de zakelijke reden.
• De commit SHA en de metadata-diff.
• De identiteiten van de goedkeurders, met tijdstempels, en of de auteur ertussen zit.
• Het testresultaat en de dekking op het moment van deployen, niet het cijfer van vandaag.
• De doelorg, de deploy-ID en de uitkomst, inclusief gedeeltelijke fouten.
• Elke uitzonderingsmarkering, zoals een break-glass release.

Bewaar dat buiten de org. Records die alleen in Salesforce leven verlopen, en auditcycli zijn jaarlijks.

Waarom native Salesforce-logs op zichzelf niet genoeg zijn

Ze zijn het aanzetten waard, maar ken de randen:

• Setup Audit Trail bewaart 180 dagen, toont in de UI alleen de recentste regels en legt geen oude en nieuwe waarden vast. Download de CSV volgens schema of bevraag het object SetupAuditTrail.
• Field History Tracking is begrensd op 20 velden per object, bewaart ongeveer 18 maanden in de UI en 24 via de API, en kan geen formule-, roll-up summary- of autonummervelden volgen. Field Audit Trail met Shield verlengt de bewaring via beleid.
• Geen van beide vertelt of een wijziging is goedgekeurd. Ze leggen vast dat iets veranderde, niet dat het mocht.

Die laatste regel is de reden dat het pipelinerecord het primaire bewijs is en de orglogs de bevestiging.

Hoe voorkomt u wijzigingen die de gate omzeilen?

De meest voorkomende bevinding is geen slechte goedkeuring, maar een wijziging die nooit door de pipeline ging: een beheerder die dinsdagmiddag een validatieregel in productie aanpast. Dicht dat met drie gewoontes.

1. Draai drift detection volgens schema en vergelijk de productie-org met de branch. Alles wat in de org staat en niet in Git is een niet-goedgekeurde wijziging of een gat in uw registratie.
2. Reconcilieer wekelijks tegen Setup Audit Trail. Elke regel moet terug te voeren zijn op een deploy of een gedocumenteerde uitzondering.
3. Behandel herhaalde drift als procesfout. Blijven beheerders om de pipeline heen gaan, dan is de pipeline te traag voor hun werk. Repareer de wrijving, niet de mensen.

Draaien die drie, dan stopt de jaarlijkse audit een project te zijn. Meer inrichtingsgidsen zoals deze staan in onze SF Guides-bibliotheek.

FAQ

Hoeveel goedkeurders heeft een productiedeploy nodig?

Twee is de praktische standaard: een technische reviewer die niet de auteur is, plus de business owner van het geraakte proces. Een volstaat bij een gedocumenteerde hotfix.

Mag degene die de wijziging schreef die goedkeuren?

Nee. Dat breekt functiescheiding en is het eerste dat een auditor toetst. Zet zelfgoedkeuring uit in branch protection, zodat de regel wordt afgedwongen en niet onthouden.

Vertragen approval gates de releases?

Zelden, mits u per omgeving gate. Lagere omgevingen blijven ongegate met alleen geautomatiseerde checks, dus de menselijke stap gebeurt eenmalig, waar een fout echt duur is.

Is Setup Audit Trail op zichzelf voldoende bewijs?

Nee. Het bewaart 180 dagen, laat oude en nieuwe waarden weg en toont dat er iets veranderde, niet dat het was goedgekeurd. Gebruik het om uw pipelinerecords te bevestigen.