Migrer de Process Builder vers Flow : guide pratique

Salesforce a officiellement retiré Process Builder et les Workflow Rules de la création pour les nouvelles organisations, et pousse activement à la migration des automatisations existantes vers Flow Builder. Si votre org compte encore des processus historiques, voici une méthode structurée pour les migrer sans casser la production.

Pourquoi migrer maintenant

• Process Builder et Workflow Rules ne bénéficient plus d'évolutions fonctionnelles et seront retirés à terme des orgs existantes.
• Flow Builder est plus performant : il regroupe les opérations DML et évite les recalculs multiples déclenchés par plusieurs automatisations séparées sur un même objet.
• Un seul outil à maîtriser simplifie la formation des équipes et la maintenance.
• Salesforce fournit un outil natif de migration assistée pour accélérer la conversion.

L'outil Migrate to Flow

Depuis Configuration > Flux, l'onglet « Migrer vers le flux » liste tous les Process Builder et Workflow Rules actifs et propose une conversion automatique en Record-Triggered Flow. L'outil gère la majorité des éléments standards (mises à jour de champs, création d'enregistrements, actions e-mail), mais certains éléments nécessitent une reprise manuelle :

• Les actions Apex invoquées dans l'ancien processus doivent être vérifiées : leur signature doit être compatible avec l'appel depuis Flow.
• Les tâches planifiées (« Enregistrement immédiat » vs « Actions planifiées ») se traduisent différemment en Flow et méritent une relecture.
• Les formules complexes imbriquées sont converties mais doivent être testées pour confirmer un résultat identique.

Méthode de migration recommandée

1. Inventoriez tous les Process Builder et Workflow Rules actifs par objet, avec leur objectif métier documenté (Configuration > Processus Builder / Règles de workflow).
2. Priorisez par criticité et par objet : commencez par les objets à faible volume et faible criticité pour valider votre méthode avant de vous attaquer aux processus sensibles (Opportunité, Compte).
3. Migrez en sandbox avec l'outil natif, puis comparez le comportement ancien/nouveau sur un jeu de données représentatif.
4. Consolidez : si plusieurs Process Builder existent sur le même objet, ne créez pas plusieurs flux équivalents — regroupez-les en un seul Record-Triggered Flow avec des branches Decision, conformément à la bonne pratique « un flux par objet et par contexte ».
5. Désactivez l'ancien processus seulement après validation complète du nouveau flux, jamais en simultané sur le même déclencheur (risque de double exécution ou de conflit).
6. Surveillez les premiers jours en production via le débogueur de flux et les journaux d'erreurs (Configuration > Éléments de flux ayant échoué).

Différences de comportement à anticiper

Certains comportements changent subtilement entre les deux outils :

• L'ordre d'exécution entre un Flow « before-save » et un trigger Apex diffère de celui d'un Workflow Rule classique ; revalidez l'ordonnancement global si plusieurs automatisations interagissent sur le même objet.
• Les Field Updates de Workflow Rules s'exécutaient sans re-déclencher les règles de validation dans certains cas historiques ; en Flow, ce comportement peut différer selon le mode choisi (fast field update ou non).
• Le comportement de récursivité (un flux qui se redéclenche lui-même) doit être testé explicitement, car Flow ne bloque pas automatiquement la boucle comme le faisait parfois Workflow Rule.

Ne migrez jamais « en bloc » un grand nombre de processus la même semaine que la mise en production d'une autre fonctionnalité majeure. En cas d'anomalie, vous devez pouvoir isoler rapidement la cause : un changement à la fois.

Après la migration

Une fois tous les processus migrés, désactivez et archivez (sans forcément supprimer immédiatement) les anciens Process Builder et Workflow Rules pour conserver une trace historique le temps de la stabilisation, généralement 4 à 8 semaines. Documentez chaque flux créé avec une convention de nommage claire (préfixe par objet et déclencheur) pour que la migration profite durablement à la lisibilité de vos automatisations.

Cette migration est aussi l'occasion de nettoyer la dette technique accumulée : processus obsolètes, règles jamais désactivées, logique dupliquée entre plusieurs outils. Ne la traitez pas comme une simple conversion technique, mais comme une vraie opportunité de rationalisation.