When a Fin Procedure doesn't resolve a conversation as expected, you can use built-in inspection tools to investigate Fin's decision-making logic. Use this guide to identify where a flow went off track and how to refine your instructions.

What you'll learn

Debug Procedure failures using Fin's thoughts and conversation events.
Diagnose common issues like wrong Procedure triggers, out-of-sequence steps, and branching failures.
Troubleshoot Data connector errors, including auth failures and missing data.
Validate fixes before going live using Simulations.

Accessing the conversation debugger

To understand why Fin took a specific action, you must first enable technical visibility within the conversation thread.

Open the specific conversation in the Inbox.
Click the three dots icon at the top right of the conversation header.
Select Show conversation events.

Tip: Use the keyboard shortcut ⌘ + E (Mac) or Ctrl + Shift + E (Windows) to toggle this view.

Inspecting "Fin's thoughts"

Once conversation events are visible, you can see the reasoning behind every step Fin took during a Procedure. To trace Fin’s decision-making process, locate the Fin's thoughts events in the conversation timeline. These events summarize Fin’s reasoning before it sends a message or performs an action.

For more granular detail, click the Fin Thoughts and click See more. This reveals:

The current step: The specific Procedure step Fin was executing.
Intent interpretation: How Fin understood the customer’s request.
Logic path: Why Fin decided to skip a step, revisit a previous one, or move to a specific branch.

Note: This article covers troubleshooting for Fin Procedures only. The "Fin's thoughts" timeline and debugger are only available when a Procedure was triggered. If Fin gave an unexpected answer in a standard conversation, these tools will not be present in the conversation events.

Common Procedure failures

If Fin is not working as expected, it's usually due to how instructions are phrased or how logic is branched.

Procedure isn't triggering at all

Before reviewing the numbered failures below, run through these basics first:

Check the procedure is published: Draft procedures won't trigger for customers. Confirm the status is set to Published in the editor.
Check Fin is deployed: If Fin is not enabled through the Simply Deploy section, or the "Let Fin handle" step isn't live in your workflow, Fin won't run any procedures.
Check audience targeting: A common miss is targeting Users when the customer is a Lead (or vice versa). In the "When to use this procedure" section, click the audience button and verify the correct audience type and channel are selected.
Check for higher-priority workflows: Active workflows run before Fin evaluates procedure intent. Review your workflows to make sure none are intercepting the conversation before Fin can trigger the procedure.
Review trigger criteria scope: Criteria that are too narrow prevent Fin from matching valid customer messages. Check the "When to use this procedure" description and add positive examples (messages that should trigger it) and negative examples (messages that should not).

Note: While Slack may appear as a selectable channel, procedure triggers are not currently supported for Slack conversations.

Fin triggers the wrong Procedure

Problem: Fin starts a Procedure that doesn't match the customer's request.

Solution: Review your "When to use this procedure" instructions. Use positive and negative examples to help Fin distinguish between similar intents. If a new procedure shares similar trigger criteria with an existing published procedure, the published one may take priority. To isolate the new procedure during testing: temporarily exclude your test user from the existing procedure by adjusting its audience criteria, or narrow the new procedure's trigger to a unique phrase only you would send. Use Fin's thoughts > Expand thoughts in the conversation debugger to confirm which procedure actually fired.

Steps out of sequence

Problem: Fin skips a prerequisite step or moves to a resolution prematurely.

Solution: Check for ambiguity in your natural language instructions. If a step relies on a specific piece of data, ensure the instruction explicitly states: "Only proceed if [data] is provided."

Branching logic failures

Problem: Fin follows the "Else" path when it should have followed the "If" path.

Solution: Inspect the Conditions. If using natural language for branching, try rephrasing for clarity. For complex logic (e.g., date calculations), consider using Python code blocks to enforce strict deterministic rules.

Help Center content taking priority

Problem: Fin answers from the Help Center instead of running the procedure, even when the customer's intent clearly matches the procedure's trigger criteria.

Solution: If Fin is defaulting to a Help Center answer instead of running the procedure, there are two approaches depending on your setup. Try Option 1 first — if the issue persists, move to Option 2.

