So bringen Sie Salesforce Flows ohne Merge-Schmerzen unter Versionskontrolle

Kurz gesagt: Committen Sie jeden Flow als eine einzige .flow-meta.xml-Datei ohne Versionsnummer, geben Sie jedem Flow pro Änderung genau einen Owner und verbieten Sie Git, Flow-XML automatisch zu mergen. Ändern zwei Branches trotzdem denselben Flow, behalten Sie eine Seite und bauen die andere Änderung in Flow Builder nach, statt XML von Hand zu bearbeiten. Die meisten Merge-Schmerzen bei Flows entstehen durch parallele Bearbeitung und Layout-Rauschen, nicht durch Git.

Warum sind Salesforce Flows schwer zu versionieren?

Ein Flow ist kein Code, den Sie Zeile für Zeile schreiben. Er ist XML, das Flow Builder erzeugt, und darin stecken einige Fallen:

• Eine Datei enthält alles. Elemente, Konnektoren, Variablen und Formeln liegen in einer Datei, und ein großer Flow kann über 1.000 Zeilen XML umfassen.
• Das Layout wird als Daten gespeichert. Jedes Element trägt locationX- und locationY-Koordinaten, sodass das Verschieben eines Kastens einen Diff ohne jede Logikänderung erzeugt. Wechselt ein Flow zwischen Free-Form und Auto-Layout, werden die Positionen aller Elemente neu geschrieben.
• Nur die neueste Version kommt zurück. Seit Metadata API v44 tragen Flow-Dateinamen keine Versionsnummer mehr, und ein Retrieve liefert die neueste Version, aktiv oder Entwurf. So kann ein halbfertiger Entwurf unbemerkt im Repository landen.
• Versionsnummern laufen zwischen Orgs auseinander. Das Deployment eines Flows erzeugt in der Ziel-Org eine neue Version, Version 7 in Ihrer Sandbox kann also Version 3 in der Produktion sein.
• Die Zahl der Versionen ist begrenzt. Salesforce erlaubt 50 Versionen pro Flow, die Historie in der Org ersetzt also keine Git-Historie.

Wie richten Sie ein Flow-Repository ein, das sauber bleibt?

