Les flux de travail sont l'une des fonctions les plus polyvalentes de la plate-forme Kustomer . Les flux de travail peuvent automatiser une variété de tâches et de processus dans votre plateforme en créant des ensembles de règles qui déclenchent certaines actions basées sur des conditions prédéfinies. Bien qu'incroyablement puissant, en raison de la complexité de cette fonctionnalité, une variété d'erreurs et d'événements involontaires peuvent survenir si un flux de travail ne se déroule pas comme prévu.
Il existe plusieurs types d'erreurs que vous pouvez rencontrer dans un workflow. En outre, bien que certains problèmes de flux de travail ne soient pas spécifiquement liés à des erreurs, il existe des situations dans lesquelles vous avez pu voir un flux de travail ne se terminer que partiellement ou suivre le mauvais chemin. La compréhension de ces types de problèmes et de la manière d'en tenir compte peut contribuer à rendre vos workflows plus précis et moins susceptibles de dévier du chemin prévu.
Actions et conditions du flux de travail
Avant d'aborder les types spécifiques d'erreurs de Workflow, il est important de parler des journaux d'affichage, qui sont indispensables au dépannage des erreurs de Workflow. Dans un article de blog publié il y a quelques semaines, nous avons abordé le concept des journaux d'affichage et la façon de les consulter pour créer des flux de travail. En plus de ce qui est abordé dans cet article, les journaux de flux de travail sont également d'une importance vitale pour la résolution des problèmes que vous rencontrez dans votre flux de travail. Pour en savoir plus sur la façon d'accéder aux journaux d'affichage ainsi que sur les types de données qu'ils peuvent traiter, vous pouvez vous référer à l'article du blog lié ci-dessus.
Notre centre d'aide contient également des informations relatives à l'utilisation de ces journaux et des erreurs de workflow pour résoudre les problèmes. Vous y trouverez des informations très détaillées sur le dépannage général des erreurs de workflow. Dans ce blog, nous serons plus précis concernant les problèmes spécifiques que vous pouvez rencontrer et comment vous pouvez vérifier un problème dans votre workflow même s'il n'a pas été enregistré comme une erreur.
Le flux de travail ci-dessous est conçu pour ajouter une étiquette "Email Team" aux nouvelles conversations qui arrivent par ce canal. De plus, il en sera de même pour les chats avec une étiquette "équipe de chat".
Si nos journaux d'affichage sont activés au moment de l'exécution du flux de travail, nous pouvons vérifier les étapes par lesquelles le flux de travail est passé en inspectant les journaux d'affichage liés à cette interaction. Dans la capture d'écran ci-dessous, nous pouvons vérifier que le workflow est arrivé à son étape finale et qu'il a ajouté le tag à la conversation, comme nous pouvons le voir, les deux étapes du workflow ont réussi. Dans le cas d'un workflow qui se ramifie en différents chemins, nous pouvons également vérifier le chemin spécifique emprunté par le workflow en fonction des étapes mises en évidence dans les journaux.
Lorsqu'un flux de travail ne se déroule pas comme prévu, l'un des trois scénarios suivants entre généralement en jeu :
Scénario 1 : Le flux de travail ne satisfait pas à une condition
Dans ce scénario, un flux de travail n'atteindrait pas la fin de l'une de ses branches. Comme nous pouvons le voir sur ce workflow, chaque branche a un total de deux étapes d'action qu'il faudrait exécuter afin de terminer complètement. Dans ce cas, les journaux du workflow n'indiquent qu'une seule étape d'action comme étant terminée. Vérifiez les conditions que le flux de travail aurait dû exécuter et vérifiez si les données envoyées par les journaux d'affichage présentent une anomalie. Pour les flux de travail plus importants, il s'agit de la branche des conditions directement après la dernière étape d'action terminée.
Scénario 2 : Le flux de travail emprunte le mauvais chemin de flux de travail.
Dans certains cas, en inspectant les journaux d'affichage du flux de travail, vous pouvez observer que le flux de travail suit un chemin non intentionnel. Cela peut être dû à l'une des deux raisons suivantes :
- Le premier chemin (prévu) du flux de travail n'a pas été satisfait, le flux de travail a donc emprunté le prochain chemin disponible.
- Le Workflow satisfait plusieurs conditions dans la même branche de conditions. Dans ce cas, le flux de travail se déplacera vers la condition qu'il satisfait la plus proche de la gauche de la branche de condition, qui peut ne pas être la branche que vous vouliez qu'il se déplace.
La solution pour ces deux cas est à peu près la même. S'assurer que, dans un scénario spécifique, la branche de condition d'un flux de travail a des options diamétralement opposées. Par exemple, si une branche de condition cherche à ce que le seul canal de la conversation soit soit l'email ou le chat, il n'y aura jamais de moment où une conversation sera qualifiée pour plus d'une branche. Pour les branches où plusieurs satisfactions sont possibles, vous devez vous assurer que la branche qui sert d'option "dominante" est la plus proche du côté gauche de la branche.
Scénario 3 : Le flux de travail écrit des informations incorrectes grâce à une configuration erronée.
Il est également possible qu'un Workflow s'exécute avec succès, mais qu'il écrive les données incorrectes dans un attribut ou qu'il exploite les données correctes dans une étape de condition du Workflow. Cela peut également se produire pour l'une des deux raisons suivantes :
- La source des données n'est pas celle à laquelle vous vous attendiez initialement.
- L'attribut du Workflow utilisé pour satisfaire une condition ou écrire dans un champ est lié de manière incorrecte. Par exemple, lors de la vérification de l'ID d'une conversation dans un workflow, la condition peut être configurée de manière à extraire accidentellement l'ID d'un client.
Pour résoudre ces problèmes, vous devez vous assurer que l'ensemble de données à remplir dans un attribut ou à vérifier dans une condition est lié de manière appropriée en vérifiant l'étape et l'attribut auxquels les données sont liées. Cela peut être fait très facilement par le biais de la vue du code des données, comme indiqué ci-dessous.
En outre, vous voudrez également vous assurer que les données elles-mêmes sont conformes aux attentes de la source d'où vous les tirez en suivant ces mêmes étapes.
Erreurs d'API (Path/Data/DataType)
Dans les flux de travail, vous avez également la possibilité de créer des étapes d'action qui peuvent appeler l'API Kustomer ou d'autres API externes. Cela peut s'avérer extrêmement utile lorsqu'il s'agit de vérifier des informations provenant d'un autre système ou d'effectuer d'autres opérations en dehors du champ d'application traditionnel des étapes de flux de travail normales. Cela rend notre fonctionnalité de flux de travail exponentiellement plus puissante, mais comme tout ce dont nous avons parlé jusqu'à présent, les choses peuvent se tromper. C'est pourquoi il serait utile de passer en revue les types d'erreurs d'API que vous pouvez recevoir dans vos flux de travail.
Vous trouverez ci-dessous un flux de travail qui utilise une étape JSON de l'API REST pour appeler le point de terminaison de l'API de mise à jour des conversations et ajouter une balise "Conversation terminée" aux conversations qui ont été marquées comme terminées.
Les erreurs d'API dans les flux de travail peuvent être un peu plus cachées que de nombreuses erreurs de flux de travail traditionnelles, car elles se trouvent dans l'appel d'API lui-même, et non dans le flux de travail. En outre, les étapes d'appel d'API peuvent sembler s'exécuter avec succès même si la configuration prévue ne se produit pas. Lorsque vous consultez les journaux d'affichage, cliquez sur l'étape API. La partie de sortie des journaux vous montrera les résultats de l'appel API.
Le fait que cet appel d'API ait donné lieu à un statusCode de 200 est une bonne chose car cela indique généralement que l'appel a réussi ! Différents statusCodes apparaîtront dans cette sortie, liés à un problème plus spécifique que l'appel API a pu rencontrer. Par exemple, un code d'état 401 indique qu'il y a eu un problème d'autorisation de l'appel, ce qui signifie que vous voudrez probablement vérifier la clé API utilisée pour effectuer l'appel. Une erreur 400 peut indiquer que certains aspects de l'appel ne sont pas formatés correctement, comme les données ou l'URL. Vous devez vous assurer que tout le code lié à l'appel est correct, conformément à la documentation de l'API, avant de poursuivre le dépannage. Pour plus d'informations sur les codes d'état que vous pouvez rencontrer avec notre API, vous pouvez consulter notre documentation sur le sujet ici.
Un autre type de problème que vous pouvez rencontrer est que l'appel d'API peut ne pas traiter votre demande comme prévu. Par exemple, si vous essayez de mettre à jour un attribut de conversation via cet appel d'API, l'appel sera considéré comme réussi même si la partie données de la charge utile de l'appel d'API est vide. Cela est dû au fait que l'API a réussi à communiquer avec le serveur prévu. Les mêmes journaux ci-dessus vous indiqueront exactement ce qui a été configuré par le biais de l'appel et ces types de problèmes pourront être résolus à partir de là.
Flux de travail récursifs/en boucle
Un autre type d'erreur que vous pouvez rencontrer avec votre workflow est qu'il s'exécute en permanence. C'est ce que nous appelons communément un Workflow récursif. Par exemple, si vous avez un workflow qui se déclenche sur une mise à jour de conversation pour mettre à jour un autre attribut dans une conversation, ce type d'action de sortie serait également considéré comme une mise à jour de conversation, ce qui déclencherait une nouvelle exécution du workflow.
Un exemple de ceci serait un Workflow qui crée une note sur une conversation lorsque la conversation est mise à jour. Comme la non création est également une mise à jour de la conversation, cela déclencherait une nouvelle exécution du Workflow, créant une nouvelle note, déclenchant à nouveau le Workflow, et ainsi de suite.
Si vous constatez qu'un Workflow s'exécute involontairement plusieurs fois, la première chose à faire est de le désactiver pour couper la boucle. Ensuite, nous vous recommandons d'intégrer des conditions pour empêcher l'exécution ultérieure du workflow. Par exemple, lorsque vous mettez à jour un attribut dans une toute nouvelle conversation, vous pouvez ajouter une condition pour vérifier si l'attribut est vide au moment de la mise à jour. Cela vous permettra de mettre à jour l'attribut une fois et empêchera le flux de travail de s'exécuter plusieurs fois, car l'attribut aura une valeur lorsqu'il tentera de s'exécuter à nouveau.
Aussi puissants que soient les workflows, ils peuvent souvent prêter à confusion, en particulier pour une personne qui n'a pas initialement créé un workflow. En comprenant les différents types de problèmes susceptibles d'affecter le fonctionnement prévu d'un workflow, vous pouvez vous armer au mieux pour trouver les failles dans le workflow qui peuvent l'empêcher de fonctionner comme prévu.
Si vous avez des questions d'ordre général sur la manière de mieux comprendre les flux de travail dans leur ensemble, ou si vous avez besoin d'aide pour déboguer un problème, n'hésitez pas à contacter support@kustomer.com ou à consulter notre base de connaissances à l'adresse help.kustomer.com.
Kustomer L'université est une autre grande ressource, avec des vidéos et des tutoriels pour vous aider à mieux utiliser tout ce que Kustomer a à offrir.
