Cuando un Fin Procedure no resuelve una conversación como se esperaba, puedes usar herramientas de inspección integradas para investigar la lógica de toma de decisiones de Fin. Usa esta guía para identificar dónde se desvió un flujo y cómo refinar tus instrucciones.

Lo que aprenderás

Depura fallos de Procedure usando los pensamientos de Fin y eventos de conversación.
Diagnostica problemas comunes como activadores incorrectos de Procedure, pasos fuera de secuencia y fallos en ramificaciones.
Soluciona errores de Data connector, incluyendo fallos de autenticación y datos faltantes.
Valida las correcciones antes de ponerlas en producción usando Simulations.

Accediendo al depurador de conversaciones

Para entender por qué Fin tomó una acción específica, primero debes habilitar la visibilidad técnica dentro del hilo de conversación.

Abre la conversación específica en el Inbox.
Haz clic en el icono de tres puntos en la parte superior derecha del encabezado de la conversación.
Selecciona Mostrar eventos de conversación.

Consejo: Usa el atajo de teclado ⌘ + E (Mac) o Ctrl + Shift + E (Windows) para alternar esta vista.

Inspeccionando los "pensamientos de Fin"

Una vez que los eventos de conversación son visibles, puedes ver el razonamiento detrás de cada paso que Fin tomó durante un Procedure. Para rastrear el proceso de toma de decisiones de Fin, localiza los eventos Fin's thoughts en la línea de tiempo de la conversación. Estos eventos resumen el razonamiento de Fin antes de enviar un mensaje o realizar una acción.

Para más detalle granular, haz clic en Fin Thoughts y luego en Ver más. Esto revela:

El paso actual: El paso específico del Procedure que Fin estaba ejecutando.
Interpretación de la intención: Cómo Fin entendió la solicitud del cliente.
Ruta lógica: Por qué Fin decidió saltarse un paso, revisar uno anterior o pasar a una rama específica.

Importante: Este artículo cubre la solución de problemas solo para Fin Procedures. La línea de tiempo y el depurador de "Fin's thoughts" solo están disponibles cuando se activó un Procedure. Si Fin dio una respuesta inesperada en una conversación estándar, estas herramientas no estarán presentes en los eventos de conversación.

Fallos comunes de Procedure

Si Fin no funciona como se espera, generalmente se debe a cómo se redactan las instrucciones o cómo se ramifica la lógica.

El Procedure no se activa en absoluto

Antes de revisar los fallos numerados a continuación, repasa primero estos conceptos básicos:

Verifica que el procedure esté publicado: Los procedures en borrador no se activarán para los clientes. Confirma que el estado esté establecido en Published en el editor.
Verifica que Simple Deploy esté activo: Si Simple Deploy está desactivado, Fin no ejecutará ningún procedure. Ve a Fin AI Agent > Deploy > Chat y confirma que Fin esté habilitado.
Verifica la segmentación de audiencia: Un error común es segmentar a Users cuando el cliente es un Lead (o viceversa). En la sección "When to use this procedure", haz clic en el botón de audiencia y verifica que el tipo de audiencia y canal correctos estén seleccionados.
Verifica si hay workflows de mayor prioridad: Los workflows activos se ejecutan antes de que Fin evalúe la intención del procedure. Revisa tus workflows para asegurarte de que ninguno esté interceptando la conversación antes de que Fin pueda activar el procedure.
Revisa el alcance de los criterios de activación: Criterios demasiado restrictivos impiden que Fin coincida con mensajes válidos del cliente. Revisa la descripción "When to use this procedure" y agrega ejemplos positivos (mensajes que deberían activarlo) y negativos (mensajes que no deberían).

1. Fin activa el Procedure incorrecto

Problema: Fin inicia un Procedure que no coincide con la solicitud del cliente.

Solución: Revisa tus instrucciones de "When to use this procedure". Usa ejemplos positivos y negativos para ayudar a Fin a distinguir entre intenciones similares. Si un nuevo procedure comparte criterios de activación similares con un procedure publicado existente, el publicado puede tener prioridad. Para aislar el nuevo procedure durante las pruebas: excluye temporalmente a tu usuario de prueba del procedure existente ajustando sus criterios de audiencia, o restringe el activador del nuevo procedure a una frase única que solo tú enviarías. Usa Fin's thoughts > Expand thoughts en el depurador de conversaciones para confirmar qué procedure se activó realmente.

