Comment automatiser Salesforce : Flow ou Apex ?

Flow par défaut pour la logique métier simple

Un Record-Triggered Flow gère sans code les cas courants : mise à jour de champs à la création ou à la modification, création d'enregistrements liés, envoi d'emails, lancement d'approbations. Il est lisible par un administrateur, versionné dans Salesforce et déployable sans compilation.

• Préférer les flows avant enregistrement pour mettre à jour l'enregistrement déclencheur : plus rapides, sans DML supplémentaire.
• Plusieurs flows par objet sont possibles : l'explorateur de déclencheurs et le champ d'ordre de déclenchement fixent leur séquence. Le risque n'est pas leur nombre mais leur prolifération sans responsable.
• Des chemins d'erreur sur chaque action qui peut échouer, avec un message exploitable plutôt qu'une erreur générique.

Apex quand la logique devient algorithmique

Apex s'impose quand il faut parcourir des collections imbriquées, appliquer des règles complexes, appeler des services externes avec une gestion d'erreurs fine, ou traiter de gros volumes en asynchrone avec Batch Apex ou Queueable. Le code Apex doit être couvert à 75 % au moins par des tests pour être déployé en production.

• Un seul trigger par objet, qui délègue à une classe de gestion : le pattern trigger handler.
• Du code bulkifié dès la première ligne : jamais de requête ou de DML dans une boucle.
• Des tests qui couvrent les cas limites et les gros volumes.

Les limites de gouverneur s'appliquent aux deux

Une transaction synchrone dispose par exemple de 100 requêtes SOQL et de 150 instructions DML. Flow et Apex consomment ces mêmes compteurs. Un flow mal conçu, avec une boucle qui fait une requête par enregistrement, échouera sur un chargement de masse exactement comme un Apex non bulkifié. Les tests de volume font partie de la recette, quel que soit l'outil.

Tester les flows comme le code

Les tests de flow, disponibles depuis fin 2022 pour les flows déclenchés par un enregistrement, vérifient le résultat attendu sur des cas définis. Contrairement aux tests Apex, ils ne sont pas obligatoires pour déployer, ce qui pousse à les négliger. On les exige dans la recette au même titre que les tests Apex.

Prévoir les chargements de masse

Lors des imports et des migrations, les automatisations se déclenchent sur chaque enregistrement. Une permission personnalisée de contournement, vérifiée dans les flows, les triggers et les règles de validation, permet de les désactiver pour l'utilisateur de chargement sans toucher au paramétrage. Le sujet est détaillé dans le guide Data Loader ou script.

Les erreurs fréquentes

• Des flows sans chemin d'erreur, qui bloquent l'utilisateur avec un message incompréhensible.
• Plusieurs automatisations qui écrivent le même champ, avec un résultat qui dépend de l'ordre d'exécution.
• La même logique dupliquée entre un flow et un trigger, qui finissent par diverger.
• Des emails envoyés aux clients pendant un import, faute de contournement prévu.

Une grille de décision simple

• Logique déclarative, maintenue par les administrateurs, volumes raisonnables : Flow.
• Calculs complexes, intégrations avec gestion d'erreurs, traitements asynchrones de masse : Apex.
• Logique partagée entre plusieurs automatisations : une action Apex invocable appelée depuis les flows.
• Dans tous les cas : documentation, convention de nommage et un propriétaire identifié par automatisation.