Lorsqu'une Procedure Fin ne résout pas une conversation comme prévu, vous pouvez utiliser les outils d'inspection intégrés pour analyser la logique de prise de décision de Fin. Utilisez ce guide pour identifier où un flux a déraillé et comment affiner vos instructions.

Ce que vous apprendrez

Déboguez les échecs de Procedure en utilisant les pensées de Fin et les événements de conversation.
Diagnostiquez les problèmes courants tels que les déclencheurs de Procedure erronés, les étapes hors séquence et les échecs de branchement.
Dépannez les erreurs des connecteurs de données, y compris les échecs d'authentification et les données manquantes.
Validez les corrections avant la mise en production en utilisant les Simulations.

Accéder au débogueur de conversation

Pour comprendre pourquoi Fin a pris une action spécifique, vous devez d'abord activer la visibilité technique dans le fil de conversation.

Ouvrez la conversation spécifique dans la Inbox.
Cliquez sur l'icône des trois points en haut à droite de l'en-tête de la conversation.
Sélectionnez Afficher les événements de conversation.

Astuce : Utilisez le raccourci clavier ⌘ + E (Mac) ou Ctrl + Shift + E (Windows) pour basculer cette vue.

Inspection des « pensées de Fin »

Une fois les événements de conversation visibles, vous pouvez voir le raisonnement derrière chaque étape que Fin a prise lors d'une Procedure. Pour retracer le processus de prise de décision de Fin, localisez les événements Fin's thoughts dans la chronologie de la conversation. Ces événements résument le raisonnement de Fin avant qu'il n'envoie un message ou n'effectue une action.

Pour plus de détails, cliquez sur Fin Thoughts puis sur Voir plus. Cela révèle :

L'étape actuelle : L'étape spécifique de la Procedure que Fin exécutait.
Interprétation de l'intention : Comment Fin a compris la demande du client.
Chemin logique : Pourquoi Fin a décidé de sauter une étape, de revenir à une précédente ou de passer à une branche spécifique.

Note : Cet article couvre uniquement le dépannage des Procedures Fin. La chronologie et le débogueur « Fin's thoughts » ne sont disponibles que lorsqu'une Procedure a été déclenchée. Si Fin a donné une réponse inattendue dans une conversation standard, ces outils ne seront pas présents dans les événements de conversation.

Échecs courants de Procedure

Si Fin ne fonctionne pas comme prévu, c'est généralement dû à la formulation des instructions ou à la manière dont la logique est branchée.

La Procedure ne se déclenche pas du tout

Avant de passer en revue les échecs numérotés ci-dessous, commencez par vérifier ces bases :

Vérifiez que la procedure est publiée : Les procedures en brouillon ne se déclenchent pas pour les clients. Confirmez que le statut est défini sur Published dans l'éditeur.
Vérifiez que Fin est déployé : Si Fin n'est pas activé via la section Simply Deploy, ou si l'étape « Let Fin handle » n'est pas active dans votre workflow, Fin ne lancera aucune procedure.
Vérifiez le ciblage de l'audience : Une erreur fréquente est de cibler les Users alors que le client est un Lead (ou inversement). Dans la section "When to use this procedure", cliquez sur le bouton d'audience et vérifiez que le type d'audience et le canal corrects sont sélectionnés.
Vérifiez l'existence de workflows à priorité plus élevée : Les workflows actifs s'exécutent avant que Fin n'évalue l'intention de la procedure. Passez en revue vos workflows pour vous assurer qu'aucun n'intercepte la conversation avant que Fin puisse déclencher la procedure.
Examinez la portée des critères de déclenchement : Des critères trop restrictifs empêchent Fin de reconnaître les messages clients valides. Vérifiez la description "When to use this procedure" et ajoutez des exemples positifs (messages qui devraient déclencher la procedure) et négatifs (messages qui ne devraient pas).

Note : Bien que Slack puisse apparaître comme un canal sélectionnable, les déclencheurs de procedure ne sont pas encore pris en charge pour les conversations Slack.

Fin déclenche la mauvaise Procedure

Problème : Fin démarre une Procedure qui ne correspond pas à la demande du client.

