Prendre un appel

Salesforce : comment identifier les Flows cassés ou inactifs dans votre org

La plupart des orgs Salesforce accumulent des Flows oubliés, désactivés ou en échec silencieux. Voici comment obtenir une vue d'ensemble en moins d'une heure, sans outil payant.

Si votre Salesforce est en production depuis plus d’un an, il y a une quasi-certitude : personne dans votre organisation ne peut lister de mémoire l’ensemble des Flows actifs, ni dire lesquels fonctionnent réellement. Ce n’est pas un jugement — c’est structurel. Les automatisations s’accumulent, les personnes qui les ont créées changent de poste ou d’entreprise, et la documentation, quand elle existe, vieillit plus vite qu’on ne la met à jour.

Voici comment reprendre le contrôle en partant de zéro, sans outil tiers payant.

Étape 1 — Lister tous les Flows existants

Allez dans Configuration → Flows. Cette liste affiche tous les Flows de l’org, avec leur type (Record-Triggered, Screen Flow, Scheduled, Autolaunched) et leur statut (Actif, Brouillon, Obsolète).

Sur un org qui a plus de deux ans d’existence, il n’est pas rare de trouver 30 à 60 Flows. Le premier réflexe utile n’est pas de tout lire en détail, mais de trier par colonne Type de processus et Dernière modification pour repérer :

  • les Flows dont la dernière modification remonte à plusieurs années (candidats à la revue) ;
  • les Flows en statut Brouillon qui ne servent visiblement à rien en production (à supprimer, une fois confirmé) ;
  • les doublons apparents — deux Flows aux noms proches qui semblent faire la même chose.

Étape 2 — Repérer les Flows avec des erreurs actives

Salesforce conserve une trace des échecs d’exécution des Flows. Deux endroits à vérifier :

  1. Configuration → Flows → onglet “Erreurs des éléments de Flow” (le nom exact varie légèrement selon la version) liste les échecs récents, avec l’élément concerné et le message d’erreur brut.
  2. Les emails d’erreur de Flow, envoyés par défaut au propriétaire du Flow (souvent la personne qui l’a créé — qui a parfois quitté l’entreprise, ce qui explique que personne ne les voit jamais). Vérifiez dans chaque Flow, section Paramètres avancés, à qui ces emails sont adressés, et redirigez-les vers une adresse ou une file active si besoin.

Un Flow qui apparaît “actif” dans la liste peut très bien échouer systématiquement depuis des mois sans que cela soit visible ailleurs que dans ces deux endroits.

Étape 3 — Croiser avec les anciens Process Builders et Workflow Rules

Si votre org existe depuis avant 2020, il est probable qu’il contienne encore des Process Builders et des Workflow Rules — les ancêtres des Flows actuels, que Salesforce recommande officiellement de migrer, sans les avoir désactivés de force.

Le risque principal : un Process Builder et un Flow plus récent peuvent agir sur le même objet, dans un ordre d’exécution qui n’est pas garanti, et se marcher dessus (mises à jour de champs qui se contredisent, emails envoyés en double). Listez-les via Configuration → Process Builder et Configuration → Workflow Rules, et vérifiez, pour chaque objet important (Opportunité, Lead, Compte…), qu’un seul mécanisme d’automatisation gère chaque comportement.

Étape 4 — Documenter, même a minima

Vous n’avez pas besoin d’une documentation exhaustive. Un simple tableau avec, pour chaque Flow actif important : son nom, l’objet concerné, un résumé en une phrase de ce qu’il fait, et la personne ou l’équipe à contacter en cas de problème, change déjà radicalement la situation la prochaine fois qu’un nouvel intervenant (interne ou externe) doit toucher à ces automatisations.

Automatiser une partie de cette vérification

Cette démarche peut être largement accélérée par des requêtes directes sur les objets de métadonnées de Salesforce plutôt qu’en cliquant manuellement dans chaque écran. J’ai construit un petit script Python open source qui fait une partie de ce travail automatiquement — lister l’état de tous les Flows d’un org et repérer les champs personnalisés quasiment jamais utilisés. Le code est public sur GitHub, avec un README expliquant comment l’utiliser sur votre propre org (idéalement une sandbox, par précaution).

Si cette revue révèle plus de problèmes que vous n’avez le temps d’en traiter vous-même, c’est exactement le périmètre de l’offre Audit et remise en ordre : un rapport complet, priorisé, et la correction des points les plus critiques en 3 jours ouvrés.

Un problème similaire sur votre Salesforce ?

Décrivez-le en quelques lignes lors d'un appel de cadrage gratuit de 30 minutes.

Prendre un appel de 30 minVoir les offres