Migrer de Workflow Rules et Process Builder vers Salesforce Flow : le playbook 2026

Workflow Rules et Process Builder sont officiellement retirés. Chaque automatisation qui tourne dessus est en sursis. La migration vers Salesforce Flow n'est plus un projet « on verra plus tard », c'est une échéance dure. Voici le playbook pragmatique que nous utilisons pour migrer une org mid-size en 6-10 semaines sans casser la prod.

Pourquoi la migration ne peut plus attendre

Salesforce a arrêté d'investir sur les deux anciens outils. Bugs non corrigés. Nouveaux objets et features réservés à Flow. Chaque jour de retard = de la dette qu'un futur admin ne pourra pas maintenir.

Étape 1 : Inventorier

Utilisez Salesforce Optimizer ou une requête metadata pour lister chaque Workflow Rule et Process Builder actif. Catégorisez par objet et par action :

• Mises à jour de champ (migration facile)
• Alertes email (moyen)
• Outbound messages (moyen)
• Mises à jour cross-object (plus difficile)
• Récursion ou processus chaînés (audit avant de toucher)

Étape 2 : Consolider avant de migrer

La tentation est de reconstruire chaque automatisation en Flow. Ne le faites pas. La plupart des orgs ont 3-5 automatisations qui font le même job. Consolidez en un Flow par objet et par événement. Vous finirez avec 40 % d'automatisations en moins, bel effet de bord.

Étape 3 : Utiliser l'outil de migration, mais vérifier

Salesforce fournit « Migrate to Flow ». Il fait le mécanique mais produit des Flows aux noms génériques, sans commentaires, sans gestion d'erreur. Toujours : renommer, commenter, ajouter des chemins de fault.

Étape 4 : Tester en full sandbox

Pas de migration en developer sandbox. Une partial ou full sandbox est nécessaire pour attraper les bugs d'interaction.

Étape 5 : Déployer par vagues, pas en big-bang

Migrez par objet : leads d'abord (risque faible), puis opportunités, puis objets service. Jamais tout d'un coup. Si ça casse, ça casse dans une vague, pas tout le business.

Et les triggers Apex ?

Flow est assez rapide pour la plupart des cas en 2026. Réservez Apex aux opérations batch volumineuses, à la logique que Flow ne peut pas exprimer proprement, ou aux processus sensibles à la performance. Voir notre guide sur la dette technique.

Notes régionales

• UE : si les automatisations touchent des données salariés, revue DPO standard avant migration. Voir guide RGPD.
• États-Unis & Canada : si la migration tombe en fin de trimestre, planifiez un release freeze.

Questions fréquentes

Combien de temps ?

Petite org : 2 à 4 semaines. Mid-market : 6 à 10 semaines. Grande org complexe : 3 à 6 mois.

DIY possible ?

Oui avec un admin senior. 90 % des rescues venaient d'une consolidation et de tests sautés.

Faut-il des licences Flow ?

Non, Flow est inclus dans toutes les éditions. Flow Orchestrator est un add-on payant.

Et si mon Process Builder appelle de l'Apex ?

Migrer vers Flow ; l'appel Apex reste. Vérifier que le nouveau Flow passe le même contexte.

Obtenez une migration Flow au forfait

Notre package de migration couvre audit, consolidation, migration et tests en 6-10 semaines. Réservez un appel de 30 minutes.