Solution : Passez en revue vos instructions "When to use this procedure". Utilisez des exemples positifs et négatifs pour aider Fin à distinguer des intentions similaires. Si une nouvelle procedure partage des critères de déclenchement similaires avec une procedure publiée existante, celle publiée peut avoir la priorité. Pour isoler la nouvelle procedure lors des tests : excluez temporairement votre utilisateur test de la procedure existante en ajustant ses critères d'audience, ou restreignez le déclencheur de la nouvelle procedure à une phrase unique que vous seul enverriez. Utilisez Fin's thoughts > Expand thoughts dans le débogueur de conversation pour confirmer quelle procedure a réellement été déclenchée.

Étapes hors séquence

Problème : Fin saute une étape préalable ou passe prématurément à une résolution.

Solution : Vérifiez l'ambiguïté dans vos instructions en langage naturel. Si une étape dépend d'une donnée spécifique, assurez-vous que l'instruction indique explicitement : « N'avancez que si [donnée] est fournie. »

Échecs de logique de branchement

Problème : Fin suit le chemin « Else » alors qu'il aurait dû suivre le chemin « If ».

Solution : Inspectez les Conditions. Si vous utilisez le langage naturel pour le branchement, essayez de reformuler pour plus de clarté. Pour une logique complexe (par exemple, calculs de dates), envisagez d'utiliser des blocs de code Python pour appliquer des règles strictes et déterministes.

Priorité du contenu du Help Center

Problème : Fin répond à partir du Help Center au lieu d'exécuter la procedure, même lorsque l'intention du client correspond clairement aux critères de déclenchement de la procedure.

Solution : Si Fin choisit par défaut une réponse du Help Center au lieu d'exécuter la procedure, deux approches sont possibles selon votre configuration. Essayez d'abord l'Option 1 — si le problème persiste, passez à l'Option 2.

Option 1 : Activer le changement de Procedure
Agentic Switch est un paramètre par procedure qui permet à Fin de passer automatiquement de la procedure en cours à une autre procedure active lorsqu'il détecte que l'intention du client a changé en cours de conversation — plutôt que de rester bloqué sur la procedure initiale ou de revenir à une réponse du Help Center. Lorsqu'il est activé :
- Fin analyse la conversation et toutes les descriptions des déclencheurs de procedure actives pour décider quand un changement serait plus bénéfique pour le client
- Si plusieurs procedures peuvent s'appliquer, Fin peut poser une question de clarification pour sélectionner la meilleure
- Seule la procedure source (celle dont Fin est en train de changer sortir) doit avoir ce paramètre activé
- La commande @Switch peut toujours être utilisée pour changer manuellement
Pour l'activer : Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Option 2 : Supprimer ou mettre à jour le contenu conflictuel du Help Center
Si l'activation de Agentic Switch ne résout pas le problème, la solution la plus fiable est de supprimer ou mettre à jour le contenu du Help Center que Fin affiche au lieu d'exécuter la procédure. Fin utilise par défaut les réponses du Help Center lorsque du contenu pertinent existe pour un sujet — donc si un article couvre la même intention que votre procédure, Fin peut répondre directement à partir de celui-ci plutôt que de déclencher la procédure.

Pour identifier le contenu conflictuel :
- Trouvez la conversation dans votre Inbox et ouvrez Fin's thoughts.
- Recherchez les références aux articles du Help Center dans le chemin de réponse.
- Supprimez l'article conflictuel ou mettez-le à jour pour diriger les clients vers le support, afin que Fin oriente vers la procédure à la place.

Exemple : Une entreprise a une procédure qui gère les demandes de remboursement - elle collecte le numéro de commande, vérifie l'éligibilité et traite automatiquement le remboursement. Elle a aussi un article du Help Center intitulé « Comment obtenir un remboursement ? » qui explique la politique de remboursement. Lorsqu'un client envoie « Je voudrais un remboursement », Fin trouve l'article du Help Center et répond avec l'explication de la politique au lieu de déclencher la procédure. Dans ce cas, mettre à jour l'article pour dire quelque chose comme « Pour demander un remboursement, démarrez un chat et notre assistant vous guidera » supprime la réponse conflictuelle et oriente les clients vers la procédure.

