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 l'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.

Important : Cet article couvre uniquement le dépannage des Procedures Fin. La chronologie « Fin's thoughts » et le débogueur 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 Simple Deploy est actif : Si Simple Deploy est désactivé, Fin ne lancera aucune procedure. Allez dans Fin AI Agent > Deploy > Chat et confirmez que Fin est activé.
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 les workflows à plus haute priorité : 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 ne capte la conversation avant que Fin ne 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).

1. 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 les 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.

2. É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 : « Ne procéder que si [donnée] est fournie. »

3. É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.

4. Contenu du Help Center prioritaire

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 examine la conversation et toutes les descriptions de déclenchement des procedures actives pour décider quand un changement servirait mieux 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 du Help Center en conflit
Si l'activation de Agentic Switch ne résout pas le problème, la solution la plus fiable est de supprimer ou de 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 en conflit :
- 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 en conflit 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 dispose également d'un article du Help Center intitulé « Comment obtenir un remboursement ? » qui explique la politique de remboursement. Lorsqu'un client envoie le message « 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.

5. 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 se termine dans 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 dans la procédure 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 de tout le flux. 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.

Dépannage des connecteurs de données

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

Le connecteur fonctionne en test mais échoue dans une 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'une des raisons suivantes :

Identifiants : Enregistrez à nouveau et republiez après avoir fait pivoter 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 connaître 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 n'a pas la permission. Vérifiez les permissions sur votre système externe.
Utilisateurs OAuth : Utilisez le bouton Reauthenticate 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 n'importe quel événement d'erreur dans le Inbox pour tous les détails.

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 — ne pas utiliser le contenu de 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 mode Draft n'apparaîtra pas dans l'éditeur de procédure.
Vérifiez qu'au moins une action est configurée : Un connecteur sans action définie 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 ⌘ + Shift + R (Mac) ou Ctrl + Shift + R (Windows).
Contactez le support Intercom : Si rien de ce qui précède ne résout le problème, contactez le support Intercom avec le nom du connecteur et les détails de votre espace de travail. Certaines configurations d'espace de travail nécessitent une étape manuelle pour rendre un connecteur disponible dans l'éditeur de procédure.

Le connecteur échoue en mode d'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 d'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 que Fin peut utiliser. 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 gracieux ou un chemin d'escalade contrôlé lorsque le connecteur échoue. Consultez « 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 exécuté 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 en tant que 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 demande pas d'entrée au client 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 Condition step pour créer des branches 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 seule 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 : Consultez Comment écrire des conditions de code pour les procédures Fin pour des exemples de code utilisant status_code dans une Condition step.

Validation des corrections avec Simulations

Avant de mettre votre Procedure en ligne, utilisez Simulations pour vérifier la correction :

Aperçu vs. Simulations — lequel dois-je utiliser ? Preview montre l'expérience complète côté client. Utiliser Preview pendant que votre procédure est en ligne peut exposer les messages d'étape aux clients réels. 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 ligne.

Accédez à l'éditeur de Procedure 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.

FAQs

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 espace de travail a activé les journaux étendus, cela passe à 14 jours. Vous pouvez y accéder sous 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 Procedure complète incluant toutes les étapes du connecteur de données, ce qui en fait la méthode la plus fiable pour valider le comportement du connecteur avant la mise en ligne.

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 résoudre ce problème : 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 dont une Procedure peut être transférée à 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, quelle que soit la configuration 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 de l'espace de travail que vous souhaitez appliquer, y compris Handover and escalation.
Fin combinera la guidance sélectionnée au niveau de l'espace de travail avec toute guidance personnalisée spécifique à la Procedure que vous avez écrite.

Note : Le comportement d'escalade par défaut de Fin (demande du client pour un humain, frustration détectée, boucle répétitive) se déclenche toujours dans une Procedure quelle que soit la configuration de la Guidance. Le panneau Guidance contrôle uniquement votre Escalation Guidance et vos règles d'escalade au niveau de l'espace de travail.

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 ensuite le chemin d'escalade configuré dans votre workflow Deploy après l'étape Let Fin handle (bloc Let Fin handle).
Handoff to workflow — Termine la Procedure et transmet la conversation à un Workflow réutilisable spécifique que vous avez déjà construit (par exemple, un sondage de satisfaction ou un flux de routage spécialisé). La Procedure ne reprendra pas après la fin du Workflow.

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

Une Procedure 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.
Procedure Handoff — Fin transfère à une équipe, un coéquipier ou un workflow via une étape Handoff configurée ou une guidance spécifique à la Procedure que vous avez mise 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 Procedure ne parvient pas à se terminer, se termine sans atteindre l'un de ces résultats, un client demande à parler à un humain à tout moment, ou si la conversation se termine par 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 Comprendre les 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 que la procédure ne soit terminée. Pour résoudre ce problème, 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 celle-ci. 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 reconnue.

Pour passer d'une procédure à une autre en cours de conversation, utilisez la commande @Switch à l'intérieur de 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 lorsqu'il y a une 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 se bloquera. 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 Fin's thoughts, 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 : • Type de client : inputs["user"]["role"] — renvoie "user" ou "lead" • 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 dirige 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.

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