Lorsqu'une Procedure Fin ne résout pas une conversation comme prévu, vous pouvez utiliser les outils d'inspection intégrés pour examiner 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.

Lorsque Fin considère une Procedure pour le message d'un client mais décide de ne pas l'exécuter, un événement « [Nom de la Procedure] considéré par Fin et refusé » apparaît dans la chronologie de la conversation avec les événements de déclenchement habituels. Développez-le pour lire le raisonnement de Fin expliquant pourquoi il a refusé de lancer la Procedure.

Note : 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 des Procedures

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 activée : Les procedures désactivées ne se déclenchent pas pour les clients. Confirmez que la pastille Disponibilité indique Enabled for service 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 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. Vérifiez vos workflows pour vous assurer qu'aucun ne capte la conversation avant que Fin puisse déclencher la procedure.
Revoyez 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) 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). Vérifiez vos directives et règles d'escalade pour des 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 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 lance une Procedure qui ne correspond pas à la demande du client.

Solution : Revoyez 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.

Utiliser Fin Operator pour déboguer le déclenchement des Procedures

Le débogage de conversation de Fin Operator peut vous dire exactement ce qui s'est passé avec une Procedure dans une conversation spécifique. Demandez à Operator au sujet d'une conversation et il indique si chaque Procedure a été triggered, declined, already running, never considered ou beaten by a better-matching Procedure ou Escalation Guideline — et suggère une solution pour chaque cas.

Utiliser Fin Operator pour revoir les déclencheurs de Procedures

Lorsque vous demandez à Fin Operator de revoir ou rédiger un déclencheur de Procedure (la description « When to use this procedure » et ses exemples), il signale les deux erreurs qui empêchent le plus souvent une Procedure de se déclencher : des conditions formulées en termes qu'un client ne pourrait pas exprimer lui-même (par exemple, un statut de compte interne que le client ne saurait pas mentionner), et une description de déclencheur trop large associée à des clauses de déclenchement étroites qui contredisent les exemples de la description.

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

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

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 répond par défaut avec 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 basculement de Procedure
Agentic Switch est un paramètre par procédure qui permet à Fin de passer automatiquement de la procédure en cours à une autre procédure active lorsqu'il détecte que l'intention du client a changé en cours de conversation — plutôt que de rester bloqué sur la procédure initiale ou de revenir à une réponse du Help Center. Lorsqu'il est activé :
- Fin examine la conversation et toutes les descriptions des déclencheurs des procédures actives pour décider quand un changement servirait mieux le client
- Si plusieurs procédures peuvent s'appliquer, Fin peut poser une question de clarification pour sélectionner la meilleure
- Seule la procédure source (celle dont Fin effectue la transition depuis) 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 contradictoire du Help Center
Si l'activation d'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 lorsqu'un 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 contradictoire :
- Trouvez la conversation dans votre Inbox et ouvrez Fin's thoughts.
- Cherchez les références aux articles du Help Center dans le chemin de réponse.
- Supprimez l'article contradictoire ou mettez-le à jour pour diriger les clients vers le support, afin que Fin redirige 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 écrit « 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 contradictoire 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 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 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 l'étape où Fin s'est arrêté lorsque la procédure s'est terminée de manière inattendue.

Incompatibilité de type d'attribut provoque 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 tente 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. Utiliser un attribut de type liste avec 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 : Lorsqu'une Procedure aurait été envisagée mais refusée pour une question donnée, le test Batch affiche « [Nom de la procédure] aurait été envisagée mais refusée dans une conversation client réelle » à côté de la réponse — cliquez sur Afficher le raisonnement pour voir pourquoi Fin ne l'a pas déclenchée.

Utilisateurs uniquement : Les Procedures ne se déclenchent que pour les Users sur mobile — elles ne s'exécutent pas pour les Leads ou les Visitors, 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 activée : Les procédures désactivées ne sont pas proposées 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 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 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 d'une Procedure, commencez ici.

Le connecteur fonctionne en test mais échoue dans une Procedure 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 : Réenregistrez et republiez après rotation d'une clé. Vérifiez la présence de caractères cachés comme des espaces en fin de valeur 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 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 n'importe quel événement d'erreur dans l'Inbox pour obtenir 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 se rabattre sur 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 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 mode 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 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 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, 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 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 diriger vers un message adapté ou un chemin d'escalade contrôlé lorsque le connecteur échoue. Voir « 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 fonctionné — mais renvoie une erreur 404 et les attributs du 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 à 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 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 toutes les pilules tapées manuellement et remplacez-les en sélectionnant le bon attribut depuis le sélecteur 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 connecteur de données s'exécute et renvoie les données attendues, mais la valeur n'apparaît pas comme attribut de conversation — et les étapes suivantes dans 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 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 conserver 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 se termine avant le transfert.

Connecteur de données configuré en mode READ au lieu de UPDATE

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 ne fait que vérifier 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 doit 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 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 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 étape Condition.

Validation des corrections avec les Simulations

Avant de mettre votre procédure 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 vrais clients. Simulations exécutent la procédure en arrière-plan sans sortie côté 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 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 procédure 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 Inbox.

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

Les logs de réponse du connecteur de données sont conservés par défaut pendant 14 jours. Si votre espace de travail 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 du connecteur de données ?

Oui — Les simulations exécutent la procédure complète, y compris toutes les étapes du connecteur de données, ce qui en fait le moyen le plus fiable de valider le comportement du connecteur avant la mise en production.

Pourquoi ma procédure 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 résoudre ce problème : examinez vos workflows actifs pour détecter 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 procédure a-t-elle été transférée à un humain de manière inattendue ?

Il y a deux façons pour une procédure 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 procédure.
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 é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 message client correspond à la fois à une procédure et à une directive d'escalade ?

L'escalade prend la priorité. Si le message d'un client correspond à la fois aux critères de déclenchement d'une procédure et à une directive d'escalade (ou une règle d'escalade), Fin transfère à un humain au lieu d'exécuter la procédure — même si le déclencheur de la procédure est une correspondance plus proche ou plus spécifique au message. C'est une règle générale sur la façon dont Fin résout les intentions concurrentes, et ce n'est pas configurable par procédure.

Par exemple, une procédure 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 directive d'escalade est également écrite pour détecter le langage "API Error" — la directive d'escalade l'emporte, et la procédure ne s'exécute jamais.

Comment empêcher une directive d'escalade de supplanter involontairement ma procédure ?

Réduisez la directive d'escalade pour qu'elle ne chevauche plus les critères de déclenchement de la procédure :

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

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

Pourquoi ma directive d'escalade ne se déclenche-t-elle pas à l'intérieur d'une procédure ?

La directive d'escalade 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 guidance spécifique à la procédure que vous avez écrite.

Note : 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, quelle que soit la configuration de Guidance. Le panneau Guidance contrôle uniquement votre directive d'escalade 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 procédure, mais elles orientent la conversation différemment :

Handoff to team — Termine la procédure 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 procédure et transmet la conversation à un Workflow réutilisable spécifique que vous avez déjà construit (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 façons 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 procédure 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 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 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 orienter 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 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 Guidance.

Ma condition de code ne branche 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 ne signale pas directement l'erreur — il suit simplement la branche Else ou se bloque. 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 : • 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 pas actuellement disponible comme attribut de procédure. Si vous devez brancher selon le type de client, utilisez une condition Type dans votre Workflow avant l'étape Fin.