Un chantier que rien ne vous force à faire, jusqu'au jour où si
Salesforce n'autorise plus la création de nouvelles Workflow Rules ni de nouveaux Process Builder, et a engagé leur retrait au profit de Flow. Vos automatisations existantes, elles, continuent de tourner. C'est ce qui rend la migration de Process Builder vers Flow si facile à repousser : rien ne casse, rien n'alerte, aucune facture n'augmente.
Le risque n'est pas immédiat, il est de calendrier. Le jour où ces outils cesseront de s'exécuter, ce sont vos processus qui s'arrêteront, à une date fixée par Salesforce et non par vous. Un chantier reporté trop longtemps devient un chantier subi, mené dans l'urgence, sans le temps de tester.
L'autre raison de s'y mettre est plus immédiate. Tant que trois générations d'automatisations coexistent sur le même objet, personne ne peut dire avec certitude ce qui se déclenche, dans quel ordre. Cette incertitude est ce qui paralyse les orgs que je reprends.
Ce que vous gagnez au passage
Présenter cette migration comme une simple mise en conformité serait dommage, parce qu'elle apporte des choses concrètes.
Un seul endroit où chercher. Quand toute l'automatisation d'un objet vit dans Flow, comprendre ce qui se passe redevient possible en quelques minutes.
De la performance. Un Process Builder qui met à jour l'enregistrement en cours provoque une écriture supplémentaire. Le Flow avant enregistrement fait la même chose pendant la sauvegarde, sans ce coût. Sur les objets très sollicités, la différence se voit.
Un vrai débogage. Flow propose un mode de test qui déroule le parcours pas à pas et montre les valeurs à chaque étape. Personne ne regrettera le débogage à l'aveugle des anciens outils.
La gestion des échecs. Un Flow permet de définir un chemin d'erreur, c'est à dire ce qui doit se passer quand une étape échoue. C'est ce qui transforme une panne silencieuse en incident traité.
L'outil Migrate to Flow, ce qu'il fait et ce qu'il ne fait pas
Salesforce fournit un outil de migration dans le Setup. Il convertit une Workflow Rule ou un Process Builder en Flow équivalent, et il fait honnêtement son travail sur les cas simples.
Ce qu'il ne fait pas est plus important. Il ne regroupe pas les automatisations qui font doublon, il les convertit une par une, donc trois Process Builder sur le même objet deviennent trois Flows. Il ne décide pas de l'ordre d'exécution. Il ne teste rien. Et surtout, il reproduit fidèlement des choix faits il y a cinq ans, y compris ceux qui n'avaient plus de sens depuis trois ans.
La conversion technique est la partie facile de ce chantier. La partie qui demande du jugement, c'est de décider ce qui mérite d'être migré.
La méthode en cinq temps
1. L'inventaire, objet par objet
Pas automatisation par automatisation, objet par objet. Pour chaque objet qui compte, listez tout ce qui se déclenche à la création et à la modification : Workflow Rules, Process Builder, Flows déjà présents, règles de validation, déclencheurs Apex.
Cette vue révèle immédiatement les recouvrements, les contradictions, et les automatisations qui pointent vers des champs abandonnés ou des utilisateurs partis. C'est aussi le livrable le plus utile de l'exercice, bien au delà de la migration.
2. Le tri, avant toute conversion
Trois catégories suffisent. Ce qui ne sert plus, et qui se désactive au lieu de se migrer, ce qui est le meilleur résultat possible. Ce qui fait doublon, et qui doit fusionner en une seule automatisation. Ce qui reste, et qui sera migré.
Dans les orgs que je reprends, la première catégorie est rarement vide. Migrer une automatisation morte, c'est payer deux fois : une fois la conversion, une fois la confusion qu'elle entretiendra.
3. Le regroupement
C'est ici que se joue la valeur du chantier. Plutôt que de convertir chaque automatisation en un Flow distinct, on regroupe par objet et par moment de déclenchement : un Flow avant enregistrement pour ce qui touche la fiche elle-même, un Flow après enregistrement pour ce qui agit ailleurs.
Le résultat est une org où chaque objet a deux automatisations lisibles au lieu de sept qui se marchent dessus. Quand plusieurs Flows doivent malgré tout coexister sur un même objet, fixez explicitement leur ordre de déclenchement plutôt que de laisser la plateforme choisir.
4. Les tests, sur des cas réels
Tout se construit dans une sandbox, et se teste sur des cas issus de votre activité, pas sur un enregistrement inventé. Testez le cas nominal, mais surtout les cas limites : l'enregistrement incomplet, la modification en masse, la création par une intégration plutôt que par un humain.
Ce dernier point est celui qu'on oublie le plus. Beaucoup d'automatisations n'ont jamais été éprouvées sur des enregistrements créés par un flux automatique, et c'est précisément là qu'elles cassent.
5. La bascule, jamais en parallèle
On active le nouveau Flow et on désactive l'ancienne automatisation dans le même mouvement. Les laisser tourner ensemble « le temps de vérifier » produit des doubles exécutions, des notifications en double et des données incohérentes.
Objet par objet, avec une période d'observation entre chaque. Une migration menée en une seule fois sur toute l'org est ingérable dès que quelque chose se comporte différemment de prévu.
Ce qu'il ne faut surtout pas migrer vers Flow
Une migration de Process Builder vers Flow réussie est d'abord une migration où l'on a beaucoup jeté. Trois familles ne méritent pas d'être transportées vers Flow.
Les automatisations orphelines. Celles qui pointent vers un champ qui n'est plus renseigné, vers une file d'attente supprimée ou vers un utilisateur parti. Elles tournent encore, elles échouent souvent en silence, et personne ne les réclamera si vous les désactivez.
Les alertes que plus personne ne lit. Un courriel envoyé à chaque modification finit en règle de tri automatique dans les messageries. Migrer vers Flow une notification que tout le monde ignore, c'est reconduire un bruit qui masque les alertes utiles.
Ce qui relève d'une règle de validation. Certains Process Builder ont été construits pour contrôler une saisie, à une époque où c'était l'outil sous la main. Une règle de validation fait la même chose plus simplement, et se lit en dix secondes.
Avant de migrer quoi que ce soit vers Flow, posez la question à voix haute : si cette automatisation n'existait pas, quelqu'un la demanderait-il aujourd'hui ? Quand la réponse est non, vous venez d'économiser une conversion et une dette.
Les pièges les plus fréquents
Migrer à l'identique. Reproduire fidèlement une automatisation dont plus personne ne comprend l'intention, c'est transporter la dette dans le nouvel outil. Chaque conversion est l'occasion de demander à quoi cela sert encore.
Oublier ce qui déclenche quoi. Une automatisation qui modifie un enregistrement peut en déclencher une autre, qui en déclenche une troisième. Ces chaînes existent souvent sans que personne les ait conçues, et elles se révèlent au pire moment.
Négliger les conditions d'entrée. Une automatisation qui s'exécute à chaque modification, alors qu'elle ne concerne qu'un changement de statut, consomme du temps de traitement à chaque sauvegarde et brouille le diagnostic.
Ne pas prévoir l'échec. Un Process Builder qui échoue produit un message obscur. Un Flow sans chemin d'erreur fait la même chose. Profitez de la migration pour traiter ce point plutôt que de le reconduire.
Combien de temps cela prend
L'inventaire se compte en un à deux jours, comme un audit d'org, et il ne dépend que du volume de configuration.
La suite dépend entièrement de ce que l'inventaire révèle : le nombre d'automatisations réellement actives, leur enchevêtrement, et le nombre d'objets concernés. Une org avec quelques Process Builder isolés se migre en quelques jours. Une org où trois générations se superposent sur les objets centraux demande davantage, et c'est le temps de tests qui pèse le plus.
Le facteur qui change tout n'est pas la taille de l'entreprise, c'est le nombre de personnes qui sont intervenues sans se coordonner.
Par quoi commencer cette semaine
Ouvrez le Setup et cherchez vos Workflow Rules et vos Process Builder actifs. Vous obtiendrez en quelques minutes la mesure du chantier, et ce chiffre est presque toujours plus élevé que ce que l'on croit.
Prenez ensuite l'objet le plus sollicité de votre activité, souvent l'opportunité ou la commande, et listez tout ce qui s'y déclenche. C'est sur cet objet que la migration de Process Builder vers Flow rapportera le plus, et c'est aussi celui sur lequel il faut avancer avec le plus de méthode.
Questions fréquentes
L'outil Migrate to Flow de Salesforce suffit-il pour migrer ?
Il fait le gros du travail de conversion, mais il ne décide rien à votre place. Il ne regroupe pas les automatisations qui font doublon, il ne teste pas le résultat, et il ne dit pas dans quel ordre les nouveaux Flows doivent s'exécuter. La conversion est la partie facile.
Que se passe-t-il si je ne migre pas mes Process Builder ?
Rien d'immédiat, et c'est ce qui rend le sujet facile à reporter. Salesforce n'en autorise plus la création et a engagé leur retrait : le jour où ils cesseront de s'exécuter, ce sont vos processus qui s'arrêteront, à une date que vous n'aurez pas choisie.