Click-Deploy-Fehler: Warum Salesforce-Deployments scheitern und wie Sie sie beheben

Kurz gesagt: Ein Click Deploy scheitert selten am Button. Er scheitert, weil die Salesforce Metadata API das Paket ablehnt, und fast jede Ablehnung fällt in fünf Gruppen: eine fehlende Abhängigkeit, zu geringe Testabdeckung, eine API-Version, die das Ziel nicht kennt, ein Größenlimit der Plattform oder eine Änderung, die die API nicht ausführen kann. Lesen Sie den ersten Fehler, beheben Sie die Ursache in der Quelle und validieren Sie erneut, bevor Sie deployen.

Was passiert, wenn Sie in Salesforce auf Deploy klicken?

Egal, in welchem Tool Sie klicken, darunter passiert dasselbe. Das Tool erstellt ein package.xml-Manifest und eine .zip-Datei mit den ausgewählten Metadaten, sendet beides an die Metadata API, und Salesforce kompiliert, führt Apex-Tests auf dem gewählten Testlevel aus und speichert das Ergebnis. Wenn Point-and-Click-Tools neu für Sie sind, beginnen Sie mit wie ClickDeploy funktioniert und was es kostet.

Zwei Plattformregeln erklären die meisten Überraschungen:

• Standardmäßig gilt alles oder nichts. Ein einziger Fehler rollt das gesamte Deployment zurück. Die Salesforce-CLI-Referenz bietet ein Flag, das Fehler ignoriert und den Rollback überspringt, und sagt ausdrücklich, es niemals bei Deployments in die Produktion zu verwenden.
• Sandboxes und Produktion testen unterschiedlich. Das Standardlevel führt in einer Sandbox keine Tests aus, während Produktions-Deployments mit Apex-Klassen oder Triggern alle lokalen Tests ausführen. Deshalb kann ein Deployment in UAT gelingen und in der Produktion scheitern.

Warum scheitern Click Deployments?

1. Eine Abhängigkeit fehlt

Das Paket verweist auf etwas, das die Ziel-Org nicht hat: ein Feld ohne sein Objekt, einen Flow ohne die Felder, die er liest, ein Child-Objekt ohne sein Parent. Copado Essentials, das Tool, das früher ClickDeploy hieß, dokumentiert einen Klassiker: Wer nur ein Detail-Objekt deployt, erhält Cannot set sharingModel to ControlledByParent on a CustomObject without a MasterDetail relationship field. Die Lösung ist, das Parent-Objekt zum Deployment hinzuzufügen, auch wenn es sich nicht geändert hat.

2. Die Apex-Testabdeckung ist zu niedrig

Salesforce verlangt, dass mindestens 75 % Ihres Apex-Codes durch Unit-Tests abgedeckt sind, um in die Produktion zu deployen, und jeder Trigger braucht mindestens eine abgedeckte Zeile. Mit RunSpecifiedTests ändert sich die Messlatte: Die angegebenen Tests müssen jede Klasse und jeden Trigger im Paket einzeln zu 75 % abdecken. Die Lösung sind bessere Tests, nicht ein anderes Testlevel.

3. Die API-Version ist neuer als das Ziel

Ein Fehler wie Invalid api version taucht meist rund um ein Release-Fenster auf, wenn Ihre Sandbox bereits das nächste Salesforce-Release nutzt und die Produktion noch nicht. Winter '27 ist ein aktuelles Beispiel: Sandboxes gingen Ende August 2026 in die Preview, während Produktionsinstanzen über mehrere Wochenenden bis in den Oktober aktualisiert werden. Prüfen Sie Ihre Instanz daher auf Salesforce Trust. Copados Empfehlung lautet, die API-Version der Komponente auf eine von der Produktion unterstützte Version zurückzusetzen und erneut zu deployen.

4. Das Paket ist zu groß

Salesforces eigene Deploy-Bibliothek source-deploy-retrieve warnt, sobald sich ein Deployment den Metadata-API-Limits von 10.000 Dateien und rund 39 MB gezippt nähert. Wildcard-Auswahlen und Deployments ganzer Objekte stoßen zuerst daran. Teilen Sie das Release auf oder liefern Sie mit Delta-Deployments nur das Geänderte aus.

