Un Flow qui « ne se déclenche pas » est l’une des demandes les plus fréquentes que je reçois. Le symptôme est presque toujours le même : un utilisateur modifie un enregistrement, s’attend à voir un email partir, un champ se mettre à jour ou une tâche se créer — et rien ne se passe. Pas d’erreur visible, pas d’explication. Juste du silence.
La bonne nouvelle : dans l’immense majorité des cas, la cause appartient à une short-list de 6 raisons. Voici comment les vérifier, dans l’ordre où je les vérifie moi-même.
1. Vérifier que le Flow est bien actif
C’est la cause la plus bête, et la plus fréquente. Un Flow peut exister en plusieurs versions, et une seule version peut être active à la fois.
- Allez dans Configuration → Flows.
- Ouvrez le Flow concerné.
- Regardez la colonne Version active. Si elle est vide, aucune version n’est active — le Flow n’a jamais réellement fonctionné en production, même s’il a l’air complet dans le Flow Builder.
C’est particulièrement fréquent après une modification : on édite, on sauvegarde une nouvelle version brouillon, et on oublie de l’activer. La version précédente reste active (ou aucune ne l’est), et le comportement observé ne correspond pas à ce qu’on vient de configurer.
2. Vérifier les conditions d’entrée (Entry Conditions)
Un Flow déclenché sur enregistrement (« Record-Triggered Flow ») a des conditions d’entrée précises : à la création, à la modification, ou aux deux ; et éventuellement des critères sur les valeurs de champs.
Le piège classique : une condition du type « Le champ Statut passe de “Nouveau” à “Qualifié” » ne se déclenche que sur cette transition précise. Si un utilisateur modifie l’enregistrement d’une autre manière (import en masse, mise à jour via une intégration, changement de statut en deux étapes), la condition n’est jamais remplie.
Pour vérifier : ouvrez le nœud de déclenchement du Flow et relisez les conditions au premier degré, sans présumer de ce qu’elles devraient faire.
3. Distinguer “Fast Field Updates” et exécution asynchrone
Sur les Flows déclenchés par enregistrement, Salesforce propose plusieurs options d’exécution : avant la sauvegarde, après la sauvegarde, de façon synchrone ou asynchrone (via une file de traitement). Un Flow configuré pour s’exécuter de façon asynchrone peut prendre quelques secondes à quelques minutes avant de produire un effet visible — ce qui, pour un utilisateur qui regarde son écran, ressemble à « ça ne marche pas ».
Si le comportement attendu est immédiat, vérifiez que le Flow est bien configuré pour une exécution synchrone adaptée au cas d’usage.
4. Chercher un chemin d’erreur silencieux (Fault Path manquant)
Un Flow peut échouer en cours d’exécution (par exemple, une action qui tente de mettre à jour un champ verrouillé par une règle de validation) sans que personne ne le sache, si aucun Fault Path n’a été configuré sur l’élément qui échoue.
Sans Fault Path, l’erreur remonte dans les logs internes de Salesforce (visibles par un administrateur via Configuration → Flows → Éléments en erreur, ou dans les emails d’erreur envoyés au propriétaire du Flow s’ils n’ont pas été désactivés) — mais l’utilisateur final, lui, ne voit rien du tout. C’est l’une des causes les plus sournoises, car le Flow “se déclenche” bien, il échoue juste en silence à mi-parcours.
5. Vérifier les limites de gouverneur et les boucles
Si le Flow est appelé un grand nombre de fois dans une même transaction (par exemple via une mise à jour en masse depuis un import ou une API), il peut se heurter aux limites de gouverneur Salesforce et être interrompu, sans toujours produire une erreur explicite côté utilisateur.
De la même façon, un Flow qui met à jour un enregistrement qui redéclenche le même Flow (boucle) peut être stoppé automatiquement par Salesforce comme mesure de protection.
6. Vérifier qu’un autre automatisme ne bloque pas la modification en amont
Si une règle de validation, un autre Flow ou un trigger Apex empêche l’enregistrement lui-même d’être sauvegardé (ou modifie l’enregistrement avant que le Flow concerné n’ait la main), le Flow ne verra jamais l’état qu’il attend. Ce cas est plus rare à diagnostiquer seul, car il demande de cartographier l’ensemble des automatisations actives sur l’objet concerné — pas seulement celle qu’on regarde.
Une méthode simple pour aller plus vite
Dans l’ordre, je recommande de vérifier : version active → conditions d’entrée → mode d’exécution → présence d’un Fault Path → limites/boucles → automatisations concurrentes sur le même objet.
Sur environ 80 % des cas que je rencontre, la cause se trouve dans les deux premiers points. Les cas plus rares (automatisations en conflit, boucles, limites de gouverneur) demandent une vue d’ensemble sur l’objet, pas seulement sur le Flow isolé — c’est exactement le type de situation que je traite dans l’offre Audit et remise en ordre.