Zo zet je Salesforce Flows onder versiebeheer zonder mergeleed

Kort antwoord: Commit elke Flow als één .flow-meta.xml-bestand zonder versienummer, geef elke Flow per wijziging één eigenaar en laat Git Flow-XML nooit automatisch mergen. Raken twee branches toch dezelfde Flow, houd dan één kant en bouw de andere wijziging opnieuw in Flow Builder in plaats van XML met de hand te bewerken. Het meeste mergeleed bij Flows komt door parallelle bewerkingen en layoutruis, niet door Git.

Waarom zijn Salesforce Flows lastig onder versiebeheer te houden?

Een Flow is geen code die je regel voor regel schrijft. Het is XML die Flow Builder genereert, en daar zitten een paar valkuilen in:

• Eén bestand bevat alles. Elementen, connectors, variabelen en formules staan in één bestand, en een grote Flow kan meer dan 1.000 regels XML tellen.
• Layout wordt als data opgeslagen. Elk element heeft locationX- en locationY-coördinaten, dus een blok verslepen levert een diff op zonder logische wijziging. Een Flow omzetten tussen free-form en auto-layout herschrijft de posities van alle elementen.
• Alleen de nieuwste versie komt terug. Sinds Metadata API v44 hebben Flow-bestandsnamen geen versienummer meer en levert een retrieve de nieuwste versie op, actief of concept. Een half afgemaakt concept kan zo ongemerkt in je repo belanden.
• Versienummers lopen uiteen tussen orgs. Een Flow deployen maakt een nieuwe versie aan in de doelorg, dus versie 7 in je sandbox kan versie 3 in productie zijn.
• Het aantal versies is begrensd. Salesforce staat 50 versies per Flow toe, dus de historie in de org vervangt geen Git-historie.

Hoe richt je een Flow-repository in die schoon blijft?

1. Gebruik source format. Eén bestand per Flow onder force-app/main/default/flows/, genoemd naar de API-naam van de Flow zonder versieachtervoegsel.
2. Commit geen FlowDefinition meer. Sinds de wijziging in v44 bepaalt een status-veld op de Flow zelf of die actief is, en Salesforce raadt Flow Definitions voor activatie niet langer aan.
3. Haal op naam op, uit de org waar het werk gebeurde. Bijvoorbeeld sf project retrieve start --metadata Flow:Case_Escalation. Controleer de status-waarde vóór je commit, zodat er nooit per ongeluk een concept meegaat.
4. Laat Git Flows niet automatisch mergen. Zet force-app/**/flows/*.flow-meta.xml -merge in .gitattributes. Volgens de gitattributes-documentatie houdt een uitgeschakelde merge de versie van jouw branch aan en meldt een conflict. Vermijd hier de binary-snelkoppeling, want die schakelt ook diffs uit en je wilt Flow-wijzigingen nog steeds reviewen.

Die laatste stap telt het zwaarst. Een regelgebaseerde merge kan Flow-XML opleveren die volkomen geldig is en toch logisch fout, bijvoorbeeld een connector die wijst naar een element dat de andere branch heeft verwijderd. Een afgedwongen conflict is goedkoper dan een stil conflict. Daarom houdt onze gids voor een Salesforce-bewuste Git merge driver Flows ook buiten de patronen van de driver: profielen en permission sets mergen goed per node, Flow-logica niet.

Hoe voorkom je dat twee mensen dezelfde Flow bewerken?

• Eén eigenaar per Flow per wijziging. Claim de Flow op het work item voordat iemand Flow Builder opent.
• Splits grote Flows op in subflows. Parallel werk komt dan in verschillende bestanden terecht in plaats van in één gedeeld bestand.
• Houd branches kort. Merge de basisbranch vaak in, zodat conflicten opduiken zolang ze klein zijn.
• Kies één canvasmodus per Flow. Wisselen tussen free-form en auto-layout verandert elke coördinaat in het bestand.

Wat doe je als twee branches dezelfde Flow wijzigen?

1. Merge de XML niet met de hand. Behandel het conflict als een beslissing over logica, niet over tekst.
2. Houd de kant met de grootste wijziging met git checkout --ours of --theirs op het Flow-bestand.
3. Deploy die versie naar een sandbox en voer de kleinere wijziging opnieuw door in Flow Builder.
4. Controleer het resultaat met versievergelijking. Flow Builder kreeg in Winter '26 een tool om versies te vergelijken, en Summer '26 voegde een visuele modus toe die nieuwe, gewijzigde en verwijderde elementen op het canvas met kleuren markeert.
5. Haal op, commit en laat CI valideren voordat de gemergde Flow naar review gaat.

Voor conflicten in andere metadatatypes, zie hoe je Salesforce-metadataconflicten tijdens een merge oplost.

Hoe deploy je Flows veilig vanuit Git?

• Reken standaard op inactief. Flows die in een sandbox actief zijn, komen inactief in productie aan, tenzij je Deploy processes and flows as active aanzet in de Process Automation Settings. Die instelling vereist Apex-testdekking en geldt voor processen en autolaunched Flows, niet voor screen Flows.
• Maak activatie een expliciete releasestap, niet iets wat een admin achteraf moet onthouden.
• Draai bij elke pull request een check-only deployment, zodat een Flow die naar een ontbrekend veld verwijst in CI faalt en niet in het releasevenster.

Deploy je Flows nog met change sets? Begin dan met de overstap van change sets naar source control en pas daarna de stappen hierboven toe.

Waar helpt tooling?

DevOps-platforms zoals Gearset en Flosum voegen Flow-bewuste vergelijking en deployment toe bovenop Git, en Lifecycle Center van Salesforce (voorheen DevOps Center) geeft via zijn MCP-tools AI-aanbevelingen voor conflictoplossing. Serpent lost conflicten op in de pull request zelf: Serpent AI stelt een oplossing voor en wacht op jouw review voordat die wordt toegepast, en AI-codereview zit in elk abonnement. Bekijk de abonnementen van Serpent of blader door meer Salesforce DevOps-gidsen.

FAQ

Moet ik FlowDefinition-bestanden committen?

Nee. Sinds Metadata API v44 regelt het eigen status-veld van de Flow de activatie, en Salesforce raadt Flow Definitions daarvoor niet langer aan.

Kan Git twee versies van dezelfde Flow automatisch mergen?

Het kan een tekstueel schone merge opleveren, maar Git begrijpt geen Flow-logica. Dwing een conflict af met -merge en voer één wijziging opnieuw door in Flow Builder.

Waarom staat er een concept-Flow in mijn repository?

Een retrieve levert de nieuwste versie van de Flow op, actief of concept. Controleer de status-waarde voordat je commit.

Maken wijzigingen in locationX en locationY uit?

Ze veranderen alleen de layout, niet het gedrag. Beoordeel ze als ruis en wissel niet van canvasmodus, dan blijven ze stabiel.