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 comme 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 grâce aux 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 en arrière 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, vérifiez d'abord 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 la présence 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).
Vérifiez la présence d'une directive ou règle d'escalade concurrente : Si le message du client correspond aussi à une directive ou règle d'escalade (Fin AI Agent > Train > Escalations), l'escalade prend le pas — Fin transfère à un humain au lieu de déclencher la procedure, même si les critères de déclenchement de la procedure sont aussi pertinents (ou plus). Passez en revue vos directives et règles d'escalade pour repérer les formulations qui se chevauchent avec le déclencheur de la procedure (par exemple, les deux ciblant le même code d'erreur ou phrase), et ajoutez des exemples positifs et négatifs à la directive d'escalade comme pour un déclencheur de procedure, afin d'éviter la concurrence sur le même message.

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 un 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.

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 analyse la conversation et toutes les descriptions des déclencheurs des procedures 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 choisir la meilleure
- Seule la procedure source (celle dont Fin sort) 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 l'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 l'étape où Fin s'est arrêté lorsque la procédure s'est terminée de manière inattendue.

Échec de sauvegarde dû à une incompatibilité de type d'attribut

Problème : La procédure échoue lors de la sauvegarde d'une réponse dans un attribut de conversation.

Solution : Vérifiez que le type d'attribut correspond à la valeur que la procédure tente de sauvegarder. Si la procédure sauvegarde une chaîne (par exemple, une réponse client collectée pendant la conversation), l'attribut cible doit être de type chaîne. Utiliser un attribut de type liste avec le même nom provoquera des échecs de sauvegarde. 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 :

Utilisateurs uniquement : Les Procedures ne se déclenchent que pour les Users sur mobile — elles ne s'exécutent pas pour les Leads ou Visitors, quel que soit le paramétrage 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 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 actif Let Fin Handle dans le workflow concerné 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 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, commencez ici.

Le connecteur fonctionne en test mais échoue dans une Procedure en direct

