Conception et validation des Salesforce Flow

Appliquez ces vérifications à chaque Flow que vous concevez, créez ou examinez.

Étape 1 — Confirmer que Flow est le bon outil

Avant de concevoir un Flow, vérifiez qu'une option déclarative plus légère ne peut pas résoudre le problème :

Si vous créez un Flow qui pourrait être remplacé par un champ de formule ou une règle de validation, demandez à l'utilisateur de confirmer que le besoin est réellement plus complexe.

Étape 2 — Sélectionner le type de Flow correct

Règle de décision : choisir avant-sauvegarde quand vous avez besoin de modifier uniquement les champs du propre enregistrement déclencheur. Passer à après-sauvegarde dès que vous devez toucher des enregistrements liés, envoyer des emails ou faire des callouts.

Étape 3 — Checklist de sécurité en masse

Ces modèles provoquent des défaillances de limite de gouvernance à grande échelle. Vérifiez-les tous avant l'activation du Flow.

DML dans les boucles — Défaillance automatique

Élément Loop
  └── Create Records / Update Records / Delete Records  ← ❌ DML inside loop

Correctif : collectez les enregistrements à l'intérieur de la boucle dans une variable de collection, puis exécutez l'élément DML en dehors de la boucle.

Get Records dans les boucles — Défaillance automatique

Élément Loop
  └── Get Records  ← ❌ SOQL inside loop

Correctif : effectuez la requête Get Records avant la boucle, puis bouclez sur la variable de collection.

Modèle de masse correct

Get Records — collectez tous les enregistrements en une seule requête
└── Boucler sur la variable de collection
    └── Decision / Assignment (pas de DML, pas de Get Records)
└── Après la boucle : Create/Update/Delete Records — une seule opération DML

Transform vs Loop

Quand l'objectif est de remodeler une collection (par exemple, mapper les valeurs de champs d'un objet à un autre), utilisez l'élément Transform au lieu d'un modèle Loop + Assignment. Transform est sûr en masse par conception et produit des graphiques Flow plus propres.

Étape 4 — Exigences du chemin de défaillance

Chaque élément susceptible de défaillir à l'exécution doit avoir un connecteur de défaillance. Les Flows sans chemins de défaillance exposent les erreurs système brutes aux utilisateurs.

Éléments qui nécessitent des connecteurs de défaillance

• Create Records
• Update Records
• Delete Records
• Get Records (lors de l'accès à un enregistrement requis qui pourrait ne pas exister)
• Send Email
• HTTP Callout / External Service action
• Apex action (invocable)
• Subflow (si le subflow peut générer une défaillance)

Modèle de gestionnaire de défaillance

Connecteur de défaillance → Log Error (Create Records sur un objet de journalisation ou déclencher un Platform Event)
                         → Élément Screen avec message convivial (Screen Flows)
                         → Stop / End element (Record-Triggered Flows)

Ne connectez jamais un chemin de défaillance au même élément qui a défailli — cela crée une boucle infinie.

Étape 5 — Vérification de la densité d'automatisation

Avant le déploiement, vérifiez qu'il n'y a pas d'automatisations superposées sur le même objet et le même événement de déclenchement :

• Autres Flows Record-Triggered actifs sur la même combinaison Object + When to Run
• Règles Process Builder héritées encore actives sur le même objet
• Règles Workflow qui se déclenchent sur les mêmes modifications de champ
• Apex triggers qui s'exécutent également dans le même contexte before insert / after update

Les automatisations superposées peuvent provoquer un ordre inattendu, une récursion et des défaillances de limite de gouvernance. Documentez l'inventaire d'automatisation de l'objet avant activation.

Étape 6 — Lignes directrices UX de Screen Flow

• Chaque chemin à travers un Screen Flow doit atteindre un élément End — pas de branches orphelines.
• Fournissez une option de navigation Back sur les flows multi-étapes, sauf si la navigation arrière corromprait les données.
• Utilisez lightning-input et des composants conformes à SLDS pour toutes les entrées utilisateur — n'utilisez pas d'éléments de formulaire HTML.
• Validez les entrées requises sur l'écran avant que l'utilisateur puisse avancer — utilisez les règles de validation Flow sur l'écran.
• Gérez l'élément Pause si le flow pourrait avoir besoin d'attendre une action utilisateur entre les sessions.

Étape 7 — Sécurité du déploiement

Déployer en tant que brouillon    →   Tester avec 1 enregistrement   →   Tester avec 200+ enregistrements   →   Activer

• Toujours déployer en tant que Draft en premier et tester en détail avant activation.
• Pour les Record-Triggered Flows : testez avec les conditions d'entrée exactes (par exemple ISCHANGED(Status) — assurez-vous que les données de test déclenchent réellement la condition).
• Pour les Scheduled Flows : testez avec un petit lot dans un sandbox avant d'activer en production.
• Vérifiez le score Automation Density pour l'objet — plus de 3 automatisations actives sur un seul objet augmente le risque lié à l'ordre d'exécution.

Référence rapide — Résumé des anti-modèles de Flow