Cuando un Procedimiento Fin 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 en Procedimientos usando los pensamientos de Fin y eventos de conversación.
Diagnostica problemas comunes como activadores incorrectos de Procedimientos, pasos fuera de secuencia y fallos en la ramificación.
Soluciona errores de conectores de Datos, incluyendo fallos de autenticación y datos faltantes.
Valida las correcciones antes de ponerlas en producción usando Simulaciones.
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 Procedimiento. Para rastrear el proceso de toma de decisiones de Fin, localiza los eventos pensamientos de Fin 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 Procedimiento 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.
Nota: Este artículo cubre la solución de problemas solo para Procedimientos Fin. La línea de tiempo y el depurador de "pensamientos de Fin" solo están disponibles cuando se activó un Procedimiento. 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 en Procedimientos
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 Procedimiento no se activa en absoluto
Antes de revisar los fallos numerados a continuación, repasa primero estos conceptos básicos:
Verifica que el procedimiento esté publicado: Los procedimientos en borrador no se activarán para los clientes. Confirma que el estado esté establecido en Publicado en el editor.
Verifica que Fin esté desplegado: Si Fin no está habilitado a través de la sección Simply Deploy, o el paso "Deja que Fin maneje" no está activo en tu workflow, Fin no ejecutará ningún procedimiento.
Verifica la segmentación de audiencia: Un error común es dirigir a Users cuando el cliente es un Lead (o viceversa). En la sección "Cuándo usar este procedimiento", haz clic en el botón de audiencia y verifica que el tipo de audiencia y canal correctos estén seleccionados.
Verifica workflows de mayor prioridad: Los workflows activos se ejecutan antes de que Fin evalúe la intención del procedimiento. Revisa tus workflows para asegurarte de que ninguno esté interceptando la conversación antes de que Fin pueda activar el procedimiento.
Revisa el alcance de los criterios de activación: Criterios demasiado restrictivos impiden que Fin coincida con mensajes válidos de clientes. Revisa la descripción de "Cuándo usar este procedimiento" y agrega ejemplos positivos (mensajes que deberían activarlo) y negativos (mensajes que no deberían).
Nota: Aunque Slack puede aparecer como un canal seleccionable, actualmente no se soportan activadores de procedimiento para conversaciones de Slack.
Fin activa el Procedimiento incorrecto
Problema: Fin inicia un Procedimiento que no coincide con la solicitud del cliente.
Solución: Revisa tus instrucciones de "Cuándo usar este procedimiento". Usa ejemplos positivos y negativos para ayudar a Fin a distinguir entre intenciones similares. Si un nuevo procedimiento comparte criterios de activación similares con un procedimiento publicado existente, el publicado puede tener prioridad. Para aislar el nuevo procedimiento durante las pruebas: excluye temporalmente a tu usuario de prueba del procedimiento existente ajustando sus criterios de audiencia, o restringe el activador del nuevo procedimiento a una frase única que solo tú enviarías. Usa pensamientos de Fin > Expandir pensamientos en el depurador de conversaciones para confirmar qué procedimiento se activó realmente.
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]."
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 Condiciones. Si usas lenguaje natural para la ramificación, 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.
El contenido del Help Center tiene prioridad
Problema: Fin responde desde el Help Center en lugar de ejecutar el procedimiento, incluso cuando la intención del cliente coincide claramente con los criterios de activación del procedimiento.
Solución: Si Fin está por defecto respondiendo con una respuesta del Help Center en lugar de ejecutar el procedimiento, 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 cambio de Procedimiento
Agentic Switch es una configuración por procedimiento que permite a Fin cambiar automáticamente del procedimiento actual a otro procedimiento activo cuando detecta que la intención del cliente cambió a mitad de la conversación, en lugar de quedarse bloqueado en el procedimiento 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 procedimientos activos para decidir cuándo cambiar serviría mejor al cliente
Si múltiples procedimientos podrían aplicar, Fin puede hacer una pregunta aclaratoria para seleccionar el mejor
Solo el procedimiento origen (del que Fin está cambiando fuera) necesita tener la configuración activada
El comando
@Switchaún puede usarse para cambiar manualmente
Para habilitarlo: Fin AI Agent > Entrenar > Procedimientos > Configuración > Agentic Switch
Opción 2: Eliminar o actualizar el 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 los pensamientos de Fin.
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 soporte, de modo 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 reembolsos. Cuando un cliente escribe "Quisiera 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.
El procedimiento se detiene o finaliza antes de completarse
Problema: El procedimiento llega a un paso determinado y se detiene, o finaliza en 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 en qué parte del procedimiento se encuentra. Verifica 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 continuación: 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 los pensamientos de Fin > Ver más en el depurador de conversaciones para identificar exactamente en qué paso estaba Fin cuando el procedimiento salió inesperadamente.
Problemas en móviles (iOS) con Procedimientos
En móviles (iOS), los Procedimientos tienen requisitos adicionales:
Solo para Users: Los Procedimientos solo se activan para Users en móviles; no se ejecutarán para Leads o Visitors sin importar cómo esté configurada la audiencia en el procedimiento.
El canal iOS debe estar seleccionado: En la sección "Cuándo usar este procedimiento", iOS debe estar seleccionado como canal. El procedimiento no se activará en móviles si solo está marcado Web.
El procedimiento debe estar Publicado: Los procedimientos en borrador no se sirven a clientes móviles.
Verifica que Fin esté desplegado para iOS: Los Procedimientos necesitan que Fin esté activo en el canal iOS. Confirma que Simple Deploy esté habilitado en Fin AI Agent > Deploy > Chat, o que haya un bloque activo Let Fin Handle en el workflow relevante dirigido a iOS.
Workflows de mayor prioridad: Un workflow que se ejecute para el mismo disparador de conversación en iOS puede interceptar la conversación antes de que Fin evalúe la intención del procedimiento. Revisa tus workflows activos para solapamientos en el canal iOS.
Solución de problemas con conectores de datos en Procedimientos
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. Verifica 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, está expirado o 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 ninguna entrada de log, probablemente se saltó el paso; revisa la lógica de la rama anterior.
Revisa los 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 los pensamientos de Fin 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 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 confiablemente 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: Realiza estas verificaciones en orden:
Confirma que el conector esté en Vivo: Ve a Settings > Integrations > Data connectors y verifica el estado del conector. Un conector en Borrador 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 Vivo.
Verifica los permisos de tu rol: Algunos roles pueden ver conectores en Settings pero no pueden 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 los conectores publicados recientemente. Usa ⌘ + Shift + R (Mac) o Ctrl + Shift + R (Windows).
Contacta con Fin Support: Si nada de lo anterior lo resuelve, contacta con Fin Support con el nombre del conector y los detalles de tu workspace. Algunas configuraciones de workspace requieren un paso manual para que un conector esté disponible dentro del editor de procedimientos.
El conector falla en modo de auto-ejecució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 auto-ejecució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 o bien 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 los datos no están 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 puede trabajar.
Agrega un paso de Condición después de la llamada al conector: Usa la salida
status_codedel 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 conversación — y los pasos posteriores en el procedimiento no pueden acceder a él.
Solución: Los atributos de 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:
Usa la salida del conector directamente en pasos posteriores: Los datos que devuelve tu conector están disponibles como salida de paso dentro del procedimiento. Haz referencia 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: Usa un paso Handoff to workflow y establece el valor del atributo dentro del workflow en su lugar. Ten en cuenta que el procedimiento no se reanudará después del traspaso, así que planifica tu flujo para completarse antes de hacer el traspaso.
Conector de datos configurado para LEER en lugar de ACTUALIZAR
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: Verifica 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 tu procedimiento debe recopilar información del cliente (por ejemplo, una dirección de correo electrónico, número de pedido o motivo de contacto), cambia 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. Puedes hacer referencia a esto en un paso de Condición para ramificar según códigos de respuesta HTTP específicos, dándote un control preciso sobre cómo Fin maneja diferentes escenarios de fallo en lugar de depender de una única rama de éxito/fallo.
Por ejemplo, puedes 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: Consulta Cómo escribir condiciones de código para Fin Procedures para ejemplos de código usando status_code en un paso de Condición.
Validando correcciones con Simulations
Antes de poner tu Procedure en vivo, usa 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 tu 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 ponerlo en vivo.
Navega al editor de Procedure y haz clic en Test.
Ejecuta una Simulation donde la IA actúa como el cliente en el escenario fallido.
Revisa 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 conversaciones para conversaciones estándar de Fin?
¿Funciona el depurador de conversaciones 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; revisa los eventos de conversación en el Inbox en su lugar.
¿Cuánto tiempo se almacenan los registros del conector de datos?
¿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 tu workspace tiene registros extendidos habilitados, esto aumenta a 14 días. Accede a ellos en Settings > Integrations > Data connectors > Logs.
¿Puedo usar Simulations para probar respuestas del conector de datos?
¿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 ponerlo en vivo.
¿Por qué mi Procedure está siendo bloqueado por un Workflow?
¿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 solucionarlo: revisa tus workflows activos para disparadores superpuestos y asegúrate de que el bloque Let Fin Handle esté configurado correctamente en la ruta del workflow donde quieres que los procedimientos estén disponibles.
¿Por qué mi Procedure pasó a un humano inesperadamente?
¿Por qué mi Procedure pasó a un humano inesperadamente?
Hay dos formas en que un Procedure puede pasar 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 tu Procedure.
Traspaso configurado — Un paso Handoff to team que has añadido en un punto específico del Procedure, o una guía específica del Procedure que has escrito que indica a Fin pasar en un escenario particular.
Si el traspaso fue inesperado, usa Fin's thoughts en el depurador de conversaciones para ver qué tipo se activó y en qué paso.
¿Por qué no se activa mi Escalation Guidance dentro de un Procedure?
¿Por qué no se activa mi Escalation Guidance dentro de un Procedure?
La Escalation Guidance no se aplica dentro de un Procedure por defecto — necesitas habilitarla explícitamente en el panel de Guidance del Procedure:
Abre tu Procedure, haz clic en la rueda de configuración en la esquina superior derecha del editor de Instructions y haz clic en Guidance.
Selecciona las categorías de guidance a nivel de workspace que quieres aplicar, incluyendo Handover and escalation.
Fin combinará la guidance seleccionada a nivel de workspace con cualquier guidance específica del Procedure que hayas 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 de Guidance controla solo tu Escalation Guidance y Escalation Rules a nivel de workspace.
¿Cuál es la diferencia entre Handoff to team y Handoff to workflow?
¿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 pasa la conversación a un compañero humano. La conversación luego sigue la ruta de escalada configurada en tu Deploy workflow después del paso Let Fin handle (bloque Let Fin handle).
Transferencia a workflow — Finaliza el Procedimiento y pasa la conversación a un Workflow reutilizable específico que ya has creado (por ejemplo, una encuesta de satisfacción o un flujo de enrutamiento especializado). El Procedimiento no se reanudará después de que el Workflow termine.
¿Se factura una transferencia de Procedimiento como un Fin Outcome?
¿Se factura una transferencia de Procedimiento como un Fin Outcome?
Un Procedimiento 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.
Transferencia de Procedimiento — Fin transfiere a un equipo, compañero o workflow mediante un paso de Transferencia configurado o una guía específica del procedimiento que has establecido.
En ambos casos, se te 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 te cobrará si un Procedimiento no se completa, sale sin alcanzar uno de estos resultados, un cliente solicita hablar con un humano en cualquier momento, o la conversación termina mediante el comportamiento de escalación predeterminado de Fin o las reglas de escalación a nivel de espacio de trabajo.
Para más detalles, consulta Understanding Fin Outcomes.
Mi Procedimiento se detiene a mitad de la conversación — ¿podría ser por tiempo de espera?
Mi Procedimiento se detiene a mitad de la conversación — ¿podría ser por 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 de inactividad predeterminado. Si un cliente tarda más que eso 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 de inactividad para que coincida mejor con la duración esperada de la conversación.
¿Puedo usar Guidance para activar un Procedimiento?
¿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 da forma al 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 habilita 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 basado en lo que dice 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?
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 a la 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 habilita Mostrar eventos de conversación (consulta "Accediendo al depurador de conversación" arriba).
En los pensamientos de Fin, verifica qué valor recibió Fin como entrada para tu condición. Si el valor es
nulloundefined, 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.