Option 1: Enable Procedure Switching
Agentic Switch is a per-procedure setting that allows Fin to automatically switch from the current procedure to another live procedure when it detects that a customer's intent has changed mid-conversation — rather than staying locked to the original procedure or falling back to a Help Center answer. When enabled:
- Fin reviews the conversation and all live procedure trigger descriptions to decide when switching would better serve the customer
- If multiple procedures could apply, Fin may ask a clarifying question to select the best one
- Only the source procedure (the one Fin is switching out of) needs the setting on
- The @Switch command can still be used to switch manually
To enable it: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Option 2 : Supprimer ou mettre à jour le contenu Help Center conflictuel
Si l’activation d’Agentic Switch ne résout pas le problème, la solution la plus fiable est de supprimer ou de mettre à jour le contenu Help Center que Fin utilise au lieu d’exécuter la procédure. Fin utilise par défaut les réponses du Help Center lorsqu’un contenu pertinent existe pour un sujet : si un article couvre la même intention que votre procédure, Fin peut répondre depuis cet article directement 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 des références aux articles du Help Center dans le chemin de réponse.
- Soit supprimez l’article en conflit, soit mettez-le à jour pour demander aux clients de contacter le support, afin que Fin redirige vers la procédure.

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 Help Center intitulé « How do I get a refund? » qui explique la politique de remboursement. Lorsqu’un client écrit « I'd like a refund », 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 indiquer quelque chose comme « To request a refund, start a chat and our assistant will walk you through it » supprime la réponse conflictuelle et oriente les clients vers la procédure.

La procédure se bloque ou se termine avant d’être complétée

Problème : La procédure atteint une certaine étape et s’arrête, ou se termine dans un état final sans accomplir toutes les étapes attendues.

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

Déclarations redondantes « Immediately proceed » : Si plusieurs étapes incluent des instructions comme « immediately proceed to the next step », Fin peut réévaluer des étapes déjà complétées au lieu d’avancer. Supprimez ces formulations et laissez Fin progresser naturellement dans la procédure en fonction du flux.
Instructions de saut d’étape : Des phrases comme « go back to step 2 » ou « repeat the verification step » peuvent amener Fin à boucler entre des étapes plutôt qu’à avancer. Conceptionnez chaque étape pour qu’il y ait une voie claire vers l’avant.
Logique de condition qui se chevauche : Si deux conditions peuvent être vraies en même temps, Fin peut bifurquer de manière imprévisible ou se bloquer. Assurez-vous que vos conditions sont mutuellement exclusives : une seule branche doit être vraie à tout moment.
Les sous-procédures se terminent sans continuer : Si une sous-procédure se termine mais que la procédure principale n’a pas d’instruction claire pour 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 : « Once the sub-procedure is complete, continue to [next step name]. »

Utilisez Fin's thoughts > See more dans le débogueur de conversation pour identifier précisément sur quelle étape Fin se trouvait lorsque la procédure s’est terminée de manière inattendue.

Incompatibilité de type d’attribut provoquant des échecs d’enregistrement

Problème : La procédure échoue lors de l’enregistrement d’une réponse dans un attribut de conversation.

Solution : Vérifiez que le type d’attribut correspond à la valeur que la procédure essaie d’enregistrer. Si la procédure enregistre une chaîne (par exemple, une réponse client collectée pendant la conversation), l’attribut cible doit être de type chaîne. L’utilisation d’un attribut de type liste portant le même nom provoquera des échecs d’enregistrement. Pour corriger cela, mettez à jour la procédure pour référencer l’attribut correct, ou allez dans Settings > Data > Conversations pour changer le type d’attribut.

Problèmes mobiles (iOS) avec les Procedures

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

Users only : Les Procedures ne se déclenchent sur mobile que pour les Users — elles ne s’exécuteront pas pour Leads ou Visitors, quel que soit le paramétrage de l’audience dans la procédure.
iOS channel must be targeted : Dans la section "When to use this procedure", iOS doit être sélectionné comme canal. La procédure ne se déclenchera pas sur mobile si seul Web est coché.
Procedure must be Published : Les procédures en brouillon ne sont pas servies aux clients mobiles.
Check Fin is deployed for iOS : Les Procedures 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 Let Fin Handle actif dans le workflow pertinent ciblant iOS.
Higher-priority workflows : 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. Passez en revue vos workflows actifs pour les chevauchements sur le canal iOS.

Dépannage des connecteurs de données dans les Procedures

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

Le connecteur fonctionne en test mais échoue en exécution réelle

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

Solution : Ceci est généralement causé par l’un des éléments suivants :

Identifiants : Ré-enregistrez et republiez après avoir fait pivoter une clé. Vérifiez la présence de caractères cachés comme des espaces finaux dans les valeurs de jeton.
Permissions : Un changement de sécurité récent sur votre système externe a pu supprimer l’accès.
Liste d’adresses IP autorisées : Confirmez que les IP sortantes d’Intercom sont incluses. Contactez votre responsable de compte pour connaître les plages actuelles.

Important : Si votre connecteur cesse de fonctionner sans modification de votre côté, vérifiez si votre fournisseur d’API externe (par ex. Shopify, Stripe) a mis à jour ou déprécié un endpoint.

Erreurs d’autorisation 401 et 403

