Comment identifier et corriger une erreur Salesforce Flow ?

Un Flow en erreur bloque souvent un geste simple : créer une opportunité, enregistrer un compte, fermer une requête. L'utilisateur voit un message peu clair, et l'administrateur reçoit un e-mail plein de détails techniques. Bonne nouvelle : dans la grande majorité des cas, la cause se trouve en suivant toujours la même méthode.

Où apparaissent les erreurs de Flow

Une erreur de Flow se manifeste à deux endroits.

• À l'écran de l'utilisateur. Pour un Flow déclenché par un enregistrement, l'enregistrement échoue et un message s'affiche. Pour un Flow à l'écran, le texte « An unhandled fault has occurred in this flow » (une erreur non gérée s'est produite) remplace l'écran.
• Dans la boîte de l'administrateur. Salesforce envoie un e-mail d'erreur qui contient le nom du Flow, la version, l'élément en échec et les valeurs des variables au moment de l'erreur. C'est le document le plus utile pour le diagnostic.

La méthode de diagnostic en 5 étapes

1. Lire l'e-mail d'erreur jusqu'au bout

Le début de l'e-mail est souvent générique. La partie utile est plus bas : la liste des éléments exécutés, et surtout le dernier, celui qui a échoué, avec le message d'erreur exact. Notez trois choses : l'élément en échec, le message, et l'enregistrement concerné.

2. Identifier le type d'erreur

Le message d'erreur indique presque toujours la famille du problème :

3. Reproduire le problème en sandbox

Ouvrez le Flow dans Flow Builder et utilisez le bouton Déboguer avec le même enregistrement, ou un enregistrement équivalent. Le débogage montre le chemin suivi, élément par élément, et la valeur de chaque variable. Pour un Flow déclenché par un enregistrement, choisissez s'il s'agit d'une création ou d'une modification, comme dans le cas réel.

Si le Flow fonctionne en débogage mais échoue pour l'utilisateur, le problème vient souvent du contexte d'exécution : droits de l'utilisateur, type d'enregistrement, ou valeur d'un champ que vous n'avez pas reproduite.

4. Regarder ce qui tourne autour du Flow

Un Flow n'est jamais seul. Sur le même objet, il peut y avoir d'autres Flows, des règles de validation, des règles de workflow anciennes, du code Apex. L'Explorateur de déclencheurs de Flow (Flow Trigger Explorer) affiche tous les Flows déclenchés sur un objet et leur ordre. Deux Flows qui modifient le même champ dans un ordre différent produisent des résultats surprenants.

5. Corriger la cause, pas le symptôme

Contourner l'erreur (désactiver la règle de validation, donner plus de droits à tout le monde) la fait disparaître, mais crée souvent un autre problème. Demandez-vous pourquoi la règle existe, ou pourquoi l'utilisateur n'a pas l'accès, avant de changer quoi que ce soit.

Les erreurs les plus fréquentes et leur correction

Une règle de validation bloque le Flow

C'est le cas le plus courant. Une règle ajoutée récemment refuse une modification que le Flow faisait sans problème avant. Deux options : adapter la règle pour qu'elle tienne compte du cas (avec le métier), ou faire remplir par le Flow le champ attendu. Exemple : une règle exige un « Secteur » sur le compte, et le Flow crée des comptes sans secteur. Le Flow doit renseigner le secteur, ou la règle doit l'exclure pour les comptes créés automatiquement.

Une variable vide

Un élément « Get Records » ne trouve rien, puis un élément suivant utilise le résultat comme s'il existait. Ajoutez une Décision juste après la recherche : « le résultat n'est pas vide ». Le chemin « vide » doit faire quelque chose de prévu : rien, une notification, ou un message clair.

Des recherches ou des écritures dans une boucle

Placer un « Get Records » ou un « Update Records » à l'intérieur d'une boucle fait exploser les limites dès que le Flow traite beaucoup d'enregistrements, par exemple lors d'un import. La correction : collecter les enregistrements dans une variable de collection pendant la boucle, puis faire une seule écriture après.

Le mauvais type de Flow déclenché par un enregistrement