5. Die API führt die Änderung nicht aus

• Aktive Flows. Copados Flow-Leitfaden hält fest, dass sich eine Flow-Version, die in der Ziel-Org aktiv ist, nicht deployen lässt. Klonen Sie sie in der Quelle als neue Version, deployen Sie diese und aktivieren Sie sie im Ziel. Außerdem warnt der Leitfaden, dass das Deployen der Komponente FlowDefinition häufig invalid version number liefert.
• Picklist-Umstellungen. Eine normale Picklist lässt sich per Deployment nicht in ein Global Value Set umwandeln. Copados Workaround ist, ein neues Feld auf Basis des Global Value Sets anzulegen und das alte stillzulegen.

Wie beheben Sie einen gescheiterten Click Deploy Schritt für Schritt?

1. Lesen Sie den ersten Fehler, nicht den letzten. Ein einziges fehlendes Feld kann Dutzende Folgefehler auslösen.
2. Bestimmen Sie die Gruppe. Abhängigkeit, Abdeckung, Version, Größe oder nicht unterstützte Änderung. Jede hat eine andere Lösung.
3. Korrigieren Sie die Quelle, nicht das Ziel. Wer die Produktion von Hand anpasst, verfälscht den nächsten Vergleich.
4. Validieren Sie erneut. Führen Sie ein Check-only-Deployment mit demselben Testlevel aus, das die Produktion verwendet.
5. Deployen Sie das validierte Paket. Unsere Click-Deploy-Checkliste behandelt Testlevel und Quick Deploy.

Was verrät Ihnen ein erfolgreicher Click Deploy nicht?

Ein grünes Deployment heißt nur, dass Salesforce das Paket akzeptiert hat. Es heißt nicht, dass das Ziel der Quelle entspricht:

• Deaktivierte Profilberechtigungen. Copado dokumentiert, dass die Metadata API deaktivierte User Permissions in abgerufenen Profilen weglässt. Eine in der Quelle abgeschaltete Berechtigung kann im Ziel also aktiv bleiben.
• Löschungen. Sie reisen separat, als Destructive Changes vor oder nach dem Deployment.
• Die Arbeit anderer. Org-zu-Org-Deployments führen keine gemeinsame Historie, daher kann ein zweites Deployment das erste unbemerkt überschreiben. Ein Deployment aus einem Git-Branch löst das.

Wer ist Tekunda, und wie reduziert Serpent gescheiterte Deployments?

Tekunda ist das Salesforce-Beratungs- und Produktunternehmen hinter Serpent, der DevOps-Plattform, die es für die eigene Kundenauslieferung nutzt. Serpent behält das Auswählen per Klick bei, aber jede Änderung durchläuft Git, einen Pull Request und eine Validierung mit Apex-Tests, bevor sie die nächste Org erreicht, mit KI-Code-Review in jedem Plan, auch im kostenlosen. In Ihrer Org wird nichts installiert. Teams, die Copado Essentials, Gearset, Salto, AutoRABIT, Flosum oder Blue Canvas nutzen, können unserem Migrationspfad folgen, und weitere Anleitungen finden Sie in der SF-Guides-Bibliothek.

FAQ

Warum gelingt mein Deployment in der Sandbox, scheitert aber in der Produktion?

Sandboxes führen standardmäßig keine Apex-Tests aus, die Produktion dagegen führt lokale Tests aus und verlangt 75 % Abdeckung. Validieren Sie zuerst gegen die Produktion mit demselben Testlevel.

Was bedeutet „invalid api version“?

Ihre Komponente nutzt eine API-Version, die die Ziel-Org noch nicht unterstützt, meist während eines Release-Fensters. Senken Sie die Version der Komponente und deployen Sie erneut.

Kann ich Fehler ignorieren und trotzdem deployen?

Die Salesforce CLI hat ein Flag, das Fehler ignoriert und den Rollback überspringt, doch ihre eigene Referenz sagt, es niemals in der Produktion zu verwenden.

Wie viele Komponenten passen in ein Deployment?

Die Metadata API begrenzt ein Deployment auf 10.000 Dateien und rund 39 MB gezippt. Teilen Sie größere Releases auf.