401 Unauthorized : 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 Forbidden : Le jeton est valide mais manque d’autorisation. Passez en revue les autorisations sur votre système externe.
OAuth users : 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 tout événement d’erreur dans l’Inbox pour obtenir 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 : « Use @connector_name to answer this—do not use knowledge base content. »
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 calls one connector per turn: 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 chaîner plusieurs appels de connecteur dans une seule instruction d’étape.

Important : Fin ne peut traiter qu’un appel de connecteur par tour, donc si votre serveur MCP renvoie deux réponses séparées 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 data connector 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 réglé sur Live : Allez dans Settings > Integrations > Data connectors et vérifiez le statut du connecteur. Un connecteur en Draft 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 Live.
Vérifiez les permissions de votre rôle : Certains rôles peuvent voir les connecteurs dans Settings mais ne peuvent pas y accéder depuis 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 rechargement complet pour refléter les connecteurs récemment publiés. Utilisez ⌘ + Shift + R (Mac) ou Ctrl + Shift + R (Windows).
Contactez Fin Support : Si rien de ce qui précède ne résout le problème, contactez Fin Support en indiquant le nom du connecteur et les informations 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 data connector est configuré pour s'exécuter automatiquement — sans solliciter le client — mais il échoue silencieusement pendant 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 auto-exécution, Fin ne peut pas ignorer une étape de connecteur échouée et poursuivre la procédure. Si le connecteur renvoie une erreur, Fin considère l'ensemble de l'étape comme irrésoluble et escalade vers un humain ou revient à son comportement par défaut.

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

Modifiez votre API externe pour renvoyer 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 est introuvable), configurez votre API pour renvoyer un résultat vide ou par défaut sur lequel Fin peut agir. C'est la correction la plus fiable car Fin reçoit toujours quelque chose avec lequel travailler.
Ajoutez une étape Condition après l'appel du connecteur : Utilisez la sortie status_code du connecteur pour bifurquer vers un message élégant ou un chemin d'escalade contrôlé lorsque le connecteur échoue. Consultez « Advanced failure handling with status_code » dans cet article pour savoir comment configurer cela.

Le connecteur renvoie 404 ou les attributs du contact ne sont pas écrits malgré une exécution apparente

Problème : Le connecteur semble se déclencher — les logs montrent qu'il a été exécuté — mais renvoie une erreur 404 et les attributs de contact ne sont pas écrits, même si tous les connecteurs semblent correctement configurés.

Solution : Cela est presque toujours causé par une pilule d'attribut invalide dans l'URL de la requête. Un des paramètres de l'URL se résout en une valeur vide à l'exécution, rendant l'URL malformée.

La cause la plus fréquente : un attribut a été tapé manuellement comme {{Attribute Name}} au lieu d'être sélectionné depuis l'Attribute Inserter. L'éditeur convertit tout texte {{...}} en une pilule qui ressemble identique à un attribut valide — mais si l'identifiant ne correspond pas à un attribut réel, il se résout en vide à l'exécution et l'URL de la requête devient invalide.

Pour corriger cela :

Ouvrez le connecteur et inspectez l'URL de la requête et le corps pour toute pilule d'attribut.
Supprimez toute pilule tapée manuellement et remplacez-la en sélectionnant le bon attribut depuis le sélecteur Attribute Inserter.
Si votre URL nécessite l'Intercom contact ID, sélectionnez Contact ID (user.id) depuis le sélecteur — pas User ID (user_id). L'API Contacts attend l'ID de contact généré par Intercom (user.id), pas l'ID utilisateur défini à l'extérieur (user_id).

La sortie du connecteur ne remplit pas les attributs de conversation

Problème : Une étape de data connector s'exécute et renvoie les données attendues, mais la valeur n'apparaît pas comme attribut de conversation — et les étapes ultérieures 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é à l'intérieur d'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 ultérieures : Les données retournées par votre connecteur sont disponibles en tant que sortie d'étape dans la procédure. Référencez-les 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 attribut de conversation dans l'Inbox.
Pour persister 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 la passation, donc planifiez votre flux pour terminer avant la passation.

Connecteur de données réglé sur READ au lieu de UPDATE

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

Solution : Vérifiez le type d'action du data connector dans l'étape concernée. READ vérifie uniquement une valeur existante stockée — il ne sollicitera pas le client pour une saisie ni n'enregistrera de nouvelles données. UPDATE collecte la saisie du client et la sauvegarde dans l'attribut. Si votre procédure doit recueillir des informations auprès du client (par exemple une adresse e-mail, un numéro de commande ou une raison de contact), passez le type d'action à UPDATE.

Gestion avancée des erreurs avec status_code