2. Pasos fuera de secuencia

Problema: Fin omite un paso previo o pasa a una resolución prematuramente.

Solución: Revisa si hay ambigüedad en tus instrucciones en lenguaje natural. Si un paso depende de un dato específico, asegúrate de que la instrucción indique explícitamente: "Solo procede si se proporciona [dato]."

3. Fallos en la lógica de ramificación

Problema: Fin sigue la ruta "Else" cuando debería haber seguido la ruta "If".

Solución: Inspecciona las Conditions. Si usas lenguaje natural para ramificar, intenta reformular para mayor claridad. Para lógica compleja (por ejemplo, cálculos de fechas), considera usar bloques de código Python para aplicar reglas estrictas y deterministas.

4. Contenido de Help Center con prioridad

Problema: Fin responde desde el Help Center en lugar de ejecutar el procedure, incluso cuando la intención del cliente coincide claramente con los criterios de activación del procedure.

Solución: Si Fin está por defecto respondiendo con una respuesta del Help Center en lugar de ejecutar el procedure, hay dos enfoques según tu configuración. Prueba la Opción 1 primero; si el problema persiste, pasa a la Opción 2.

Opción 1: Habilitar el cambio de Procedure
Agentic Switch es una configuración por procedure que permite a Fin cambiar automáticamente del procedure actual a otro procedure activo cuando detecta que la intención del cliente cambió a mitad de la conversación, en lugar de quedarse bloqueado en el procedure original o recurrir a una respuesta del Help Center. Cuando está habilitado:
- Fin revisa la conversación y todas las descripciones de activación de procedures activos para decidir cuándo cambiar serviría mejor al cliente
- Si varios procedures podrían aplicar, Fin puede hacer una pregunta aclaratoria para seleccionar el mejor
- Solo el procedure origen (del que Fin está cambiando fuera) necesita tener la configuración activada
- El comando @Switch aún puede usarse para cambiar manualmente
Para habilitarlo: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

Opción 2: Eliminar o actualizar contenido conflictivo del Help Center
Si habilitar Agentic Switch no resuelve el problema, la solución más confiable es eliminar o actualizar el contenido del Help Center que Fin está mostrando en lugar de ejecutar el procedimiento. Fin utiliza por defecto las respuestas del Help Center cuando existe contenido relevante para un tema; por lo tanto, si un artículo cubre la misma intención que tu procedimiento, Fin puede responder directamente desde él en lugar de activar el procedimiento.

Para identificar el contenido conflictivo:
- Encuentra la conversación en tu Inbox y abre Fin's thoughts.
- Busca referencias a artículos del Help Center en la ruta de respuesta.
- Elimina el artículo conflictivo o actualízalo para dirigir a los clientes a contactar con soporte, para que Fin redirija al procedimiento en su lugar.

Ejemplo: Una empresa tiene un procedimiento que maneja solicitudes de reembolso: recopila el número de pedido, verifica la elegibilidad y procesa el reembolso automáticamente. También tienen un artículo del Help Center titulado "¿Cómo obtengo un reembolso?" que explica la política de reembolso. Cuando un cliente envía el mensaje "Me gustaría un reembolso", Fin encuentra el artículo del Help Center y responde con la explicación de la política en lugar de activar el procedimiento. En este caso, actualizar el artículo para decir algo como "Para solicitar un reembolso, inicia un chat y nuestro asistente te guiará" elimina la respuesta conflictiva y redirige a los clientes al procedimiento.

5. El procedimiento se detiene o sale antes de completarse

Problema: El procedimiento llega a un cierto paso y se detiene, o sale a un estado final sin completar todos los pasos esperados.

Solución: Esto suele ser causado por patrones de diseño que confunden la capacidad de Fin para rastrear dónde está en el procedimiento. Revisa lo siguiente:

Declaraciones redundantes de "Proceder inmediatamente": Si varios pasos incluyen instrucciones como "proceder inmediatamente al siguiente paso", Fin puede reevaluar pasos ya completados en lugar de avanzar. Elimina estas declaraciones y permite que Fin avance naturalmente según el flujo.
Instrucciones para saltar pasos: Frases como "volver al paso 2" o "repetir el paso de verificación" pueden hacer que Fin entre en un bucle entre pasos en lugar de avanzar. Diseña cada paso para que haya un camino claro hacia adelante.
Lógica de condiciones superpuestas: Si dos condiciones pueden evaluarse como verdaderas al mismo tiempo, Fin puede ramificarse de forma impredecible o detenerse. Asegúrate de que tus condiciones sean mutuamente excluyentes: solo una rama debe ser verdadera en cualquier momento.
Salidas de subprocedimientos sin continuar: Si un subprocedimiento se completa pero el procedimiento principal no tiene una instrucción clara sobre qué hacer a continuación, Fin puede tratar el fin del subprocedimiento como el fin de todo el flujo. En el paso que llama al subprocedimiento, añade una instrucción explícita: "Una vez que el subprocedimiento esté completo, continúa con [nombre del siguiente paso]."

Usa Fin's thoughts > Ver más en el depurador de conversaciones para identificar exactamente en qué paso estaba Fin cuando el procedimiento salió inesperadamente.

Solución de problemas de conectores de datos

Esta sección cubre fallos específicos de conectores de datos que se ejecutan dentro de un Procedimiento. Si tu conector pasa pruebas independientes pero falla durante una ejecución en vivo del Procedimiento, comienza aquí.

El conector funciona en pruebas pero falla en un Procedimiento en vivo

Problema: El conector pasa pruebas independientes pero falla durante una ejecución en vivo.

Solución: Esto suele ser causado por una de las siguientes razones:

Credenciales: Guarda y vuelve a publicar después de rotar una clave. Revisa si hay caracteres ocultos como espacios al final en los valores del token.
Permisos: Un cambio reciente de seguridad en tu sistema externo puede haber eliminado el acceso.
Lista blanca de IPs: Confirma que las IPs salientes de Intercom estén incluidas. Contacta a tu gerente de cuenta para los rangos actuales.

Importante: Si tu conector deja de funcionar sin cambios de tu parte, verifica si tu proveedor externo de API (por ejemplo, Shopify, Stripe) ha actualizado o eliminado un endpoint.

Errores de autorización 401 y 403

401 No autorizado: El token falta, ha expirado o está mal formado. Intercom reintenta automáticamente una vez. Revisa la pestaña Logs para confirmar si se intentó una actualización.
403 Prohibido: El token es válido pero carece de permiso. Revisa los permisos en tu sistema externo.
Usuarios OAuth: Usa el botón Reauthenticate en lugar de eliminar y recrear el token.

El conector no parece activarse

Revisa los logs: Navega a Settings > Integrations > Data connectors > Logs. Si no hay entrada de log, probablemente se saltó el paso; revisa la lógica de la rama anterior.
Revisa eventos de conversación: Selecciona Logs de cualquier evento de error en el Inbox para detalles completos.

El conector devuelve datos pero Fin no los usa

Usa Fin's thoughts para ver cómo Fin interpretó la respuesta del conector.
Haz la instrucción del paso más explícita: "Usa @connector_name para responder esto—no uses contenido de knowledge base."
Verifica si la respuesta está vacía o es nula; Fin puede recurrir a otras fuentes si no se encuentran datos utilizables.
Fin llama a un conector por turno: Si tu procedimiento necesita hacer múltiples llamadas a conectores en secuencia, cada llamada debe ser un paso distinto. Fin procesa una llamada a herramienta por turno de conversación; no puede encadenar múltiples llamadas a conectores dentro de una sola instrucción de paso.

Importante: Fin solo puede procesar una llamada a conector por turno, así que si tu servidor MCP envía dos respuestas separadas por el mismo flujo SSE, Fin no podrá usar de forma confiable la primera respuesta para construir su respuesta.

El conector no aparece en el editor de procedimientos

Problema: Tu conector de datos está publicado y configurado, pero no aparece cuando intentas agregarlo a un paso dentro del editor de procedimientos.

Solución: Revisa estos puntos en orden:

Confirma que el conector esté en modo Live: Ve a Settings > Integrations > Data connectors y verifica el estado del conector. Un conector en Draft no aparecerá en el editor de procedimientos.
Verifica que al menos una acción esté configurada: Un conector sin acciones definidas no aparecerá como opción en el editor de procedimientos, incluso si está en modo Live.
Revisa los permisos de tu rol: Algunos roles pueden ver conectores en Settings pero no acceder a ellos dentro del editor de procedimientos. Confirma que tu rol tenga acceso a ambas áreas.
Actualiza la página: El editor de procedimientos a veces necesita una actualización completa para reflejar conectores publicados recientemente. Usa ⌘ + Shift + R (Mac) o Ctrl + Shift + R (Windows).
Contacta al soporte de Intercom: Si nada de lo anterior lo resuelve, contacta al soporte de Intercom con el nombre del conector y los detalles de tu espacio de trabajo. Algunas configuraciones de espacio de trabajo requieren un paso manual para que un conector esté disponible dentro del editor de procedimientos.

El conector falla en modo de autoejecución

Problema: El conector de datos está configurado para ejecutarse automáticamente, sin solicitar al cliente, pero falla silenciosamente durante una conversación en vivo. Fin escala o da una respuesta inesperada, y no hay error visible en la conversación.

Solución: En modo de autoejecución, Fin no puede saltarse un paso de conector fallido y continuar el procedimiento. Si el conector devuelve un error, Fin trata todo el paso como irresoluble y escala a un humano o vuelve a su comportamiento predeterminado.

Hay dos formas de manejar esto:

Modifica tu API externa para devolver un valor de respaldo: En lugar de devolver un error cuando no hay datos disponibles (por ejemplo, un 404 cuando no se encuentra un pedido), configura tu API para devolver un resultado vacío o predeterminado que Fin pueda usar. Esta es la solución más confiable porque Fin siempre recibe algo con lo que trabajar.
Añade un paso de Condición después de la llamada al conector: Usa la salida status_code del conector para ramificar a un mensaje amable o a una ruta de escalada controlada cuando el conector falle. Consulta "Manejo avanzado de fallos con status_code" en este artículo para saber cómo configurarlo.

La salida del conector no llena los atributos de la conversación

Problema: Un paso de conector de datos se ejecuta y devuelve los datos esperados, pero el valor no aparece como un atributo de la conversación, y los pasos posteriores en el procedimiento no pueden acceder a él.

Solución: Los atributos de la conversación se establecen al inicio de una conversación y no pueden actualizarse en tiempo real mientras se ejecuta un procedimiento. Un conector que se ejecuta dentro de un procedimiento no puede escribir un nuevo valor en un atributo de conversación a mitad de la conversación.

Lo que esto significa en la práctica:

Use la salida del conector directamente en pasos posteriores: Los datos que devuelve su conector están disponibles como salida de paso dentro del procedimiento. Refiérase a ellos en las instrucciones de pasos posteriores usando la sintaxis de salida @connector_name. El valor es accesible dentro del procedimiento, simplemente no aparecerá como un atributo de conversación en el Inbox.
Para persistir datos en un atributo de conversación: Use un paso Handoff to workflow y establezca el valor del atributo dentro del workflow en su lugar. Tenga en cuenta que el procedimiento no se reanudará después del traspaso, así que planifique su flujo para completarse antes de hacer el traspaso.

Conector de datos configurado para READ en lugar de UPDATE

Problema: El procedimiento se ejecuta pero no recopila ni almacena la entrada del cliente, aunque el paso del conector de datos parece ejecutarse.

Solución: Verifique el tipo de acción del conector de datos en el paso correspondiente. READ solo verifica un valor almacenado existente; no solicitará entrada al cliente ni guardará datos nuevos. UPDATE recopila la entrada del cliente y la guarda en el atributo. Si su procedimiento debe recopilar información del cliente (por ejemplo, una dirección de correo electrónico, número de pedido o motivo de contacto), cambie el tipo de acción a UPDATE.

Manejo avanzado de fallos con status_code

El status_code devuelto por una llamada al conector de datos se expone como un atributo de salida. Puede referenciarlo en un Condition step para ramificar según códigos de respuesta HTTP específicos, dándole control preciso sobre cómo Fin maneja diferentes escenarios de fallo en lugar de depender de una sola rama de éxito/fallo.

Por ejemplo, puede dirigir un 404 (recurso no encontrado) a un mensaje diferente que un 500 (error del servidor), o escalar a un agente humano solo cuando se devuelve un código de error específico.