Pour modifier un champ du même enregistrement, un Flow « avant l'enregistrement » (mises à jour rapides de champs) est plus rapide et évite des écritures en plus. Pour créer des enregistrements liés ou envoyer des e-mails, il faut un Flow « après l'enregistrement ». Mélanger les deux crée des boucles et des erreurs.

Exemple complet : une opportunité qui ne se crée plus

Situation fictive : depuis lundi, l'équipe commerciale ne peut plus créer d'opportunité sur certains comptes. L'administrateur reçoit un e-mail d'erreur à chaque tentative.

1. Lecture de l'e-mail. L'élément en échec est « Mise à jour du compte » et le message est FIELD_CUSTOM_VALIDATION_EXCEPTION : une règle de validation refuse la modification. Le Flow lui-même n'a pas changé depuis des mois.
2. Recherche de la cause. Dans le Gestionnaire d'objets, sur l'objet Compte, une règle de validation créée vendredi exige le champ « Secteur » dès qu'un compte passe au type « Client ». Or le Flow passe le compte en « Client » à la création de sa première opportunité, sans renseigner le secteur.
3. Reproduction. En sandbox, le débogage du Flow avec un compte sans secteur échoue exactement au même élément. La cause est confirmée.
4. Correction, décidée avec le métier. La règle a une raison d'être : le secteur sert aux rapports de la direction. Elle reste donc en place. Le Flow ne change plus le type d'un compte sans secteur : il crée une tâche « Compléter le secteur » pour le propriétaire du compte. Un chemin d'erreur sur l'élément de mise à jour prévient l'administrateur au lieu de bloquer le commercial.
5. Vérification. Trois tests avant activation : un compte avec secteur, un compte sans secteur et un import de 50 opportunités. Puis activation de la nouvelle version et contrôle des e-mails d'erreur les jours suivants.

Les bonnes pratiques pour éviter les prochaines erreurs

• Un chemin d'erreur sur chaque écriture. Dans Flow Builder, chaque élément qui écrit peut avoir un chemin « Erreur ». Utilisez-le pour enregistrer le problème et prévenir l'administrateur, sans bloquer l'utilisateur quand c'est acceptable.
• Des critères d'entrée précis. Un Flow déclenché par un enregistrement ne doit tourner que lorsque c'est nécessaire, par exemple « quand l'étape change ».
• Un Flow par objet et par moment, quand c'est possible. Moins de Flows, c'est moins de conflits d'ordre.
• Des descriptions. Chaque Flow, chaque version et chaque élément important doit dire ce qu'il fait et pourquoi.
• Pas de modification directe en production. Testez en sandbox, puis déployez.

Tester avant d'activer

Avant d'activer une nouvelle version, testez au minimum :

1. le cas qui échouait ;
2. le cas normal, qui fonctionnait déjà ;
3. un cas limite : champ vide, utilisateur avec peu de droits, plusieurs enregistrements à la fois (import).

Pour les Flows déclenchés par un enregistrement, Flow Builder permet d'enregistrer des tests de Flow réutilisables. Ils évitent de refaire les mêmes vérifications à chaque modification.

Quand faire appel à un expert

Vous pouvez corriger vous-même une règle de validation ou une variable vide. Faites appel à un expert quand :

• plusieurs automatisations sur le même objet se contredisent ;
• l'erreur concerne des limites de la plateforme ou un import en masse ;
• du code Apex intervient dans la chaîne ;
• vous n'avez pas de sandbox, ou pas de temps pour tester sans risque.

Dans ces cas, une heure de diagnostic évite souvent plusieurs jours d'essais en production. Voir notre service d'automatisation Salesforce : diagnostic, correction et tests, avec un devis avant tout travail.

Références officielles

Documentation Salesforce (en anglais) pour aller plus loin :

• Troubleshooting Flow Run Time Errors (aide Salesforce) (nouvel onglet)
• Select Flow and Process Error Email Recipients (aide Salesforce) (nouvel onglet)
• Default Flow Error Handling (aide Salesforce) (nouvel onglet)
• Handle Flow Errors Effectively (Trailhead) (nouvel onglet)

Questions fréquentes