Ce que Flow est, et pourquoi il a remplacé tout le reste
Salesforce Flow est le moteur d'automatisation de la plateforme. Il se construit dans une interface visuelle où l'on pose des éléments et des conditions, sans écrire de syntaxe. C'est aujourd'hui le seul outil sur lequel Salesforce investit encore.
Avant lui, la plateforme proposait trois outils qui se recouvraient en partie : Workflow Rules, Process Builder et Flow. Salesforce a tranché en concentrant tout sur Flow, et en engageant le retrait des deux autres. Concrètement, si votre org tourne encore sur les anciens outils, vous avez un chantier de migration qui vous attend, et ce chantier n'est pas optionnel.
Le point qui surprend le plus mes clients, c'est l'étendue de ce qui est faisable sans développement. La frontière du déclaratif s'est déplacée très loin ces dernières années, et beaucoup d'orgs contiennent du code écrit à une époque où il était indispensable, qui ne le serait plus aujourd'hui.
Les quatre familles de Flow
Choisir le bon type conditionne tout le reste. C'est la première question que je pose devant un besoin d'automatisation.
Le Flow déclenché par un enregistrement
C'est celui qu'on utilise le plus. Il se déclenche quand un enregistrement est créé, modifié ou supprimé, et il travaille sans que l'utilisateur voie quoi que ce soit.
Il existe en deux moments, et la distinction compte. Le Flow avant enregistrement modifie l'enregistrement en cours de sauvegarde, sans écriture supplémentaire : c'est le plus rapide, et c'est celui qu'il faut privilégier quand il s'agit simplement de remplir ou de normaliser un champ sur la fiche elle-même. Le Flow après enregistrement, lui, sert dès qu'il faut agir ailleurs : créer un enregistrement lié, envoyer une notification, déclencher une approbation.
Le Flow d'écran
Celui-ci parle à l'utilisateur. Il affiche une suite d'écrans, pose des questions, et se comporte différemment selon les réponses. On l'utilise pour guider une saisie qui traverse plusieurs objets, ou pour encadrer un processus que l'on ne veut pas laisser à l'improvisation.
Le Flow planifié
Il tourne à heure fixe sur un ensemble d'enregistrements. C'est l'outil des relances, des contrôles de cohérence nocturnes, et des mises à jour périodiques. Discret par nature, il mérite d'être documenté avec soin : c'est typiquement le traitement que personne ne retrouve deux ans plus tard.
Le Flow appelé par un autre
Il ne se déclenche pas seul, il est invoqué depuis un autre Flow, depuis un bouton ou depuis du code. C'est le mécanisme de réutilisation : une logique écrite une fois, appelée à plusieurs endroits, corrigée en un seul.
Ce que vous pouvez automatiser dès aujourd'hui
Voici ce que je mets en place le plus souvent, sans une ligne de code.
- Remplir un champ à partir d'un autre enregistrement. Récupérer les conditions de paiement du compte au moment où l'opportunité est créée, par exemple, pour que le commercial n'ait rien à ressaisir.
- Normaliser une donnée à la saisie. Mettre un format en forme, proposer l'indicatif téléphonique correspondant au pays du compte, uniformiser une casse. C'est le meilleur investissement pour la qualité de vos données, parce qu'il agit à la source.
- Créer les enregistrements liés automatiquement. Les tâches de suivi à la signature, les lignes attendues sur un nouveau contrat, la fiche de livraison associée à une commande.
- Prévenir la bonne personne au bon moment. Notification interne, email, publication dans un canal de discussion, en s'appuyant sur des conditions précises plutôt que sur une alerte qui se déclenche tout le temps et que plus personne ne lit.
- Bloquer une saisie non conforme. Refuser l'enregistrement avec un message compréhensible quand une règle métier n'est pas respectée, y compris quand cette règle dépend de données situées ailleurs dans l'org.
- Lancer une approbation selon des conditions calculées. Un montant, une remise, un pays de livraison, une combinaison des trois.
- Guider une saisie complexe par un écran unique. Remplacer un parcours en trois étapes sur trois objets par un formulaire séquentiel.
- Faire tourner un contrôle périodique. Repérer les enregistrements incomplets, les affaires sans activité depuis trop longtemps, les incohérences entre deux champs.
Un exemple concret, sans code
Chez un acteur du négoce, certaines combinaisons de marque et de pays de livraison sont interdites par des accords de distribution. Le contrôle se faisait de tête, et une commande non conforme se rattrapait après coup, quand elle se rattrapait.
Le dispositif de conformité export mis en place est entièrement déclaratif. Les combinaisons autorisées sont stockées dans un objet de paramétrage, que l'équipe met à jour elle-même sans intervention technique. Un Flow lit ce paramétrage au moment de la saisie et bloque l'enregistrement non conforme avec un message explicite.
Ce point est le plus important, et il n'a rien de technique : les règles vivent dans des données, pas dans l'automatisation. Le jour où un accord change, personne n'a besoin de moi.
Là où Flow s'arrête
Autant être clair sur la frontière, parce qu'un intervenant qui prétend tout faire en déclaratif vous mènera dans une impasse.
Les interfaces vraiment sur mesure. Un Flow d'écran offre des composants standard. Dès que l'ergonomie visée sort de ce cadre, avec une mise en page particulière ou des interactions riches, il faut un composant Lightning Web Component.
Les traitements de gros volumes. La plateforme impose des limites par transaction, et une automatisation qui parcourt des milliers d'enregistrements les atteint. À ce niveau, du code écrit pour le traitement par lots est plus adapté.
Les intégrations complexes. Flow sait appeler un service externe dans des cas simples. Dès qu'il faut gérer l'authentification, la reprise après incident et le rejeu, on quitte son domaine.
Les logiques algorithmiques. Un calcul qui exige des boucles imbriquées, un tri élaboré ou une récursion se construit dans Flow au prix d'une usine à gaz illisible. Vingt lignes d'Apex sont plus maintenables que quarante éléments graphiques.
Ma règle est simple : je cherche d'abord la solution déclarative, et je passe au code quand le déclaratif produirait quelque chose que personne ne pourra reprendre. Le critère n'est pas la pureté, c'est la maintenabilité.
Ce que Flow ne dispense pas de faire
L'absence de code ne veut pas dire l'absence de méthode, et c'est le malentendu qui coûte le plus cher.
Un Flow se conçoit et se teste dans une sandbox, jamais directement en production. Il se documente, parce qu'un diagramme lisible aujourd'hui ne le sera plus dans deux ans pour quelqu'un qui n'était pas là. Il se teste sur plusieurs enregistrements à la fois, et pas seulement sur le cas idéal. Il prévoit ce qui se passe quand une étape échoue, sans quoi vous récolterez des erreurs de Flow silencieuses.
C'est exactement ce qui distingue une automatisation qui tient d'une automatisation qu'il faudra reprendre.
Par où commencer
Ne commencez pas par le Flow le plus impressionnant. Commencez par celui qui supprime la tâche la plus répétitive et la plus visible, celle dont vos utilisateurs parlent spontanément.
Prenez le processus qui fait le plus ressaisir, mesurez ce qu'il coûte en minutes, et regardez ce qu'un Salesforce Flow peut en retirer. Un gain modeste mais quotidien fait plus pour l'adoption qu'une automatisation spectaculaire dont personne ne comprend le fonctionnement.
Si vous ne savez pas où se trouvent ces gains, c'est le rôle d'un audit de votre org : il liste les automatisations existantes, celles qui font doublon, et les processus manuels qui mériteraient d'en devenir.
Questions fréquentes
Faut-il savoir coder pour construire un Salesforce Flow ?
Non. Flow se construit dans une interface visuelle, en posant des éléments et des conditions. Ce qui est exigeant, ce n'est pas la syntaxe, c'est la logique : savoir ce qui doit se déclencher, dans quel ordre, et ce qui se passe quand une étape échoue.
Un Flow peut-il remplacer du code Apex existant ?
Souvent oui, quand le code se contente de mettre à jour des champs ou de créer des enregistrements liés. Cela reste un chantier à part entière : il faut désactiver le déclencheur Apex, reconstruire la logique, tester sur des cas réels, et vérifier qu'aucun autre traitement n'en dépendait.