Consejo: Consulte Cómo escribir condiciones de código para Fin Procedures para ejemplos de código usando status_code en un Condition step.

Validando correcciones con Simulations

Antes de activar su Procedure, use Simulations para verificar la corrección:

Vista previa vs. Simulations — ¿cuál debo usar? Vista previa muestra la experiencia completa para el cliente. Usar Vista previa mientras su procedimiento está activo puede exponer mensajes de pasos a clientes reales. Simulations ejecutan el procedimiento en segundo plano sin salida visible para el cliente; son la forma más segura de validar la lógica y activar coincidencias antes de activar en vivo.

Navegue al editor de Procedure y haga clic en Test.
Ejecute una Simulation donde la IA actúe como el cliente en el escenario fallido.
Revise el resultado de aprobado/reprobado y el juicio de la IA para confirmar que la lógica es confiable.

Preguntas frecuentes

¿Funciona el depurador de conversación para conversaciones estándar de Fin?

No, la línea de tiempo y el depurador "Fin's thoughts" solo están disponibles cuando se ha activado un Procedure. Si Fin dio una respuesta inesperada en una conversación estándar, estas herramientas no estarán presentes; revise los eventos de conversación en el Inbox en su lugar.

¿Cuánto tiempo se almacenan los registros del conector de datos?

Los registros de respuesta del conector de datos se almacenan por defecto hasta 7 días. Si su espacio de trabajo tiene registros extendidos habilitados, esto aumenta a 14 días. Accédalos en Settings > Integrations > Data connectors > Logs.

¿Puedo usar Simulations para probar respuestas del conector de datos?

Sí — Simulations ejecutan el Procedure completo incluyendo cualquier paso de conector de datos, siendo la forma más confiable de validar el comportamiento del conector antes de activarlo en vivo.

¿Por qué mi Procedure está siendo bloqueado por un Workflow?

Los Workflows se ejecutan antes de que Fin evalúe la intención del procedimiento. Si un Workflow está activo para el mismo disparador de conversación, puede dirigir la conversación antes de que Fin tenga oportunidad de coincidir con un procedimiento. Para solucionar esto: revise sus workflows activos para disparadores superpuestos y asegúrese de que el bloque Let Fin Handle esté configurado correctamente en la ruta del workflow donde desea que los procedimientos estén disponibles.

¿Por qué mi Procedure hizo un traspaso inesperado a un humano?

Hay dos formas en que un Procedure puede hacer un traspaso a un humano:

Comportamiento de escalada predeterminado — Fin escala automáticamente según su lógica incorporada: cuando un cliente claramente pide hablar con un humano, cuando Fin detecta fuerte frustración o enojo, o cuando el cliente está atrapado en un bucle repetitivo. Esto siempre se activa sin importar cómo esté configurado su Procedure.
Traspaso configurado — Un paso Handoff to team que ha agregado en un punto específico del Procedure, o una guía específica del procedimiento que ha escrito que instruye a Fin a hacer el traspaso en un escenario particular.

Si el traspaso fue inesperado, use Fin's thoughts en el depurador de conversación para ver qué tipo se activó y en qué paso.

¿Por qué no se activa mi Escalation Guidance dentro de un Procedure?

La Escalation Guidance no se aplica dentro de un Procedure por defecto; debe habilitarla explícitamente en el panel Guidance del Procedure:

Abra su Procedure, haga clic en la rueda de configuración en la esquina superior derecha del editor de Instructions y haga clic en Guidance.
Seleccione las categorías de guía a nivel de espacio de trabajo que desea aplicar, incluyendo Handover and escalation.
Fin combinará la guía seleccionada a nivel de espacio de trabajo con cualquier guía personalizada específica del procedimiento que haya escrito.

Nota: El comportamiento de escalada predeterminado de Fin (cliente pide un humano, se detecta frustración, bucle repetitivo) siempre se activa dentro de un Procedure sin importar la configuración de Guidance. El panel Guidance controla solo su Escalation Guidance y Escalation Rules a nivel de espacio de trabajo.

¿Cuál es la diferencia entre Handoff to team y Handoff to workflow?

Ambos pasos terminan el Procedure, pero dirigen la conversación de manera diferente:

