Click deploy-fouten: waarom Salesforce-deployments mislukken en hoe je ze oplost

TL;DR: Een click deploy mislukt zelden door de knop. Hij mislukt omdat de Salesforce Metadata API het pakket weigert, en bijna elke weigering valt in vijf groepen: een ontbrekende afhankelijkheid, te weinig testdekking, een API-versie die het doel niet kent, een platformlimiet op omvang, of een wijziging die de API niet kan doorvoeren. Lees de eerste fout, los de oorzaak op in de bron en valideer opnieuw voordat je deployt.

Wat gebeurt er als je in Salesforce op deploy klikt?

In welke tool je ook klikt, eronder gebeurt hetzelfde. De tool bouwt een package.xml-manifest en een .zip van de geselecteerde metadata, stuurt die naar de Metadata API, en Salesforce compileert het, draait Apex-tests op het gekozen testniveau en slaat het resultaat op. Ben je nieuw met point-and-click tools, begin dan met hoe ClickDeploy werkt en wat het kost.

Twee platformregels verklaren de meeste verrassingen:

• Standaard is het alles of niets. Eén fout draait de hele deployment terug. De Salesforce CLI-referentie biedt een vlag om fouten te negeren en de rollback over te slaan, en zegt die nooit te gebruiken bij een deployment naar productie.
• Sandboxes en productie testen anders. Het standaardniveau draait geen tests in een sandbox, terwijl productiedeployments met Apex-classes of triggers alle lokale tests draaien. Daarom kan een deploy in UAT slagen en in productie mislukken.

Waarom mislukken click deployments?

1. Er ontbreekt een afhankelijkheid

Het pakket verwijst naar iets wat de doelorg niet heeft: een veld zonder zijn object, een Flow zonder de velden die hij leest, een child-object zonder zijn parent. Copado Essentials, de tool die vroeger ClickDeploy heette, beschrijft een klassiek geval: alleen een detailobject deployen geeft Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field. De oplossing is het parent-object aan de deployment toe te voegen, ook als het niet gewijzigd is.

2. De Apex-testdekking is te laag

Salesforce vereist dat minstens 75% van je Apex door unittests gedekt is om naar productie te deployen, en elke trigger heeft minstens één gedekte regel nodig. Kies je RunSpecifiedTests, dan verandert de lat: de tests die je noemt moeten elk class en elke trigger in het pakket afzonderlijk voor 75% dekken. De oplossing is betere tests, niet een ander testniveau.

3. De API-versie is nieuwer dan het doel

Een fout als Invalid api version verschijnt meestal rond een releasemoment, wanneer je sandbox al de volgende Salesforce-release draait en productie nog niet. Winter '27 is een actueel voorbeeld: sandboxes gingen eind augustus 2026 naar de preview, terwijl productie-instances over meerdere weekenden tot in oktober upgraden, dus controleer je instance op Salesforce Trust. Het advies van Copado is de API-versie van het component terug te zetten naar een versie die productie ondersteunt en opnieuw te deployen.

4. Het pakket is te groot

De eigen deploybibliotheek van Salesforce, source-deploy-retrieve, waarschuwt wanneer een deployment de Metadata API-limieten van 10.000 bestanden en ongeveer 39 MB gezipt nadert. Wildcardselecties en volledige objectdeploys lopen hier het eerst tegenaan. Splits de release, of lever alleen wat veranderd is met delta deployments.

5. De API voert de wijziging niet uit

• Actieve Flows. De Flow-handleiding van Copado meldt dat je geen Flow-versie kunt deployen die in de doelorg actief is. Kloon hem naar een nieuwe versie in de bron, deploy die en activeer hem in het doel. Ook waarschuwt de handleiding dat het deployen van het FlowDefinition-component vaak invalid version number oplevert.
• Picklist-conversies. Een gewone picklist kan niet via een deployment worden omgezet naar een global value set. De workaround van Copado is een nieuw veld op de global value set te maken en het oude uit te faseren.

Hoe los je een mislukte click deploy stap voor stap op?

1. Lees de eerste fout, niet de laatste. Eén ontbrekend veld kan tientallen vervolgfouten veroorzaken.
2. Benoem de groep. Afhankelijkheid, dekking, versie, omvang of niet-ondersteunde wijziging. Elke groep heeft een andere oplossing.
3. Repareer de bron, niet het doel. Productie met de hand bijwerken laat de volgende vergelijking liegen.
4. Valideer opnieuw. Draai een check-only deployment met hetzelfde testniveau dat productie gebruikt.
5. Deploy het gevalideerde pakket. Onze click deploy-checklist behandelt testniveaus en quick deploy.

Wat vertelt een geslaagde click deploy je niet?

Een groene deploy betekent alleen dat Salesforce het pakket accepteerde. Het betekent niet dat het doel gelijk is aan de bron:

• Uitgeschakelde profielrechten. Copado documenteert dat de Metadata API uitgeschakelde user permissions weglaat uit opgehaalde profielen, zodat een recht dat in de bron uit staat in het doel aan kan blijven.
• Verwijderingen. Die gaan apart mee, als destructive changes vóór of na de deploy.
• Werk van een ander. Org-naar-org deploys houden geen gedeelde geschiedenis bij, dus een tweede deploy kan de eerste ongemerkt overschrijven. Deployen vanuit een Git-branch lost dat op.

Wie is Tekunda, en hoe voorkomt Serpent mislukte deploys?

Tekunda is het Salesforce-consultancy- en productbedrijf achter Serpent, het DevOps-platform dat het voor zijn eigen klantdelivery gebruikt. Serpent behoudt het klik-en-selecteer-gevoel, maar elke wijziging gaat via Git, een pull request en een validatie met Apex-tests voordat hij de volgende org bereikt, met AI-codereview op elk abonnement, ook het gratis abonnement. Er wordt niets in je org geïnstalleerd. Teams op Copado Essentials, Gearset, Salto, AutoRABIT, Flosum of Blue Canvas kunnen ons migratiepad volgen, en meer handleidingen staan in de SF Guides-bibliotheek.

FAQ

Waarom slaagt mijn deployment in een sandbox maar mislukt hij in productie?

Sandboxes draaien standaard geen Apex-tests, terwijl productie lokale tests draait en 75% dekking afdwingt. Valideer eerst tegen productie met hetzelfde testniveau.

Wat betekent "invalid api version"?

Je component gebruikt een API-versie die de doelorg nog niet ondersteunt, meestal tijdens een releasemoment. Verlaag de versie van het component en deploy opnieuw.

Kan ik fouten negeren en toch deployen?

De Salesforce CLI heeft een vlag om fouten te negeren die de rollback overslaat, maar de eigen referentie zegt die nooit in productie te gebruiken.

Hoeveel componenten kan één deployment bevatten?

De Metadata API begrenst een deployment op 10.000 bestanden en ongeveer 39 MB gezipt. Splits grotere releases.