La procédure s'arrête ou se termine avant d'être complète

Problème : La procédure atteint une certaine étape et s'arrête, ou sort vers un état final sans compléter toutes les étapes attendues.

Solution : Cela est généralement causé par des modèles de conception qui perturbent la capacité de Fin à suivre sa position dans la procédure. Vérifiez les points suivants :

Instructions redondantes « Procéder immédiatement » : Si plusieurs étapes incluent des instructions comme « procéder immédiatement à l'étape suivante », Fin peut réévaluer des étapes déjà complétées au lieu d'avancer. Supprimez ces instructions et laissez Fin avancer naturellement selon le flux.
Instructions de saut d'étape : Des phrases comme « revenir à l'étape 2 » ou « répéter l'étape de vérification » peuvent faire boucler Fin entre les étapes au lieu d'avancer. Concevez chaque étape pour qu'il y ait un chemin clair vers l'avant.
Logique conditionnelle qui se chevauche : Si deux conditions peuvent être vraies en même temps, Fin peut bifurquer de manière imprévisible ou s'arrêter. Assurez-vous que vos conditions sont mutuellement exclusives — une seule branche doit être vraie à tout moment.
Sorties de sous-procédure sans continuation : Si une sous-procédure se termine mais que la procédure principale n'a pas d'instruction claire sur la suite, Fin peut considérer la fin de la sous-procédure comme la fin du flux entier. Dans l'étape qui appelle la sous-procédure, ajoutez une instruction explicite : « Une fois la sous-procédure terminée, continuez vers [nom de l'étape suivante]. »

Utilisez Fin's thoughts > Voir plus dans le débogueur de conversation pour identifier précisément à quelle étape Fin se trouvait lorsque la procédure s'est arrêtée de manière inattendue.

Problèmes mobiles (iOS) avec les procédures

Sur mobile (iOS), les procédures ont des exigences supplémentaires :

Utilisateurs uniquement : Les procédures ne se déclenchent que pour les Users sur mobile — elles ne s'exécutent pas pour les Leads ou les visiteurs, quelle que soit la configuration de l'audience dans la procédure.
Le canal iOS doit être ciblé : Dans la section « Quand utiliser cette procédure », iOS doit être sélectionné comme canal. La procédure ne se déclenchera pas sur mobile si seul Web est coché.
La procédure doit être publiée : Les procédures en brouillon ne sont pas servies aux clients mobiles.
Vérifiez que Fin est déployé pour iOS : Les procédures nécessitent que Fin soit actif sur le canal iOS. Confirmez que Simple Deploy est activé dans Fin AI Agent > Deploy > Chat, ou qu'il y a un bloc actif Let Fin Handle dans le workflow pertinent ciblant iOS.
Workflows à priorité plus élevée : Un workflow s'exécutant pour le même déclencheur de conversation sur iOS peut intercepter la conversation avant que Fin n'évalue l'intention de la procédure. Vérifiez vos workflows actifs pour les chevauchements sur le canal iOS.

Dépannage des connecteurs de données dans les procédures

Cette section couvre les échecs spécifiques aux connecteurs de données exécutés dans une procédure. Si votre connecteur passe les tests autonomes mais échoue lors d'une exécution en direct, commencez ici.

Le connecteur fonctionne en test mais échoue en procédure en direct

Problème : Le connecteur réussit les tests autonomes mais échoue lors d'une exécution en direct.

Solution : Cela est généralement causé par l'un des éléments suivants :

Identifiants : Enregistrez à nouveau et republiez après rotation d'une clé. Vérifiez la présence de caractères cachés comme des espaces en fin dans les valeurs de jeton.
Permissions : Un changement récent de sécurité sur votre système externe peut avoir supprimé l'accès.
Liste blanche IP : Confirmez que les IP sortantes d'Intercom sont incluses. Contactez votre gestionnaire de compte pour les plages actuelles.

Important : Si votre connecteur cesse de fonctionner sans changement de votre côté, vérifiez si votre fournisseur d'API externe (par exemple Shopify, Stripe) a mis à jour ou déprécié un point de terminaison.

