Ce qu'un Screen Flow fait, et ce qu'il n'est pas
Un Screen Flow, ou Flow d'écran, affiche une suite d'écrans à l'utilisateur, recueille ce qu'il saisit, et agit ensuite selon ses réponses. Il se construit visuellement, sans développement.
Ce n'est pas un formulaire de plus. La différence tient à un mot : la séquence. Une page classique montre tout d'un coup et laisse l'utilisateur naviguer librement. Un Flow d'écran impose un chemin, pose les questions dans l'ordre, et adapte la suite à ce qui vient d'être répondu.
Cette contrainte est parfois exactement ce qu'il faut, et parfois exactement ce qu'il ne faut pas. Tout l'art consiste à savoir dans quel cas on se trouve.
Les quatre situations où il gagne
1. La saisie traverse plusieurs objets
C'est le cas le plus net. L'utilisateur doit créer un compte, puis un contact, puis une opportunité, en recopiant des informations d'un écran à l'autre. Sur une page classique, cela signifie trois créations successives, trois navigations, et autant d'occasions de se tromper.
Un Flow d'écran pose les questions une fois et crée les trois enregistrements dans la foulée, avec les liens entre eux déjà en place. Le gain se mesure en minutes par saisie, et en erreurs évitées.
2. Le processus ne doit pas être improvisé
Certaines démarches ont un ordre qui compte : qualifier avant de chiffrer, vérifier une éligibilité avant d'engager, recueillir un accord avant de déclencher. Sur une page classique, rien n'empêche de remplir les champs dans n'importe quel ordre, ni d'en oublier.
Un écran guidé rend l'ordre obligatoire sans avoir besoin de le rappeler dans une procédure que personne ne lit. La règle vit dans l'outil plutôt que dans un document.
3. L'utilisateur est occasionnel
Un commercial qui saisit dix opportunités par jour connaît sa page par cœur, et toute forme de guidage le ralentit. Un utilisateur qui ouvre Salesforce deux fois par mois, lui, redécouvre l'interface à chaque fois.
Pour ce second profil, un Flow d'écran divise le temps de saisie et supprime les questions au support. C'est aussi ce qui évite les licences dormantes : un utilisateur occasionnel qui trouve l'outil pénible cesse de l'ouvrir.
4. Il faut décider avant de créer
Parfois le résultat de la saisie dépend des réponses. Selon le type de demande, on ne crée pas le même enregistrement, on ne prévient pas la même équipe, on ne demande pas les mêmes pièces.
Sur une page classique, cela se traduit par des champs conditionnels et des consignes orales. Dans un Flow d'écran, l'aiguillage est explicite : l'utilisateur répond, le parcours s'adapte, et il ne voit jamais les questions qui ne le concernent pas.
Les trois situations où il perd
Le Screen Flow est souvent proposé là où il n'apporte rien, et il faut savoir dire non.
Pour consulter. Un Flow d'écran sert à saisir et à décider, pas à regarder. Pour consulter une fiche, la page standard est plus rapide et plus complète.
Pour une saisie experte et répétitive. L'utilisateur qui connaît son écran veut tout voir d'un coup et remplir dans son propre ordre. Lui imposer une séquence, c'est le ralentir, et il vous le fera savoir.
Quand l'ergonomie visée sort du cadre. Les composants d'écran standard couvrent l'essentiel, mais restent standard. Dès que le besoin exige une mise en page particulière, un tableau éditable dense ou des interactions riches, il faut un composant Lightning Web Component. C'est précisément ce que j'ai développé pour un négociant dont la saisie de commande demandait un confort que les écrans standard ne donnaient pas.
Ces deux mondes ne s'opposent d'ailleurs pas : un composant sur mesure peut être intégré dans un Flow d'écran, ce qui permet de garder le déclaratif partout où il suffit et de ne développer que le morceau qui l'exige.
Où le poser, la question qui décide de l'adoption
Un Flow d'écran parfaitement conçu que personne ne trouve ne sert à rien. L'endroit où vous le placez compte autant que son contenu.
Il peut être posé directement sur une page Lightning, déclenché par un bouton ou une action rapide, rendu disponible dans l'application mobile, publié sur un site Experience Cloud pour des utilisateurs externes, ou appelé depuis un autre Flow.
Ma règle est de ne jamais créer un nouveau point d'entrée quand un existant fait l'affaire. Si vos utilisateurs cliquent depuis deux ans sur un bouton pour créer une commande, gardez ce bouton et changez ce qu'il ouvre. Ils n'ont aucune nouvelle habitude à prendre, et l'adoption est immédiate.
C'est le retour d'expérience qui m'a le plus servi : la meilleure automatisation est celle qui ne demande à personne de changer sa façon d'arriver jusqu'à elle.
Trois erreurs de conception qui se voient tout de suite
Trop d'écrans. Découper une saisie en huit étapes parce que c'est possible transforme une minute en cinq. Regroupez ce qui va ensemble, et n'ajoutez un écran que quand la suite dépend vraiment de la réponse précédente.
Aucun retour en arrière. Un utilisateur qui se trompe à l'étape deux et découvre son erreur à l'étape quatre doit pouvoir revenir sans tout recommencer. C'est un réglage simple, et son absence suffit à faire détester un parcours.
Aucun message en cas d'échec. Si la création échoue à la dernière étape, l'utilisateur doit savoir ce qui s'est passé et ce qu'il doit faire. Un écran de fin qui confirme, et un chemin prévu pour l'erreur, font toute la différence entre un outil dans lequel on a confiance et un outil qu'on double par précaution.
Un ordre de grandeur, pour situer l'effort
La question qui suit immédiatement est toujours la même : est-ce que cela vaut la peine.
Un parcours simple, deux ou trois écrans qui créent un enregistrement et remplissent quelques champs, se construit et se teste en moins d'une journée. Un parcours qui traverse plusieurs objets, avec des aiguillages selon les réponses et des contrôles en cours de route, se compte plutôt en deux à trois jours, tests inclus.
Ce qui pèse le plus n'est pas la construction, c'est la définition du parcours. Décider quelles questions poser, dans quel ordre, et quoi faire des réponses demande de s'asseoir avec ceux qui saisissent tous les jours. Cette étape ne se sous-traite pas, et c'est elle qui fait la différence entre un écran adopté et un écran contourné.
Ce qu'il faut vérifier avant de le mettre en service
Un Flow d'écran se construit dans une sandbox et se teste avec les personnes qui l'utiliseront, pas seulement avec celle qui l'a conçu. Regardez-les l'utiliser sans les aider : les hésitations vous diront où le libellé est ambigu.
Vérifiez aussi le comportement quand les données sont incomplètes, quand l'utilisateur n'a pas les droits sur un objet manipulé, et quand il abandonne en cours de route. Un parcours qui laisse des enregistrements à moitié créés fait plus de dégâts que la saisie manuelle qu'il remplaçait.
Enfin, ne confondez pas guidage et contrôle. Un Screen Flow accompagne la saisie, il ne garantit pas la conformité de ce qui est saisi : les règles métier bloquantes restent du domaine de la règle de validation ou du Flow de validation, qui agissent quel que soit le chemin emprunté pour créer l'enregistrement.
Questions fréquentes
Un Screen Flow peut-il remplacer une page de saisie standard ?
Pour une saisie guidée qui traverse plusieurs objets, oui, et il fait souvent mieux. Pour la consultation d'une fiche ou pour une saisie rapide par un utilisateur expert, non : la page standard reste plus directe, parce qu'elle affiche tout d'un coup au lieu d'imposer une séquence.
Où peut-on placer un Screen Flow dans Salesforce ?
Sur une page Lightning, derrière un bouton ou une action rapide, dans l'application mobile, sur un site Experience Cloud, ou en appel depuis un autre Flow. C'est ce qui permet de le glisser dans un parcours existant sans changer les habitudes des utilisateurs.