Comment versionner vos Flows Salesforce sans douleur au merge

En bref : commitez chaque Flow sous la forme d'un seul fichier .flow-meta.xml sans numéro de version, donnez à chaque Flow un seul propriétaire par changement et interdisez à Git de merger automatiquement le XML des Flows. Quand deux branches touchent malgré tout le même Flow, gardez un côté et refaites l'autre changement dans Flow Builder au lieu d'éditer le XML à la main. L'essentiel de la douleur vient des modifications parallèles et du bruit de mise en page, pas de Git.

Pourquoi les Flows Salesforce sont-ils difficiles à versionner ?

Un Flow n'est pas du code écrit ligne par ligne. C'est du XML généré par Flow Builder, avec quelques pièges :

• Un seul fichier contient tout. Éléments, connecteurs, variables et formules vivent dans un seul fichier, et un gros Flow peut dépasser 1 000 lignes de XML.
• La mise en page est stockée comme donnée. Chaque élément porte des coordonnées locationX et locationY : déplacer une boîte produit un diff sans aucun changement de logique. Basculer un Flow entre free-form et auto-layout réécrit la position de tous les éléments.
• Seule la dernière version revient. Depuis la Metadata API v44, les noms de fichiers des Flows ne portent plus de numéro de version et un retrieve renvoie la dernière version, active ou brouillon. Un brouillon inachevé peut ainsi entrer dans votre dépôt sans que personne ne le remarque.
• Les numéros de version divergent entre orgs. Déployer un Flow crée une nouvelle version dans l'org cible : la version 7 de votre sandbox peut être la version 3 en production.
• Le nombre de versions est plafonné. Salesforce autorise 50 versions par Flow : l'historique de l'org ne remplace pas l'historique Git.

Comment monter un dépôt de Flows qui reste propre ?

1. Utilisez le source format. Un fichier par Flow sous force-app/main/default/flows/, nommé d'après le nom d'API du Flow, sans suffixe de version.
2. Arrêtez de commiter FlowDefinition. Depuis le changement de la v44, un champ status sur le Flow lui-même indique s'il est actif, et Salesforce ne recommande plus les Flow Definitions pour l'activation.
3. Récupérez par nom, depuis l'org où le travail a été fait. Par exemple sf project retrieve start --metadata Flow:Case_Escalation. Vérifiez la valeur de status avant de commiter, pour qu'un brouillon ne parte jamais par erreur.
4. Interdisez à Git de merger les Flows automatiquement. Ajoutez force-app/**/flows/*.flow-meta.xml -merge à .gitattributes. Selon la documentation gitattributes, un attribut merge désactivé garde la version de votre branche et déclare un conflit. Évitez ici le raccourci binary, qui désactive aussi les diffs, alors que vous voulez continuer à relire les changements de Flow.

Cette dernière étape est la plus importante. Un merge ligne par ligne peut produire un XML de Flow parfaitement valide mais logiquement faux, par exemple un connecteur qui pointe vers un élément supprimé par l'autre branche. Un conflit forcé coûte moins cher qu'un conflit silencieux. C'est aussi pourquoi notre guide du merge driver Git adapté à Salesforce laisse les Flows hors des motifs du driver : profils et permission sets se mergent bien nœud par nœud, la logique d'un Flow non.

Comment éviter que deux personnes modifient le même Flow ?

• Un propriétaire par Flow et par changement. Réservez le Flow sur le work item avant que quiconque ouvre Flow Builder.
• Découpez les gros Flows en subflows. Le travail parallèle atterrit alors dans des fichiers différents plutôt que dans un seul fichier partagé.
• Gardez des branches courtes. Mergez souvent la branche de base pour que les conflits apparaissent tant qu'ils sont petits.
• Choisissez un seul mode de canvas par Flow. Passer de free-form à auto-layout modifie chaque coordonnée du fichier.

Que faire quand deux branches modifient le même Flow ?

1. Ne mergez pas le XML à la main. Traitez le conflit comme une décision de logique, pas de texte.
2. Gardez le côté qui porte le plus gros changement avec git checkout --ours ou --theirs sur le fichier du Flow.
3. Déployez cette version dans une sandbox et refaites le plus petit changement dans Flow Builder.
4. Vérifiez le résultat avec la comparaison de versions. Flow Builder a reçu un outil de comparaison de versions avec Winter '26, et Summer '26 a ajouté un mode visuel qui colore sur le canvas les éléments créés, modifiés et supprimés.
5. Récupérez, commitez et laissez la CI valider le Flow mergé avant la revue.

Pour les conflits sur les autres types de métadonnées, consultez comment résoudre les conflits de métadonnées Salesforce pendant un merge.

Comment déployer des Flows depuis Git en toute sécurité ?

• Attendez-vous à un état inactif par défaut. Les Flows actifs en sandbox arrivent inactifs en production, sauf si vous activez Deploy processes and flows as active dans les Process Automation Settings. Ce réglage impose une couverture de tests Apex et concerne les processus et les Flows autolaunched, pas les screen Flows.
• Faites de l'activation une étape explicite de la release, pas un geste dont un admin doit se souvenir après coup.
• Lancez un déploiement check-only sur chaque pull request, pour qu'un Flow qui référence un champ manquant échoue en CI et non pendant la fenêtre de release.

Vous déployez encore vos Flows avec des change sets ? Commencez par passer des change sets au contrôle de source, puis appliquez les étapes ci-dessus.

Où les outils aident-ils ?

Des plateformes DevOps comme Gearset et Flosum ajoutent au-dessus de Git une comparaison et un déploiement qui comprennent les Flows, et Lifecycle Center de Salesforce (anciennement DevOps Center) propose, via ses outils MCP, des recommandations IA pour résoudre les conflits. Serpent résout les conflits directement dans la pull request : Serpent AI propose une résolution et attend votre revue avant de l'appliquer, et la revue de code IA est incluse dans chaque offre. Découvrez les offres Serpent, ou parcourez d'autres guides Salesforce DevOps.

FAQ

Faut-il commiter les fichiers FlowDefinition ?

Non. Depuis la Metadata API v44, c'est le champ status du Flow qui pilote l'activation, et Salesforce ne recommande plus les Flow Definitions pour cela.

Git peut-il merger automatiquement deux versions du même Flow ?

Il peut produire un merge propre sur le plan textuel, mais Git ne comprend pas la logique d'un Flow. Forcez un conflit avec -merge et refaites un des changements dans Flow Builder.

Pourquoi un Flow en brouillon s'est-il retrouvé dans mon dépôt ?

Un retrieve renvoie la dernière version du Flow, active ou brouillon. Vérifiez la valeur de status avant de commiter.

Les changements de locationX et locationY comptent-ils ?

Ils ne modifient que la mise en page, pas le comportement. Relisez-les comme du bruit, et évitez de changer de mode de canvas pour qu'ils restent stables.