Erreurs d'autorisation 401 et 403

401 Non autorisé : Le jeton est manquant, expiré ou mal formé. Intercom réessaie automatiquement une fois. Vérifiez l'onglet Logs pour confirmer si une actualisation a été tentée.
403 Interdit : Le jeton est valide mais sans permission. Vérifiez les permissions sur votre système externe.
Utilisateurs OAuth : Utilisez le bouton Réauthentifier au lieu de supprimer et recréer le jeton.

Le connecteur ne semble pas se déclencher

Vérifiez les logs : Allez dans Settings > Integrations > Data connectors > Logs. S'il n'y a aucune entrée de log, l'étape a probablement été sautée ; vérifiez la logique de branchement précédente.
Vérifiez les événements de conversation : Sélectionnez Logs depuis tout événement d'erreur dans la Inbox pour les détails complets.

Le connecteur renvoie des données mais Fin ne les utilise pas

Utilisez Fin's thoughts pour voir comment Fin a interprété la réponse du connecteur.
Rendez l'instruction de l'étape plus explicite : « Utilisez @connector_name pour répondre à ceci — ne pas utiliser le contenu de la knowledge base. »
Vérifiez si la réponse est vide ou nulle ; Fin peut revenir à d'autres sources si aucune donnée exploitable n'est trouvée.
Fin appelle un connecteur par tour : Si votre procédure doit effectuer plusieurs appels de connecteur en séquence, chaque appel doit être une étape distincte. Fin traite un appel d'outil par tour de conversation — il ne peut pas enchaîner plusieurs appels de connecteur dans une seule instruction d'étape.

Important : Fin ne peut traiter qu'un seul appel de connecteur par tour, donc si votre serveur MCP renvoie deux réponses distinctes sur le même flux SSE, Fin ne pourra pas utiliser de manière fiable la première réponse pour construire sa réponse.

Le connecteur n'apparaît pas dans l'éditeur de procédure

Problème : Votre connecteur de données est publié et configuré, mais il n'apparaît pas lorsque vous essayez de l'ajouter à une étape dans l'éditeur de procédure.

Solution : Suivez ces vérifications dans l'ordre :

Confirmez que le connecteur est en mode Live : Allez dans Settings > Integrations > Data connectors et vérifiez le statut du connecteur. Un connecteur en brouillon n'apparaîtra pas dans l'éditeur de procédure.
Vérifiez qu'au moins une action est configurée : Un connecteur sans actions définies n'apparaîtra pas comme option dans l'éditeur de procédure, même s'il est en mode Live.
Vérifiez vos permissions de rôle : Certains rôles peuvent voir les connecteurs dans Settings mais ne peuvent pas y accéder dans l'éditeur de procédure. Confirmez que votre rôle a accès aux deux zones.
Actualisez la page : L'éditeur de procédure nécessite parfois un rafraîchissement complet pour refléter les connecteurs récemment publiés. Utilisez ⌘ + Maj + R (Mac) ou Ctrl + Maj + R (Windows).
Contactez le support Fin : Si aucune des solutions ci-dessus ne fonctionne, contactez le support Fin avec le nom du connecteur et les détails de votre workspace. Certaines configurations de workspace nécessitent une étape manuelle pour rendre un connecteur disponible dans l'éditeur de procédure.

Le connecteur échoue en mode exécution automatique

Problème : Le connecteur de données est configuré pour s'exécuter automatiquement — sans solliciter le client — mais il échoue silencieusement lors d'une conversation en direct. Fin escalade ou donne une réponse inattendue, et il n'y a pas d'erreur visible dans la conversation.

Solution : En mode exécution automatique, Fin ne peut pas passer outre une étape de connecteur échouée et continuer la procédure. Si le connecteur renvoie une erreur, Fin considère toute l'étape comme non résoluble et escalade soit vers un humain, soit revient à son comportement par défaut.

Il y a deux façons de gérer cela :