Problème : Le connecteur passe 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 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 de sécurité récent 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 un rafraîchissement a été tenté.
403 Interdit : Le jeton est valide mais sans 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 à ceci — n'utilisez pas 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 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 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 en 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 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 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 data connector 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, sans 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 l'étape entière comme non résoluble et escalade à un humain ou 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 quand les données ne sont pas disponibles (par exemple, un 404 quand 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 sur lequel agir.
Ajoutez une étape Condition après l'appel du connecteur : Utilisez la sortie status_code du connecteur pour diriger vers un message de secours ou un chemin d'escalade contrôlé lorsque le connecteur échoue. Voir « Gestion avancée des échecs avec status_code » dans cet article pour la configuration.

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

Problème : Le connecteur semble se déclencher — les logs montrent qu'il a fonctionné — mais renvoie une erreur 404 et les attributs 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 URL se résout à une valeur vide à l'exécution, rendant l'URL mal formé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 à un attribut valide — mais si l'identifiant ne correspond pas à un attribut réel, il se résout à vide à l'exécution et l'URL 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 toutes les pilules tapées manuellement et remplacez-les en sélectionnant l'attribut correct depuis l'Attribute Inserter.
Si votre URL nécessite l'ID contact Intercom, sélectionnez Contact ID (user.id) depuis le sélecteur — pas User ID (user_id). L'API Contacts attend l'ID contact généré par Intercom (user.id), pas l'ID utilisateur défini en externe (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 suivantes 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.

Ce que cela signifie en pratique :

Utilisez directement la sortie du connecteur dans les étapes suivantes : Les données renvoyées par votre connecteur 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 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 dans le 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.

Data connector réglé sur READ au lieu de UPDATE

Problème : La procédure s'exécute mais ne collecte ni ne stocke les données client, même si l'étape de 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 la présence d'une valeur stockée — il ne sollicite pas le 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 doit recueillir des informations du client (ex. adresse e-mail, numéro de commande, raison du contact), changez le type d'action en UPDATE.

Gestion avancée des échecs avec status_code

Le status_code renvoyé par un appel de data connector est exposé comme attribut de sortie. Vous pouvez le référencer dans une étape Condition pour bifurquer selon des codes HTTP spécifiques, vous donnant un contrôle précis sur la gestion par Fin des 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 à 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 Procedure en ligne, utilisez Simulations pour vérifier la correction :

Aperçu vs. Simulations — lequel utiliser ? Aperçu montre l'expérience complète côté client. Utiliser Aperçu 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.

Allez dans 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 la fiabilité de la logique.

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 le Inbox.

Combien de temps les logs des Data connectors sont-ils conservés ?

Les logs de réponse des Data connectors sont conservés par défaut jusqu'à 14 jours. Si votre workspace a des exigences de sécurité des données plus strictes, Intercom peut réduire cela à 7 jours sur demande — contactez notre équipe 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 connectors ?

Oui — les Simulations exécutent la procédure complète incluant toutes les étapes de Data connector, 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 orienter 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, 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.

Que se passe-t-il lorsque la même demande client correspond à la fois à une Procedure et à une Escalation Guideline ?

L'escalade a la priorité. Si le message d'un client correspond à la fois aux critères de déclenchement d'une Procedure et à une Escalation Guideline (ou une Escalation Rule), Fin transfère à un humain au lieu d'exécuter la Procedure — même si le déclencheur de la Procedure correspond plus précisément au message. C'est une règle générale sur la résolution des intentions concurrentes par Fin, non configurable par Procedure.

Par exemple, une Procedure conçue pour gérer les demandes de création de cas "API Error" ne se déclenchera pas pour un client décrivant une erreur API si une Escalation Guideline est aussi écrite pour détecter le terme "API Error" — l'Escalation Guideline l'emporte, et la Procedure ne s'exécute jamais.

Comment empêcher une Escalation Guideline de supplanter involontairement ma Procedure ?

Réduisez la portée de l'Escalation Guideline pour qu'elle ne chevauche plus les critères de déclenchement de la Procedure :

Ouvrez Fin AI Agent > Train > Escalations et examinez vos Escalation Guidance et Escalation Rules pour repérer des formulations pouvant correspondre aux mêmes messages que le déclencheur de la Procedure.
Ajoutez des exemples positifs spécifiques (devrait escalader) et négatifs (ne devrait pas escalader — devrait exécuter la Procedure à la place) à l'Escalation Guideline, comme vous affineriez la section "Quand utiliser cette procédure" d'une Procedure.
Si les deux ciblent la même expression précise (par exemple, un code d'erreur spécifique), reformulez l'Escalation Guideline pour exclure les messages de type création de cas, ou rendez les critères de déclenchement de la Procedure plus spécifiques pour éviter le chevauchement.

Utilisez Fin's thoughts dans le débogueur de conversation pour confirmer si une escalade ou la Procedure s'est déclenchée pour un message donné (voir "Accéder au débogueur de conversation" ci-dessus).

Pourquoi mon Escalation Guidance ne se déclenche-t-elle 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 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, quelle que soit la configuration de Guidance. Le panneau Guidance contrôle uniquement votre Escalation Guidance et Escalation Rules 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 redirigent 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 Deploy workflow après l'étape Let Fin handle .
Handoff to workflow — Termine la Procedure et transmet la conversation à un Workflow réutilisable spécifique que vous avez déjà créé (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 de transfert 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 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 Procedure s'arrête en plein milieu de la conversation — est-ce un problème de délai d'attente ?

Oui. Les Procedures 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 à répondre, le bloc peut se fermer avant la fin de la Procedure. 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 Procedure ?

Non. Guidance contrôle la réponse et le comportement de Fin — elle ne peut pas démarrer une Procedure ni diriger une conversation vers celle-ci. Les deux systèmes sont distincts : Guidance façonne le ton et les règles d'escalade de Fin ; les Procedures définissent les workflows étape par étape que Fin suit lorsqu'une intention spécifique est détectée.

Pour passer d'une Procedure à une autre en cours de conversation, utilisez la commande @Switch dans la Procedure source, ou activez Agentic Switch dans les paramètres de la Procedure (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 selon ce que dit le client, intégrez cette logique dans une Procedure plutôt que dans Guidance.

Ma condition de code ne bifurque pas — 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 tentez d'accéder n'existe pas dans le contexte de la conversation. Fin ne signale pas directement l'erreur — il suit simplement la branche Else ou se bloque. Voici comment 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 : • 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 Procedure. 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 reçue par Fin. La sortie apparaîtra dans les événements de conversation.

Note : Le type de client (user vs. lead) n'est pas actuellement disponible comme attribut de Procedure. Si vous devez bifurquer 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