Flow for Service – Actions and Recommendations

Les flows s’imposent de plus en plus dans le paysage Salesforce. On les retrouve à plusieurs endroits et notamment avec Flow for Service. Salesforce Flow for Service va permettre d’afficher une liste de tâches à faire (to-do list) au travers du composant Actions and Recommendations.

Salesforce Flow for Service

Cette fonctionnalité va notamment aider les agents d’un call-center afin qu’ils déroulent des processus sans oublier d’étapes. Cela va également offrir une expérience consistante aux utilisateurs. Par ailleurs l’utilisation de flows autorisera la suspension de certaines tâches et les reprendre quand les informations manquantes seront récupérées.

Actions and Recommendations

Le composant Actions and Recommendations va s’appuyer sur 3 types d’actions :

• Flow
• Quick Action
• Recommendation (provenant d’Einstein NBA, Next Best Action)

Il s’agit d’un composant standard que l’on va pouvoir ajouter avec le Lightning App Builder :

Afin d’alimenter le contenu des tâches, on va avoir le choix entre utiliser un déploiement ou créer à la volée les tâches. En effet, celles-ci sont stockées dans l’objet RecordAction. Un autre objet associé, RecordActionHistory contiendra quant à lui l’historique des tâches traitées.

Jennifer Lee décrit très bien le deuxième cas dans son article de blog. Le scénario montre comment créer des tâches de type flow et quick action grâce à un flow. Dans notre article, nous allons opter pour le premier cas, à savoir un déploiement qui va faire appel à des flows.

Lister ses tâches et préparer ses flows

Dans l’ordre, il va falloir :

• Lister la succession de tâches à réaliser
• Créer les flows pour chaque tâche
• Créer un déploiement
• Faire appel à ce déploiement via le composant Action and Recommendations

Scénario : une société suit ses salariés (en tant que Contacts) dans Salesforce. Le service RH doit gérer le changement d’adresse d’un salarié et prévenir sa comptabilité externalisée ainsi que la Mutuelle santé couvrant les salariés. Dès que la RH est informée par le salarié, il faut en premier lieu récupérer l’adresse et la mettre à jour dans Salesforce. Ensuite il faut la communiquer à la comptabilité externalisée (qui traite les fiches de paie) et également à la mutuelle. Enfin, la RH vérifie que les nouvelles fiches de paie mentionnent la nouvelle adresse.

Les étapes identifiées dans ce cas sont les suivantes :

• Récupérer la nouvelle adresse
• Prévenir le service comptable
• Prévenir la mutuelle
• Vérifier la prochaine fiche de paie

N.B. : on pourrait utiliser des quick actions (par exemple, enregistrer un appel téléphonique, envoyer un mail avec un template prédéfini) ou des recommandations (générées via Einstein NBA). Nous nous concentrons uniquement sur des flows dans notre scénario. Celui-ci est volontairement simple et certaines tâches pourraient être traitées différemment.

Une fois les étapes listées, il faut créer les flows correspondant à chaque étape. On peut commencer par les initier avec un simple screen flow pour les compléter ensuite. Nous ne rentrons pas dans le détail même des flows, le but étant de présenter le composant Action and Recommendations.

S’ils concernent un même processus, nous vous conseillons de les préfixer afin de les retrouver plus facilement (et même les regrouper dans une vue) :

Créer une todo list avec un déploiement

Depuis Setup | Home | User Interface | Actions & Recommendations, cliquer sur New Deployment :

Cliquer sur Next puis renseigner le nom du déploiement et préciser le type d’actions que l’on va utiliser (ici, on ne coche que Flows and quick actions) :

Préciser sur quel(s) objet(s) on veut faire apparaître la liste de tâches. Dans notre exemple, il s’agit de l’objet Contact :

Dans l’écran suivant, il faut choisir le canal d’affichage des tâches parmi Chat, Phone et Default. En effet, ce composant est destiné à l’origine pour les agents d’une équipe support. On a la possibilité de faire des variantes par canal. A minima, il faut renseigner Default qui va afficher des tâches par défaut si on n’est pas dans le contexte d’un Chat ou appel téléphonique.