Modifiez votre API externe pour retourner une valeur de secours : Au lieu de renvoyer une erreur lorsque les données ne sont pas disponibles (par exemple, un 404 lorsqu'une commande n'est pas trouvée), configurez votre API pour retourner un résultat vide ou par défaut sur lequel Fin peut agir. C'est la solution la plus fiable car Fin reçoit toujours quelque chose avec quoi travailler.
Ajoutez une étape Condition après l'appel du connecteur : Utilisez la sortie status_code du connecteur pour bifurquer vers un message approprié ou un chemin d'escalade contrôlé lorsque le connecteur échoue. Voir « Gestion avancée des échecs avec status_code » dans cet article pour savoir comment configurer cela.

La sortie du connecteur ne remplit pas les attributs de conversation

Problème : Une étape de connecteur de données s'exécute et renvoie les données attendues, mais la valeur n'apparaît pas comme un attribut de conversation — et les étapes suivantes de la procédure ne peuvent pas y accéder.

Solution : Les attributs de conversation sont définis au début d'une conversation et ne peuvent pas être mis à jour en temps réel pendant l'exécution d'une procédure. Un connecteur s'exécutant dans une procédure ne peut pas écrire une nouvelle valeur dans un attribut de conversation en cours de conversation.

Ce que cela signifie en pratique :

Utilisez directement la sortie du connecteur dans les étapes suivantes : Les données que votre connecteur renvoie sont disponibles comme sortie d'étape dans la procédure. Référez-vous à elles dans les instructions des étapes suivantes en utilisant la syntaxe de sortie @connector_name. La valeur est accessible dans la procédure — elle n'apparaîtra simplement pas comme un attribut de conversation dans l'Inbox.
Pour conserver les données dans un attribut de conversation : Utilisez une étape Handoff to workflow et définissez la valeur de l'attribut à l'intérieur du workflow à la place. Notez que la procédure ne reprendra pas après le transfert, planifiez donc votre flux pour qu'il soit terminé avant le transfert.

Connecteur de données configuré en LECTURE au lieu de MISE À JOUR

Problème : La procédure s'exécute mais ne collecte ni ne stocke les données du client, même si l'étape du connecteur de données semble s'exécuter.

Solution : Vérifiez le type d'action du connecteur de données dans l'étape concernée. READ vérifie uniquement la présence d'une valeur stockée existante — il ne sollicite pas le client pour une saisie ni ne sauvegarde de nouvelles données. UPDATE collecte les données du client et les enregistre dans l'attribut. Si votre procédure est censée recueillir des informations du client (par exemple une adresse e-mail, un numéro de commande ou un motif de contact), changez le type d'action en UPDATE.

Gestion avancée des échecs avec status_code

Le status_code renvoyé par un appel de connecteur de données est exposé comme un attribut de sortie. Vous pouvez le référencer dans une étape Condition pour bifurquer selon des codes de réponse HTTP spécifiques, vous donnant un contrôle précis sur la manière dont Fin gère différents scénarios d'échec plutôt que de vous fier à une simple branche réussite/échec.

Par exemple, vous pouvez diriger un 404 (ressource non trouvée) vers un message différent d'un 500 (erreur serveur), ou escalader vers un agent humain uniquement lorsqu'un code d'erreur spécifique est renvoyé.

Astuce : Voir Comment écrire des conditions de code pour les procédures Fin pour des exemples de code utilisant status_code dans une étape Condition.

Validation des corrections avec les Simulations

Avant de mettre votre procédure en production, utilisez les Simulations pour vérifier la correction :

Aperçu vs. Simulations — lequel dois-je utiliser ? Aperçu montre l'expérience complète côté client. Utiliser l'Aperçu pendant que votre procédure est en direct peut exposer les messages d'étape aux clients réels. Les Simulations exécutent la procédure en arrière-plan sans sortie visible pour le client — c'est la manière la plus sûre de valider la logique et le déclenchement avant la mise en production.

Accédez à l'éditeur de procédure et cliquez sur Test.
Exécutez une Simulation où l'IA joue le rôle du client dans le scénario d'échec.
Examinez le résultat réussite/échec et le jugement de l'IA pour confirmer que la logique est fiable.

FAQ