Le status_code renvoyé par un appel de data connector est exposé en tant qu'attribut de sortie. Vous pouvez le référencer dans une Condition step pour bifurquer selon des codes de réponse HTTP spécifiques, vous donnant un contrôle précis sur la façon dont Fin gère différents scénarios d'échec plutôt que de compter sur une simple branche pass/fail.

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

Astuces : Consultez How to write code conditions for Fin Procedures 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 utiliser ? Preview montre l'expérience complète destinée au client. Utiliser Preview alors que votre procédure est en ligne peut exposer les messages d'étape à de vrais clients. Simulations exécutent la procédure en arrière-plan sans sortie visible pour le client — elles sont le moyen le plus sûr pour valider la logique et déclencher le matching 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éfaillant.
Examinez le résultat pass/é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 « 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 — vérifiez les événements de conversation dans l'Inbox à la place.

Combien de temps les logs de Data connector sont-ils stockés ?

Les logs de réponse des data connector sont conservés pendant 14 days par défaut. Si votre workspace a des exigences de sécurité des données plus strictes, Intercom peut réduire cela à 7 days sur demande — contactez notre Support pour l'activer. Accédez à vos logs sous Settings > Integrations > Data connectors > Logs.

Puis-je utiliser les Simulations pour tester les réponses des Data connector ?

Oui — les Simulations exécutent la procédure complète y compris toutes les étapes de Data connector, ce qui en fait le moyen le plus fiable pour valider le comportement du connecteur avant la mise en ligne.

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

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 possibilité de faire correspondre une procedure. Pour corriger cela : vérifiez vos workflows actifs pour des 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 procedures soient disponibles.

Pourquoi ma Procedure a-t-elle passé la main à un humain de manière inattendue ?

Il y a deux façons dont une Procedure peut passer la main à un humain :

Comportement d'escalade par défaut — Fin escalade automatiquement selon sa logique interne : 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 Procédure, ou des instructions spécifiques à la Procédure que vous avez rédigées et qui indiquent à 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-elle pas à l'intérieur d'une Procédure ?

Escalation Guidance ne s'applique pas par défaut à l'intérieur d'une Procédure — vous devez l'activer explicitement dans le panneau Guidance de la Procédure :

Ouvrez votre Procédure, 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 instruction personnalisée spécifique à la procédure que vous avez rédigée.

Remarque : le comportement d'escalade par défaut de Fin (le client demande un humain, frustration détectée, boucle répétitive) se déclenche toujours à l'intérieur d'une Procédure quelles que soient les paramètres de 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 mettent fin à la Procédure, mais elles routent la conversation différemment :

Handoff to team — Met fin à la Procédure et remet la conversation à un coéquipier humain. La conversation suit ensuite le chemin d'escalade configuré dans votre Deploy workflow après l'étape Let Fin handle (bloc Let Fin handle).
Handoff to workflow — Met fin à la Procédure 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 vers un spécialiste). 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 n'est facturée comme Fin Outcome que lorsque la conversation se termine de l'une des deux façons :

Résolution — le client confirme que Fin a résolu son problème, ou ne demande pas d'aide supplémentaire 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 des instructions spécifiques à la procédure que vous avez définies.
Dans les deux cas, vous êtes facturé 0,99 $ — et seulement une 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.

Remarque : Vous ne serez pas facturé si une Procédure n'arrive pas à son terme, se termine sans atteindre l'un de ces résultats, si un client demande à tout moment à parler à un humain, ou si la conversation se termine en raison du comportement d'escalade par défaut de Fin ou des règles d'escalade au niveau de l'espace de travail.

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

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

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 cela à 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 de conversation attendue.

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

Non. Guidance contrôle la façon dont Fin répond et se comporte — elle 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 flux étape par étape que Fin suit lorsqu'une intention spécifique est détectée.

Pour passer d'une procédure à une autre en milieu 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 voulez 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 la guidance.

Ma condition de code ne bifurque pas — 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 n'affichera pas l'erreur directement — il suivra simplement la branche Else ou s'arrêtera. Voici comment le diagnostiquer :

Ouvrez la conversation dans Inbox et activez Show conversation events (voir « Accéder au débogueur de conversation » ci-dessus).
Dans Fin's thoughts, vérifiez quelle valeur Fin a reçue comme entrée pour 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 à exécuter une conversation en direct.
Si la condition s'évalue mais va vers la mauvaise branche, ajoutez une instruction print() dans votre bloc de code pour consigner la valeur réelle que Fin reçoit. La sortie apparaîtra dans les événements de conversation.

Remarque : Le type de client (user vs. lead) n'est pas actuellement disponible en tant qu'attribut de Procédure. Si vous devez bifurquer en fonction du type de client, utilisez une condition Type dans votre Workflow avant l'étape Fin à la place.

Troubleshooting Fin Procedures and Data connectors