Org drift: waarom je Salesforce-sandboxen niet meer op productie lijken

Kort antwoord: org drift is de opgetelde kostenpost van elke wijziging die een org bereikte zonder door je proces te gaan. Het komt niet door een slechte admin of een overgeslagen review, het is de som van honderden kleine, legitieme uitzonderingen. En de kwartaalrefresh waar de meeste teams op leunen kan het niet oplossen, want refreshes gebeuren op zijn best maandelijks terwijl drift dagelijks ontstaat.

Wat is org drift?

Org drift is het verschil tussen wat een omgeving bevat en wat je bron van waarheid zegt dat er in hoort. Tussen sandbox en productie, tussen twee sandboxen, of tussen productie en de repository die haar zou moeten beschrijven.

Het symptoom dat iedereen herkent: een wijziging die elke test in een sandbox doorstond, faalt onderweg naar productie. De oorzaak is bijna nooit de wijziging. De oorzaak is dat de sandbox geen eerlijke test meer was.

Waar komt drift vandaan?

Vrijwel alles komt van wijzigingen die op dat moment redelijk waren:

• Configuratie direct in productie. Een picklistwaarde die vrijdag is toegevoegd omdat een deal het nodig had. Juiste beslissing, onzichtbaar voor je repo.
• Hotfixes die nooit terug zijn gemerged. De fix ging live. De branch waar hij had moeten landen kreeg hem niet.
• Packages die in een omgeving zijn geinstalleerd. Iemand installeert een app in een sandbox om hem te beoordelen, of in productie om een team te deblokkeren.
• Rechten die bij uitzondering zijn gegeven. Profielen en permission sets driften in de meeste orgs het snelst en staan het minst vaak in versiebeheer.
• Omgevingsspecifieke instellingen die nooit gelijk hoefden te zijn. Endpoints, named credentials, e-mailinstellingen, geplande jobs. Dit is legitieme drift, en die moet je alsnog vastleggen, want als je legitieme drift niet van toevallige drift kunt onderscheiden ga je beide negeren.
• Het releaseschema van Salesforce zelf. Instances upgraden op verschillende momenten, dus twee omgevingen kunnen echt even op verschillende platformversies draaien.

Niets daarvan is nalatigheid. Het is een systeem dat wijzigingen via meer dan een deur binnenlaat.

Waarom lost de kwartaalrefresh het niet op?

Het refreshritueel gaat ervan uit dat drift periodiek te resetten is. Kijk naar de cadans die Salesforce toestaat: Developer- en Developer Pro-sandboxen kunnen ongeveer een keer per dag worden ververst, Partial Copy elke vijf dagen en Full sandboxen elke 29 dagen (zie de documentatie over sandboxtypes).

De omgeving die het meest telt voor realistisch testen, de Full sandbox, heeft dus een harde ondergrens van ongeveer een maand. In de praktijk ververst niemand op maximale snelheid, want een refresh wist werk dat onderweg is, vereist datamaskering en opnieuw seeden, en kost een team daarna dagen inrichting. Per kwartaal is het eerlijke getal.

Ondertussen ontstaat drift elke dag opnieuw. Je lost een dagelijks probleem niet op met een kwartaalritueel. De refresh is niet nutteloos, hij zet alleen een teller terug die meteen weer begint te lopen, en tussen refreshes verzwakt je vertrouwen in de testomgeving continu zonder dat iemand het meet.

Wat kost drift echt?

• Mislukte deployments. De zichtbare kostenpost, en de kleinste.
• Vals vertrouwen. Veel erger. Tests die slagen tegen een gedrifte sandbox zeggen niets, en je merkt het pas in productie.
• Langere schattingen. Teams bouwen buffer in voor deployverrassingen. Die buffer is drift, ingeprijsd.
• Rollbacks die niet volledig terugdraaien. Als productie config bevat die je repo nooit had, is terug naar de repo geen terugkeer naar een bekende toestand.
• Auditrisico. "Wat staat er in productie en wie heeft het gezet" hoort een antwoord te hebben.

Hoe ziet continue driftdetectie eruit?

1. Benoem een bron van waarheid. Meestal Git. Al het andere wordt daartegen vergeleken. Zonder die stap levert driftdetectie twee lijsten op en geen oordeel.
2. Maak elke omgeving volgens schema een snapshot. Dagelijks verslaat wekelijks. De waarde zit in het betrappen van een wijziging terwijl de maker nog weet waarom.
3. Classificeer het verschil, toon het niet alleen. Drie bakken: verwachte omgevingsverschillen, geaccepteerde uitzonderingen met eigenaar en einddatum, en echte ongeplande drift.
4. Stuur het direct naar een mens. Een driftrapport zonder verantwoordelijke is een dashboard, geen controle.
5. Sluit de lus terug naar de repo. Legitieme productiewijzigingen horen vastgelegd te worden in source, niet alleen gemarkeerd. Anders meldt elke cyclus eeuwig hetzelfde item.

De meeste tools in deze categorie kunnen twee omgevingen vergelijken. Wat verschil maakt is of de vergelijking volgens schema draait zonder dat iemand eraan moet denken, of de uitvoer geclassificeerd is in plaats van rauw, en of het aan dezelfde pipeline hangt die deployt.

Dat is het ontwerpuitgangspunt van Serpent: driftdetectie staat naast delta-deployments, one-click rollback en AI-codereview die governance-drift bij elke wijziging markeert, en het draait via standaard-API's zonder iets in je org te installeren. Detectie en deployment op een plek betekent dat de fix een handeling is en geen ticket voor een ander team.

Wat doe je deze week?

Pak je meest bedrijfskritische sandbox en vergelijk hem een keer met productie. Sorteer de uitkomsten in "verwacht", "hier wisten we van" en "wie heeft dit gedaan". Is de derde bak de grootste, plan dan geen refreshes meer maar vergelijkingen.

FAQ

Wat veroorzaakt Salesforce org drift?

Wijzigingen die buiten het deployproces een org bereiken: directe productieconfig, niet teruggemergede hotfixes, packages in een omgeving, rechtenwijzigingen, en legitieme omgevingsspecifieke instellingen die nooit als zodanig zijn vastgelegd.

Lost een sandboxrefresh drift op?

Alleen even. Full sandboxen kunnen op zijn best elke 29 dagen ververst worden en de meeste teams halen een kwartaal, terwijl drift dagelijks aangroeit.

Hoe vaak moet je op drift controleren?

Dagelijks voor productie en elke omgeving die je voor releasevalidatie gebruikt. Trager en je verliest de context om te verklaren wat er veranderde.

Is alle drift slecht?

Nee. Endpoints, credentials en geplande jobs horen te verschillen. Het probleem is niet dat er verschillen zijn, maar dat niet-vastgelegde verschillen niet te onderscheiden zijn van fouten.