Le débogueur de conversation fonctionne-t-il pour les conversations Fin standard ?

Non, la timeline et le débogueur « Fin's thoughts » ne sont disponibles que lorsqu'une Procedure a été déclenchée. Si Fin a donné une réponse inattendue dans une conversation standard, ces outils ne seront pas présents — vérifiez plutôt les événements de conversation dans l'Inbox.

Combien de temps les journaux du connecteur de données sont-ils conservés ?

Les journaux de réponse du connecteur de données sont conservés par défaut pendant 7 jours. Si votre workspace a activé les journaux étendus, cela passe à 14 jours. Vous y accédez via Paramètres > Intégrations > Connecteurs de données > Journaux.

Puis-je utiliser les Simulations pour tester les réponses du connecteur de données ?

Oui — les Simulations exécutent la procédure complète incluant toutes les étapes du connecteur de données, ce qui en fait la manière la plus fiable de valider le comportement du connecteur avant la mise en production.

Pourquoi ma Procedure est-elle bloquée par un Workflow ?

Les Workflows s'exécutent avant que Fin n'évalue l'intention de la procédure. Si un Workflow est actif pour le même déclencheur de conversation, il peut diriger la conversation avant que Fin ait la chance d'associer une procédure. Pour corriger cela : vérifiez vos workflows actifs pour les déclencheurs qui se chevauchent et assurez-vous que le bloc Let Fin Handle est correctement configuré dans le chemin du workflow où vous souhaitez que les procédures soient disponibles.

Pourquoi ma Procedure a-t-elle été transférée à un humain de manière inattendue ?

Il y a deux façons pour une Procedure de transférer à un humain :

Comportement d'escalade par défaut — Fin escalade automatiquement selon sa logique intégrée : lorsqu'un client demande clairement à parler à un humain, lorsque Fin détecte une forte frustration ou colère, ou lorsque le client est bloqué dans une boucle répétitive. Cela se déclenche toujours quel que soit le paramétrage de votre Procedure.
Transfert configuré — Une étape Handoff to team que vous avez ajoutée à un point précis de la Procedure, ou des instructions spécifiques à la Procedure que vous avez écrites pour indiquer à Fin de transférer dans un scénario particulier.

Si le transfert était inattendu, utilisez « Fin's thoughts » dans le débogueur de conversation pour voir quel type s'est déclenché et à quelle étape.

Pourquoi mon Escalation Guidance ne se déclenche-t-il pas dans une Procedure ?

L'Escalation Guidance ne s'applique pas par défaut dans une Procedure — vous devez l'activer explicitement dans le panneau Guidance de la Procedure :

Ouvrez votre Procedure, cliquez sur la roue des paramètres en haut à droite de l'éditeur Instructions et cliquez sur Guidance.
Sélectionnez les catégories de guidance au niveau du workspace que vous souhaitez appliquer, y compris Handover and escalation.
Fin combinera la guidance sélectionnée au niveau du workspace avec toute guidance personnalisée spécifique à la Procedure que vous avez écrite.

Note : Le comportement d'escalade par défaut de Fin (demande d'humain, frustration détectée, boucle répétitive) se déclenche toujours dans une Procedure quel que soit le paramétrage de Guidance. Le panneau Guidance contrôle uniquement votre Escalation Guidance et vos règles d'escalade au niveau du workspace.

Quelle est la différence entre Handoff to team et Handoff to workflow ?

Les deux étapes terminent la Procedure, mais elles dirigent la conversation différemment :

Handoff to team — Termine la Procedure et transfère la conversation à un coéquipier humain. La conversation suit alors le chemin d'escalade configuré dans votre workflow Deploy après l'étape Let Fin handle (bloc Let Fin handle).
Transfert vers workflow — Termine la Procédure et transfère la conversation à un Workflow réutilisable spécifique que vous avez déjà créé (par exemple, une enquête de satisfaction ou un flux de routage spécialisé). La Procédure ne reprendra pas après la fin du Workflow.

Un transfert de Procédure est-il facturé comme un Fin Outcome ?