Handoff to team — Termina el Procedure y entrega la conversación a un compañero humano. La conversación sigue la ruta de escalada configurada en su workflow de Deploy después del paso Let Fin handle (bloque Let Fin handle).
Handoff to workflow — Termina el Procedure y pasa la conversación a un Workflow reutilizable específico que ya ha construido (por ejemplo, una encuesta de satisfacción o un flujo de enrutamiento especializado). El Procedure no se reanudará después de que el Workflow termine.

¿Se factura un traspaso de Procedure como un Fin Outcome?

Un Procedure de Fin solo se factura como un Fin Outcome cuando la conversación termina de una de dos maneras:

Resolución — el cliente confirma que Fin resolvió su problema, o no solicita más ayuda después de que Fin responde.
Procedure Handoff — Fin hace un traspaso a un equipo, compañero o workflow mediante un paso de Handoff configurado o una guía específica del procedimiento que haya establecido.
En ambos casos, se le cobra $0.99, y solo una vez por conversación, sin importar cuántos pasos haya ejecutado Fin o cuántas preguntas haya hecho el cliente.

Nota: No se le cobrará si un Procedure no se completa, sale sin alcanzar uno de estos resultados, un cliente pide hablar con un humano en cualquier momento, o la conversación termina mediante el comportamiento de escalada predeterminado de Fin o las reglas de escalada a nivel de espacio de trabajo.

Para más detalles, consulte Entendiendo Fin Outcomes.

Mi Procedimiento se detiene a mitad de la conversación: ¿podría ser un tiempo de espera?

Sí. Los procedimientos se ejecutan dentro de un bloque Let Fin Handle en tu Workflow, y ese bloque tiene un tiempo de espera por inactividad predeterminado. Si un cliente tarda más en responder, el bloque puede cerrarse antes de que el procedimiento termine. Para solucionarlo, abre el bloque Let Fin Handle en la configuración de tu Workflow y aumenta el tiempo de espera por inactividad para que coincida mejor con la duración esperada de la conversación.

¿Puedo usar Guidance para activar un Procedimiento?

No. Guidance controla cómo responde y se comporta Fin; no puede iniciar un procedimiento ni dirigir una conversación hacia uno. Los dos sistemas son separados: Guidance define el tono y las reglas de escalación de Fin; los Procedimientos definen los workflows paso a paso que Fin sigue cuando se detecta una intención específica.

Para cambiar de un procedimiento a otro a mitad de la conversación, usa el comando @Switch dentro del procedimiento origen, o activa Agentic Switch en la configuración del procedimiento (consulta "4. Help Center content taking priority" en este artículo).

Si quieres que Fin decida inteligentemente cuándo llamar a un conector de datos o seguir un flujo específico según lo que diga el cliente, construye esa lógica en un procedimiento en lugar de en Guidance.

Mi condición de código no está ramificándose: ¿cómo la depuro?

Las condiciones de código fallan silenciosamente cuando hay un error de sintaxis o cuando la ruta de datos que intentas acceder no existe en el contexto de la conversación. Fin no mostrará el error directamente; simplemente seguirá la rama Else o se detendrá. Aquí te explicamos cómo diagnosticarlo:

Abre la conversación en el Inbox y activa Mostrar eventos de conversación (consulta "Accediendo al depurador de conversación" arriba).
En Fin's thoughts, verifica qué valor recibió Fin como entrada para tu condición. Si el valor es null o undefined, la ruta de datos en tu código es incorrecta.
Revisa estos patrones comunes de acceso a datos: • Tipo de cliente: inputs["user"]["role"] — devuelve "user" o "lead" • Salida del conector: usa el nombre exacto del campo del esquema de respuesta de tu conector • Atributo de conversación: inputs["conversation"]["attribute_name"]
Prueba tu bloque de código en un intérprete de Python antes de agregarlo al procedimiento. Esto detecta errores de sintaxis inmediatamente, sin necesidad de ejecutar una conversación en vivo.
Si la condición se evalúa pero dirige a la rama incorrecta, agrega una instrucción print() en tu bloque de código para registrar el valor real que Fin está recibiendo. La salida aparecerá en los eventos de la conversación.

Solución de problemas de Fin Procedures y Data connectors