Un flux déclenché par un enregistrement échoue silencieusement un vendredi soir. Le lundi, un commercial signale que de nouvelles opportunités « ne s'enregistrent pas », et le seul indice est un e-mail cryptique arrivé dans la boîte de réception de la dernière personne ayant modifié le flux — quelqu'un qui a peut-être quitté l'entreprise depuis des mois. Cela vous rappelle quelque chose ? La gestion des erreurs Flow Salesforce est l'un des aspects les plus négligés de l'automatisation, alors qu'elle demande très peu d'efforts pour être mise en place. Ce guide présente quatre techniques à appliquer dès aujourd'hui : les chemins d'erreur (fault paths), l'annulation des modifications (rollback), les erreurs personnalisées (Custom Error) et le routage des e-mails d'erreur vers les bons destinataires.
Pourquoi les erreurs Flow non gérées nuisent à l'entreprise
Lorsqu'un élément de flux échoue et que rien ne prend en charge cette défaillance, le flux s'arrête tout simplement. Selon l'unité Trailhead consacrée aux chemins d'erreur dans Flow (Handle Flow Errors with Fault Paths, en anglais), l'utilisateur voit alors un message générique indiquant qu'une erreur non gérée s'est produite et doit tout recommencer. Salesforce envoie les détails techniques par e-mail, mais l'utilisateur bloqué n'obtient aucune information utile.
Trailhead liste les causes les plus fréquentes, et presque toutes sont prévisibles :
- l'utilisateur exécutant ne peut pas créer ou modifier l'enregistrement ;
- un champ obligatoire est manquant ;
- un ID d'enregistrement est mal formé ou une adresse e-mail est invalide ;
- une règle de validation rejette la modification.
Pour les décideurs, la conséquence n'est pas seulement technique : perte de saisie, frustration des utilisateurs, multiplication des tickets de support et érosion progressive de la confiance accordée au CRM. Pour les administrateurs, cela implique de déboguer à partir de signalements flous plutôt que de messages précis.
Conseil n° 1 : ajoutez un chemin d'erreur à chaque élément de données et d'action
Un chemin d'erreur (fault path) est un connecteur secondaire qui ne s'exécute que si son élément source échoue. Trailhead confirme sa disponibilité sur les éléments Get Records, Create Records, Update Records, Delete Records et Action. Dans Flow Builder, ouvrez le menu de l'élément, choisissez d'ajouter un chemin d'erreur, puis définissez les actions à exécuter.
Ce qu'il convient de placer sur le chemin d'erreur dépend du type de flux :
| Type de flux | Que placer sur le chemin d'erreur | Pourquoi |
|---|---|---|
| Screen flow (flux d'écran) | Roll Back Records, puis un écran affichant l'erreur | L'utilisateur comprend ce qui a échoué et aucune donnée n'est partiellement enregistrée |
| Record-triggered flow (flux déclenché par un enregistrement) | Élément Custom Error | La modification initiale est annulée et l'utilisateur voit un message clair |
| Flux lancé automatiquement ou planifié | Notification ou enregistrement de journal pour l'administrateur | Aucun utilisateur n'est devant l'écran, il faut donc alerter l'équipe technique |
Dans les screen flows, la variable globale $Flow.FaultMessage contient le détail de l'erreur. L'exemple de Trailhead l'affiche sur un « écran d'erreur » accompagné des valeurs saisies par l'utilisateur, ce qui permet de repérer immédiatement une date de clôture manquante lors du débogage. Pour éviter de reconstruire la même logique dans chaque flux, Trailhead suggère de placer les éléments communs du chemin d'erreur dans un sous-flux lancé automatiquement et réutilisable.
Conseil n° 2 : annulez les modifications partielles dans les screen flows
Un chemin d'erreur ne suffit pas à annuler ce que les éléments précédents ont déjà enregistré. Si un flux met à jour un compte puis échoue lors de la création de l'opportunité, la mise à jour du compte est conservée. L'unité Trailhead Roll Back Changes After an Error (en anglais) explique que l'élément Roll Back Records annule les modifications apportées à la base de données au cours de la transaction en cours.
Trois règles essentielles à retenir :
- Roll Back Records s'applique uniquement aux screen flows.
- Placez-le avant l'écran d'erreur, car les utilisateurs ferment souvent la fenêtre dès l'affichage de l'erreur, empêchant les éléments suivants de s'exécuter.
- Un écran met fin à la transaction en cours : le rollback ne peut donc pas annuler les modifications enregistrées avant un écran précédent.
Conseil n° 3 : utilisez Custom Error dans les flux déclenchés par un enregistrement
Pour les flux déclenchés par un enregistrement (record-triggered flows), l'élément d'erreur personnalisé (Custom Error) constitue la solution la plus propre. L'aide Salesforce indique qu'il fonctionne dans les flux avant sauvegarde (before-save) et après sauvegarde (after-save), ainsi que dans les flux s'exécutant avant la suppression d'un enregistrement. Lorsqu'il se déclenche, la modification initiale est annulée et l'utilisateur voit votre message, soit dans une fenêtre sur la page de l'enregistrement, soit en ligne sur un champ spécifique.
Quelques limites documentées à prendre en compte : un message sur la page d'enregistrement par élément, une erreur en ligne par champ, 255 caractères maximum par message, pas de champs composés et aucun chemin asynchrone. Les messages peuvent être traduits via Translation Workbench, un atout précieux pour les équipes bilingues français-anglais.
Conseil n° 4 : envoyez les e-mails d'erreur à une équipe, pas au dernier modificateur
Dans de nombreuses organisations, les erreurs de flux sont encore envoyées par e-mail à la dernière personne ayant modifié le flux. L'aide Salesforce explique comment sélectionner les destinataires des e-mails d'erreur de flux et de processus : dans la Configuration, ouvrez Process Automation Settings (Paramètres d'automatisation des processus) et définissez l'option d'e-mail d'erreur soit sur l'utilisateur ayant modifié le flux en dernier, soit sur les Apex Exception Email Recipients. Choisir cette seconde option vous permet de gérer une liste unique, sur la page Apex Exception Email de la Configuration, qui peut inclure une boîte partagée d'administration.
Pour rendre ces e-mails immédiatement exploitables, le blog Salesforce Admins recommande une convention de nommage des éléments très efficace : préfixez chaque libellé d'élément par un code court (par exemple S01 pour le premier écran, G02 pour le deuxième Get Records). Lorsqu'un e-mail d'erreur mentionne ce code, il suffit de le coller dans la recherche de Flow Builder pour accéder à l'élément défaillant en quelques secondes.
Que faire dès maintenant : checklist de gestion des erreurs Flow Salesforce en 30 minutes
Passez en revue cette liste pour vos cinq flux les plus utilisés cette semaine :
- Les Process Automation Settings redirigent les e-mails d'erreur vers les Apex Exception Email Recipients, et cette liste contient une boîte partagée surveillée.
- Chaque élément Get, Create, Update, Delete et Action dispose d'un chemin d'erreur.
- Les screen flows exécutent un rollback avant d'afficher un écran d'erreur contenant
$Flow.FaultMessage. - Les flux déclenchés par un enregistrement utilisent Custom Error pour bloquer les modifications non valides avec un message clair.
- Les flux lancés automatiquement et planifiés notifient un responsable en cas d'échec.
- Les libellés d'éléments suivent une convention de nommage facilitant l'identification des erreurs.
Si votre org accumule des dizaines de flux créés au fil des ans par différents collaborateurs, la gestion des erreurs n'est souvent que la partie émergée de l'iceberg. Notre article sur la dette technique CRM explique comment maintenir des automatisations évolutives, et notre guide récent sur les doublons Salesforce et les règles de duplication traite du volet qualité des données. Si vous souhaitez un diagnostic externe, notre audit CRM évalue conjointement vos flux, vos données et votre sécurité, tandis que nos services Sales Cloud vous accompagnent dans la conception de vos automatisations dès le départ.
Conclusion
Une gestion efficace des erreurs dans Salesforce Flow ne nécessite ni code ni nouvelles licences. Un chemin d'erreur, un rollback, un message Custom Error clair et une boîte e-mail partagée transforment des échecs silencieux en informations exploitables. Commencez par les flux utilisés au quotidien par vos équipes commerciales et de service, et intégrez la gestion des erreurs dans vos critères de validation pour chaque nouvelle automatisation.
Sources
- Trailhead, Handle Flow Errors with Fault Paths (en anglais)
- Trailhead, Roll Back Changes After an Error (en anglais)
- Aide Salesforce, Élément d'erreur personnalisé
- Aide Salesforce, Sélection des destinataires des e-mails d'erreur de flux et de processus
- Blog Salesforce Admins, Customize Error Emails with a Flow Element Naming Convention (en anglais)