Une Procédure Fin est facturée comme un Fin Outcome uniquement lorsque la conversation se termine de l'une des deux manières suivantes :

Résolution — le client confirme que Fin a résolu son problème, ou ne demande pas plus d'aide après la réponse de Fin.
Transfert de Procédure — Fin transfère à une équipe, un coéquipier ou un workflow via une étape de transfert configurée ou des instructions spécifiques à la procédure que vous avez mises en place.
Dans les deux cas, vous êtes facturé 0,99 $ — et ce, une seule fois par conversation, quel que soit le nombre d'étapes exécutées par Fin ou le nombre de questions posées par le client.

Note : Vous ne serez pas facturé si une Procédure ne se termine pas, sort sans atteindre l'un de ces résultats, si un client demande à parler à un humain à tout moment, ou si la conversation se termine via le comportement d'escalade par défaut de Fin ou les règles d'escalade au niveau de l'espace de travail.

Pour plus de détails, consultez Understanding Fin Outcomes.

Ma Procédure s'arrête en plein milieu de la conversation — cela pourrait-il être un problème de délai d'attente ?

Oui. Les Procédures s'exécutent dans un bloc Let Fin Handle de votre Workflow, et ce bloc a un délai d'inactivité par défaut. Si un client met plus de temps que ce délai pour répondre, le bloc peut se fermer avant la fin de la procédure. Pour corriger cela, ouvrez le bloc Let Fin Handle dans les paramètres de votre Workflow et augmentez le délai d'inactivité pour mieux correspondre à la durée prévue de la conversation.

Puis-je utiliser Guidance pour déclencher une Procédure ?

Non. Guidance contrôle la façon dont Fin répond et se comporte — il ne peut pas démarrer une procédure ni diriger une conversation vers une procédure. Les deux systèmes sont séparés : Guidance façonne le ton et les règles d'escalade de Fin ; les Procédures définissent les workflows étape par étape que Fin suit lorsqu'une intention spécifique est détectée.

Pour passer d'une procédure à une autre en cours de conversation, utilisez la commande @Switch dans la procédure source, ou activez Agentic Switch dans les paramètres de la procédure (voir « 4. Help Center content taking priority » dans cet article).

Si vous souhaitez que Fin décide intelligemment quand appeler un connecteur de données ou suivre un flux spécifique en fonction de ce que dit le client, intégrez cette logique dans une procédure plutôt que dans Guidance.

Ma condition de code ne fait pas de branchement — comment la déboguer ?

Les conditions de code échouent silencieusement en cas d'erreur de syntaxe ou lorsque le chemin de données que vous essayez d'accéder n'existe pas dans le contexte de la conversation. Fin ne signalera pas directement l'erreur — il suivra simplement la branche Else ou restera bloqué. Voici comment le diagnostiquer :

Ouvrez la conversation dans Inbox et activez Afficher les événements de conversation (voir « Accéder au débogueur de conversation » ci-dessus).
Dans Les pensées de Fin, vérifiez quelle valeur Fin a reçue en entrée de votre condition. Si la valeur est null ou undefined, le chemin de données dans votre code est incorrect.
Vérifiez ces modèles courants d'accès aux données : • Adresse e-mail : inputs["user"]["email"] — renvoie l'adresse e-mail du client si disponible, sinon None • Sortie du connecteur : utilisez le nom exact du champ dans le schéma de réponse de votre connecteur • Attribut de conversation : inputs["conversation"]["attribute_name"]
Testez votre bloc de code dans un interpréteur Python avant de l'ajouter à la procédure. Cela permet de détecter immédiatement les erreurs de syntaxe, sans avoir besoin d'exécuter une conversation en direct.
Si la condition s'évalue mais oriente vers la mauvaise branche, ajoutez une instruction print() dans votre bloc de code pour enregistrer la valeur réelle que Fin reçoit. La sortie apparaîtra dans les événements de conversation.

Note : Le type de client (user vs. lead) n'est actuellement pas disponible en tant qu'attribut de Procédure. Si vous devez faire un branchement selon le type de client, utilisez une condition Type dans votre Workflow avant l'étape Fin.

Dépannage des procédures Fin et des connecteurs de données