Pourquoi une automatisation défaillante ne se voit pas
Un site web en panne se remarque en quelques minutes. Une automatisation qui échoue, non : elle ne fait rien, et ne rien faire ne déclenche aucune alarme.
Les erreurs de Flow se manifestent par des symptômes qui ne ressemblent pas à des pannes. Un champ qui reste vide alors qu'il devait se remplir. Une tâche de suivi qui n'existe pas. Un rapport dont le total baisse sans raison. Personne ne fait le lien avec une automatisation, et le diagnostic arrive des mois plus tard.
Voici les sept causes que je retrouve le plus souvent quand je reprends une org, classées par ce qu'elles coûtent réellement.
Les sept erreurs les plus coûteuses
1. Une requête ou une écriture à l'intérieur d'une boucle
C'est de loin la plus fréquente, et la plus traître. Le Flow parcourt une liste d'enregistrements et, à chaque tour, va chercher une information ou enregistre une modification.
Sur un enregistrement, tout fonctionne. Sur deux cents, la plateforme interrompt le traitement, parce qu'elle limite le nombre de requêtes et d'écritures autorisées dans une même transaction. Ces limites existent pour protéger l'ensemble des clients, et elles ne se négocient pas.
La bonne construction consiste à parcourir la liste pour préparer une collection, puis à faire une seule écriture après la boucle. C'est un réflexe à acquérir une fois, et il vaut pour toutes vos automatisations.
2. Aucun chemin d'erreur
Par défaut, quand une étape échoue, le Flow s'arrête et l'utilisateur reçoit un message technique incompréhensible. S'il s'agit d'un traitement de fond, personne ne voit rien du tout.
Un chemin d'erreur définit ce qui doit se passer dans ce cas : consigner l'incident, prévenir quelqu'un, afficher un message clair. Sans lui, vous n'avez pas une automatisation, vous avez un pari.
3. Des notifications d'erreur qui partent dans le vide
Quand un Flow échoue en arrière-plan, Salesforce envoie un courriel à la dernière personne ayant modifié ce Flow. Dans une org reprise, cette personne a souvent quitté l'entreprise depuis longtemps.
Résultat, les alertes existent et n'arrivent nulle part. C'est le premier réglage que je vérifie lors d'un audit d'org, parce qu'il conditionne la détection de tout le reste. Faites-les arriver à une adresse suivie par quelqu'un de présent.
4. Aucune condition d'entrée
Un Flow qui se déclenche à chaque modification, alors qu'il ne concerne qu'un changement de statut, s'exécute des milliers de fois pour rien. Il consomme du temps de traitement à chaque sauvegarde, ralentit l'expérience des utilisateurs, et brouille l'analyse quand vous cherchez ce qui se passe.
Restreindre le déclenchement au cas utile est le réglage le plus rentable du chantier : il coûte deux minutes et il se sent immédiatement.
5. Plusieurs Flows sur le même objet, sans ordre défini
Quand deux automatisations se déclenchent sur le même objet au même moment, l'ordre dans lequel elles s'exécutent n'est pas garanti si vous ne l'avez pas fixé. Tant que les deux sont indépendantes, cela n'a pas de conséquence. Le jour où l'une calcule un champ que l'autre utilise, vous obtenez un comportement qui change sans raison apparente.
Regroupez ce qui peut l'être, et quand plusieurs Flows doivent coexister, fixez explicitement leur ordre de déclenchement. C'est un point à traiter systématiquement pendant une migration de Process Builder vers Flow, moment où les automatisations se multiplient mécaniquement.
6. Des identifiants écrits en dur
Un Flow qui contient l'identifiant technique d'un utilisateur, d'une file d'attente ou d'un enregistrement de paramétrage fonctionne parfaitement dans l'environnement où il a été construit. Il échoue silencieusement ailleurs, ou après le départ de la personne concernée.
Passez par un nom, une recherche, ou un paramétrage prévu pour cela. Vous éviterez la panne classique du Flow qui fonctionnait en sandbox et échoue en production.
7. Un test sur un seul enregistrement, dans le cas idéal
Le mode de test de Flow est excellent, et c'est ce qui le rend dangereux : il déroule le parcours sur un enregistrement choisi par vous, et il donne le sentiment que tout va bien.
Or les automatisations ne cassent presque jamais sur le cas nominal. Elles cassent sur l'enregistrement incomplet, sur la mise à jour en masse, sur la création par une intégration plutôt que par un humain, et sur l'utilisateur qui n'a pas les mêmes droits que vous.
Comment savoir si vous en avez, dès aujourd'hui
Vous n'avez pas besoin d'un diagnostic complet pour savoir si votre org est concernée. Les erreurs de Flow laissent des traces visibles depuis le Setup, et trois vérifications suffisent à les repérer. Aucune ne demande de compétence particulière, et aucune ne modifie quoi que ce soit.
- Cherchez à qui arrivent les alertes. Ouvrez vos Flows actifs et regardez qui les a modifiés en dernier. Si ce sont des personnes parties, vos erreurs partent avec elles.
- Ouvrez un Flow qui traite plusieurs enregistrements et regardez s'il contient une requête ou une écriture à l'intérieur d'une boucle. C'est visuellement identifiable, même sans être administrateur.
- Listez les Flows actifs par objet. Trois automatisations ou plus sur un objet central est le signal qu'il faut regrouper avant d'ajouter quoi que ce soit.
La checklist avant d'activer un Flow
C'est celle que j'applique systématiquement, y compris sur les automatisations qui paraissent triviales, parce que ce sont souvent celles-là qui traînent le plus longtemps.
- Les conditions d'entrée sont restrictives, le Flow ne s'exécute que quand c'est utile.
- Aucune requête ni écriture à l'intérieur d'une boucle.
- Un chemin d'erreur est prévu sur chaque étape qui peut échouer.
- Les notifications d'échec arrivent à quelqu'un de présent dans l'entreprise.
- Aucun identifiant technique écrit en dur.
- Le test a couvert le cas nominal, un enregistrement incomplet, une mise à jour en masse et un utilisateur aux droits restreints.
- Le rôle du Flow, son déclencheur et son ordre d'exécution sont documentés.
- Tout a été construit et validé dans une sandbox avant la production.
Ce que coûte le fait de ne rien vérifier
Les erreurs de Flow ont une particularité : leur coût est différé et diffus. Il ne se lit sur aucune facture. Il apparaît sous forme de données incomplètes que quelqu'un rattrape à la main, de rapports auxquels plus personne ne se fie, et de temps passé à chercher pourquoi un enregistrement n'a pas le comportement attendu.
Quand ce doute s'installe, les utilisateurs se protègent en doublant l'outil avec leurs propres fichiers, et vous perdez le bénéfice de l'automatisation tout en continuant d'en payer la complexité.
La bonne nouvelle, c'est que ces sept points se vérifient en une passe, et que la plupart se corrigent en quelques heures. C'est le genre de remise au propre qui ne se voit jamais, jusqu'au jour où elle vous évite d'expliquer à un client pourquoi personne ne l'a rappelé.
Questions fréquentes
Qui reçoit les notifications d'erreur d'un Flow Salesforce ?
Par défaut, la dernière personne ayant modifié le Flow. Dans une org reprise, c'est souvent quelqu'un qui a quitté l'entreprise, et les alertes partent alors dans le vide. C'est un réglage à vérifier en priorité, parce qu'il conditionne tout le reste.
Pourquoi un Flow fonctionne-t-il sur un enregistrement et échoue-t-il en masse ?
Parce qu'il a été conçu et testé sur un cas unique. La plateforme traite les enregistrements par lots et impose des limites par transaction : une requête ou une écriture placée à l'intérieur d'une boucle passe sur une fiche et casse sur deux cents.