Plus que la section (Top pinned, Unpinned, Bottom pinned), l’important est surtout l’ordre d’affichage des tâches. On peut rendre une tâche obligatoire (Mandatory) ou optionnelle (Removable). Dans notre exemple, pour un salarié exempté de mutuelle, la tâche prévenir la mutuelle pourra ainsi être supprimée.

Enfin, l’utilisateur a la possibilité de rajouter des tâches. Cela peut être pratique pour gérer des cas exceptionnels que l’on ne souhaite pas faire apparaître par défaut ou bien remettre une tâche supprimée par erreur ou à refaire :

Ajouter le composant Actions and Recommendations

Il reste à ajouter le composant sur la page Lightning.

Il est fortement déconseillé d’ajouter le composant plus d’une fois sur la page. Toutefois, on peut souhaiter gérer plusieurs processus pour un même objet (arrivée d’un collaborateur, changement d’adresse, …).

Il vaut mieux dans ce cas utiliser la méthode qui alimente les tâches à la volée (via un Flow créant des RecordActions) afin de maitriser les tâches à faire apparaitre.

Il faut comprendre que dès l’apparition du composant, l’ensemble des tâches du déploiement sont chargées. On peut les voir apparaître dans l’objet RecordAction en filtrant sur le RecordId (correspondant à l’Id de notre contact ici) :

SELECT Id,  CreatedDate, RecordId, Order, Status, Pinned, ActionType, ActionDefinition, IsMandatory, IsUiRemoveHidden FROM RecordAction WHERE RecordId = '00309000019bQWRAA2'

Si l’on souhaite utiliser la méthode des déploiements avec 2 composants, il faudra s’assurer qu’ils n’apparaissent jamais au même moment. On peut appliquer des règles de visibilité conditionnée. Dans le cas contraire, les 2 composants afficheront la même chose (tâches d’un seul des processus) !

De même si des tâches étaient en cours pour un déploiement, le fait de masquer le composant (Processus A) et faire apparaître le deuxième (Processus B) va perturber le deuxième composant qui affichera les tâches en cours du premier déploiement (Processus A) !

Objets RecordAction et RecordActionHistory

Côté utilisateur, quand le composant apparaît, il suffit simplement de cliquer sur les tâches de la to-do list pour les exécuter. Tant que l’on reste sur l’écran, on verra une coche indiquant qu’une tâche a été traitée :

Mais si l’on rafraichit la page, seules les tâches à faire ou en cours sont visibles dans l’onglet Actions.

On peut tout de même voir les tâches traitées dans l’onglet History. Une tâche traitée va disparaitre de l’objet RecordAction et se retrouver dans RecordActionHistory. Pour ne pas être noyé, cliquer sur le filtre afin de ne voir que les tâches Completed :

L’utilisateur a la possibilité de suspendre une tâche (avec le bouton Pause du flux) et de la reprendre ultérieurement en cliquant sur Resume Paused Actions.

Rappel : lorsque l’on met un flux en pause, on peut indiquer un motif. Celui-ci n’est pas visible dans le composant mais via le menu Setup | Process Automation | Paused And Failed Flow Interviews.

Il peut aussi cliquer sur le bouton Add et rajouter des tâches (que l’on a configurée précédemment dans le déploiement) :

Une fois que l’ensemble des tâches sont terminées, le composant va recharger la liste des tâches initiales si on ne masque pas le composant et rafraichit la page.

Pour éviter cela, la dernière tâche peut inclure une mise à jour d’un champ (par exemple case à cocher) qui va déterminer si le composant s’affiche ou pas.

N.B.: une tâche mise en pause va rester dans l’objet RecordAction au statut Paused. Par contre, cette tâche ne sera pas considérée comme une tâche en cours. Par conséquent, si la dernière tâche du processus est mise en pause, le composant rechargera l’ensemble des tâches. Une solution consiste à enlever le bouton Pause de la dernière tâche ou créer une dernière tache de confirmation de fin du processus.

Plus besoin de se rappeler de l’ordre et de l’ensemble des tâches à effectuer pour vos processus complexes !