1. Nutzen Sie das Source-Format. Eine Datei pro Flow unter force-app/main/default/flows/, benannt nach dem API-Namen des Flows ohne Versionssuffix.
2. Committen Sie keine FlowDefinition mehr. Seit der Änderung in v44 steuert ein status-Feld am Flow selbst, ob er aktiv ist, und Salesforce empfiehlt Flow Definitions für die Aktivierung nicht mehr.
3. Rufen Sie per Name ab, aus der Org, in der gearbeitet wurde. Zum Beispiel sf project retrieve start --metadata Flow:Case_Escalation. Prüfen Sie den status-Wert vor dem Commit, damit nie versehentlich ein Entwurf ausgeliefert wird.
4. Verbieten Sie Git das automatische Mergen von Flows. Tragen Sie force-app/**/flows/*.flow-meta.xml -merge in .gitattributes ein. Laut gitattributes-Dokumentation behält ein deaktiviertes merge die Version Ihres Branches und meldet einen Konflikt. Verzichten Sie hier auf die Abkürzung binary, denn sie schaltet auch Diffs ab, und Flow-Änderungen wollen Sie weiterhin reviewen.

Der letzte Schritt ist der wichtigste. Ein zeilenbasierter Merge kann Flow-XML erzeugen, das vollkommen gültig und trotzdem logisch falsch ist, etwa ein Konnektor, der auf ein Element zeigt, das der andere Branch gelöscht hat. Ein erzwungener Konflikt ist billiger als ein stiller. Deshalb hält auch unser Leitfaden für einen Salesforce-fähigen Git-Merge-Driver Flows aus den Mustern des Drivers heraus: Profile und Permission Sets lassen sich gut pro Knoten mergen, Flow-Logik nicht.

Wie verhindern Sie, dass zwei Personen denselben Flow bearbeiten?

• Ein Owner pro Flow und Änderung. Reservieren Sie den Flow am Work Item, bevor jemand Flow Builder öffnet.
• Teilen Sie große Flows in Subflows auf. Parallele Arbeit landet dann in verschiedenen Dateien statt in einer gemeinsamen.
• Halten Sie Branches kurz. Mergen Sie den Basis-Branch oft ein, damit Konflikte auftauchen, solange sie klein sind.
• Wählen Sie einen Canvas-Modus pro Flow. Ein Wechsel zwischen Free-Form und Auto-Layout ändert jede Koordinate in der Datei.

Was tun, wenn zwei Branches denselben Flow ändern?

1. Mergen Sie das XML nicht von Hand. Behandeln Sie den Konflikt als Entscheidung über Logik, nicht über Text.
2. Behalten Sie die Seite mit der größeren Änderung, mit git checkout --ours oder --theirs auf der Flow-Datei.
3. Deployen Sie diese Version in eine Sandbox und bauen Sie die kleinere Änderung in Flow Builder nach.
4. Prüfen Sie das Ergebnis per Versionsvergleich. Flow Builder erhielt mit Winter '26 ein Werkzeug zum Vergleichen von Versionen, und Summer '26 ergänzte einen visuellen Modus, der neue, geänderte und gelöschte Elemente auf dem Canvas farbig markiert.
5. Rufen Sie ab, committen Sie und lassen Sie die CI validieren, bevor der gemergte Flow ins Review geht.

Für Konflikte in anderen Metadatentypen lesen Sie wie Sie Salesforce-Metadatenkonflikte während eines Merges lösen.

Wie deployen Sie Flows sicher aus Git?

• Rechnen Sie standardmäßig mit inaktiv. Flows, die in einer Sandbox aktiv sind, kommen inaktiv in der Produktion an, es sei denn, Sie aktivieren Deploy processes and flows as active in den Process Automation Settings. Diese Einstellung verlangt Apex-Testabdeckung und gilt für Prozesse und autolaunched Flows, nicht für Screen Flows.
• Machen Sie die Aktivierung zu einem expliziten Release-Schritt, nicht zu etwas, woran ein Admin hinterher denken muss.
• Führen Sie bei jedem Pull Request ein Check-only-Deployment aus, damit ein Flow, der auf ein fehlendes Feld verweist, in der CI scheitert und nicht im Release-Fenster.

Deployen Sie Flows noch mit Change Sets? Beginnen Sie mit dem Umstieg von Change Sets auf Source Control und wenden Sie danach die Schritte oben an.

Wo helfen Werkzeuge?

DevOps-Plattformen wie Gearset und Flosum ergänzen Git um Flow-fähigen Vergleich und Deployment, und Lifecycle Center von Salesforce (früher DevOps Center) liefert über seine MCP-Tools KI-Empfehlungen zur Konfliktlösung. Serpent löst Konflikte direkt im Pull Request: Serpent AI schlägt eine Lösung vor und wartet auf Ihr Review, bevor sie angewendet wird, und KI-Code-Review ist in jedem Tarif enthalten. Serpent-Tarife ansehen oder weitere Salesforce-DevOps-Leitfäden durchstöbern.

FAQ

Sollte ich FlowDefinition-Dateien committen?

Nein. Seit Metadata API v44 steuert das eigene status-Feld des Flows die Aktivierung, und Salesforce empfiehlt Flow Definitions dafür nicht mehr.

Kann Git zwei Versionen desselben Flows automatisch mergen?

Es kann einen textlich sauberen Merge erzeugen, aber Git versteht keine Flow-Logik. Erzwingen Sie mit -merge einen Konflikt und bauen Sie eine der Änderungen in Flow Builder nach.

Warum ist ein Flow-Entwurf in meinem Repository gelandet?

Ein Retrieve liefert die neueste Version des Flows, aktiv oder Entwurf. Prüfen Sie den status-Wert vor dem Commit.

Spielen Änderungen an locationX und locationY eine Rolle?

Sie ändern nur das Layout, nicht das Verhalten. Behandeln Sie sie im Review als Rauschen und wechseln Sie nicht den Canvas-Modus, dann bleiben sie stabil.