Les screenflows, vous connaissez, les composants vous connaissez aussi, mais vous voudriez plus d’interactions dans tout ça ? Vous aimeriez que vos composants puissent influer sur le screenflow ou avec d’autres composants dans ce flow ?

 

Ne scrollez pas, vous êtes au bon endroit, je vais vous expliquer.

 

L’explication par l’exemple

Laissez-moi prendre en exemple un screen flow dans lequel je voudrais deux listes de sélection personnalisée ayant chacune comme consigne les éléments suivants :

• Prendre en entrée une variable pour filtrer les contacts sélectionnables que je nommerai “filtersearch”.
• Fournir en sortie une variable pouvant servir de filtre à une deuxième instance de ce même composant que je nommerai “outputfilter”.
• Fournir en sortie une variable avec la valeur (ID) de contact sélectionné simplement nommée “value”.

 

1/ Le composant lightning

a – Paramétrage du composant (.js-meta.xml)

Afin que les variables d’entrée et de sortie soient visibles dans le screenflow, il faut avant tout les déclarer dans le composant.

Je dois donc définir comme “target” le lightning__FlowScreen et sa configuration associée pour exposer les variables “filtersearch”, “outputfilter” et “value”.

 

 

Ici, sur la “targetConfig” lightning__FlowScreen, pour chaque propriété, je peux utiliser l’attribut “role” afin de ne rendre les variables visibles qu’en entrée ou en sortie.

 

b – Le code du composant (.js)

Pour que le composant puisse notifier le screenflow qu’une variable à été modifiée, je dois tout d’abord importer l’événement “FlowAttributeChangeEvent”.

Il n’est pas nécessaire d’installer un package tiers, puisque cet événement fait partie intégrante des lightning web components Salesforce.

 

 

Pour les variables d’entrée, c’est également très simple, puisqu’il suffit de les déclarer avec l’annotation “api”.

 

 

Mon éditeur de code (ici VSCode) m’a automatiquement proposé d’insérer l’import “api” adéquat.

 

 

Dans cet article, je ne vais pas rentrer dans le détail complet du composant, mais pour faire simple, je vais prendre la variable d’entrée “filtersearch” et, si elle n’est pas vide ou nulle, m’en servir comme condition WHERE dans une SOQL effectuée par le composant (via une classe Apex) pour lister les contacts différents de celui déjà sélectionné par une autre instance du composant. Le format des variables “filtersearch” et “outputfilter” doit donc être de la forme “Id <> ‘randomID’”.

La modification de la variable “filtersearch” doit donc déclencher une nouvelle requête pour mettre à jour la liste de sélection du composant.

De même, tout changement de sélection doit fournir en sortie les variables “outputfilter” et “value” mises à jour et en informer le screenflow pour que ce dernier les prenne en compte.

Je vais donc passer outre la première partie concernant  le “filtersearch” , car ce n’est pas l’objet principal de cet article, afin de me concentrer sur la constitution de la valeur mise à jour ainsi que sur sa notification au Screenflow, dans le but de permettre au composant de propager ces valeurs à mon flux ainsi qu’aux autres instances du composant qui y sont intégrées.

Je crée donc une fonction JS qui sera appelée sur l’événement onclick/onchange du composant de liste html qui est chargé d’informer le flow des modifications de valeurs des variables.

 

 

Je ne détaille pas ici la classe apex utilisée par le composant pour générer et exécuter la SOQL avec potentiellement le filtre sur la valeur de “filtersearch” (car oui, il faut aussi considérer le cas du composant qui ne prend pas la valeur de “filtersearch” en compte.

Je vais juste pour la suite de l’article considérer que mon composant se nomme intf_CustomLookupInputField.

 

2/ Le screen flow

Maintenant que mon composant est réalisé et déployé dans mon org, je crée un screenflow. Dans mon écran, je vais pouvoir y intégrer 2 fois ce dernier.

Les composants lightning se trouvent dans la liste des composants sous la catégorie custom.

Sur ma capture d’écran ci-dessous, j’ai utilisé le composant à deux reprises à titre d’exemple. Le premier composant ne reçoit aucun paramètre d’entrée, ce qui lui permet d’afficher tous les contacts auxquels j’ai accès. En revanche, pour le second composant, j’ai renseigné dans “filtersearch” la valeur de sortie du premier composant, de manière à ce que la deuxième liste affiche tous les contacts visibles, à l’exception de celui sélectionné dans la première liste (première instance du composant).

 

L’éditeur de flow Salesforce me simplifie la tâche en me proposant directement les composants d’écran que j’ai utilisé dans mon écran, ainsi que les variables de sorties disponibles.

 

 

Dans les étapes suivantes du flow (en sortie de l’écran), il est également très aisé de récupérer la valeur (via l’attribut “value” des composants d’écran) sélectionnée dans chacun de mes composants lightning afin de les attribuer à un enregistrement ou m’en servir dans des conditions par exemple.

 

Il ne reste plus qu’à enregistrer et tester le composant dans le screenflow qui se comporte de la sorte :

• Je sélectionne un contact dans ma première liste.
• Mon composant notifie le flow que la variable “value” a été modifiée.
• Mon composant notifie le flow que la variable “outputfilter” a été modifiée.
• Le flow transmet automatiquement (propagation) cette modification à mon second composant dans la variable “filtersearch”.
• Mon second composant déclenche le rafraîchissement des options de liste.
• Mon second composant ne me propose plus le contact sélectionné dans le premier composant.

 

Dans ces captures d’écran, dans la liste Nom, j’ai choisi Rose, et je vois bien que dans ma seconde liste ce contact n’est plus disponible.

 

 

Mission réussie donc. Bien sûr, il est possible d’aller beaucoup plus loin et cela ouvre la voie à des composants non seulement très utiles, mais réutilisables à souhait et paramétrables par nos amis consultants fonctionnels.

 

Je vous invite également à consulter la documentation Salesforce à propos du support des flows dans les LWC.