Cuando una 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 el flujo se desvió y cómo refinar tus instrucciones.

Qué aprenderás

Depura fallos de Procedure usando Fin's thoughts y los eventos de la conversación.
Diagnostica problemas comunes como disparadores incorrectos de Procedure, pasos fuera de secuencia y fallos de bifurcación.
Soluciona errores de Data connector, incluidas fallas de autenticación y datos faltantes.
Valida las correcciones antes de publicarlas usando Simulations.

Acceder 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 la 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 la conversación.

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

Inspeccionando "Fin's thoughts"

Una vez que los eventos de la conversación sean visibles, puedes ver el razonamiento detrás de cada paso que Fin realizó durante una 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 ejecutar una acción.

Para detalles más granulares, haz clic en Fin Thoughts y haz clic en Ver más. Esto revela:

El paso actual: El paso específico de la 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ó omitir un paso, volver a uno anterior o pasar a una rama específica.

Nota: Este artículo cubre 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ó una Procedure. Si Fin dio una respuesta inesperada en una conversación estándar, estas herramientas no estarán presentes en los eventos de la 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.

La Procedure no se activa en absoluto

Antes de revisar los fallos numerados a continuación, repasa estos fundamentos primero:

Verifica que la procedure esté publicada: Los procedimientos en borrador no se activarán para los clientes. Confirma que el estado esté establecido en Published 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 "Let Fin handle" no está activo en tu workflow, Fin no ejecutará procedimientos.
Verifica la segmentación de audiencia: Un error común es apuntar 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 el 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 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 estrechos impiden que Fin coincida con mensajes válidos de los clientes. Revisa la descripción de "When to use this procedure" y agrega ejemplos positivos (mensajes que deberían activarlo) y ejemplos negativos (mensajes que no deberían).

Nota: Aunque Slack puede aparecer como un canal seleccionable, los disparadores de Procedure actualmente no son compatibles con conversaciones de Slack.

Fin activa el Procedure incorrecto

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

Solución: Revisa tus instrucciones "When to use this procedure". 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 tu usuario de prueba del procedimiento existente ajustando sus criterios de audiencia, o restringe el disparador del nuevo procedimiento 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.

Pasos fuera de secuencia

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

Solución: Verifica la 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 [data] se proporciona."

Fallos en la lógica de bifurcació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 la bifurcación, intenta reformular para mayor claridad. Para lógica compleja (por ejemplo, cálculos de fechas), considera usar bloques de código Python para imponer reglas deterministas estrictas.

El contenido del Help Center tiene 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á optando por 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 Procedure Switching
Agentic Switch es una configuración por procedimiento que permite a Fin cambiar automáticamente de un procedimiento activo a otro cuando detecta que la intención del cliente cambió en medio de la conversación, en lugar de permanecer 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 el cambio 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 fuente (del cual Fin está cambiando) necesita tener la configuración activada
- El comando @Switch aún se puede usar para cambiar manualmente
Para habilitarlo: Fin AI Agent > Train > Procedures > Settings > Agentic Switch

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

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

Ejemplo: Una empresa tiene un procedimiento que gestiona solicitudes de reembolso: recopila el número de pedido, comprueba la elegibilidad y procesa el reembolso automáticamente. También tienen un artículo de Help Center titulado "¿Cómo consigo un reembolso?" que explica la política de reembolsos. Cuando un cliente escribe "Me gustaría un reembolso", Fin encuentra el artículo de 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 dirige a los clientes al procedimiento.

El procedimiento se detiene o sale antes de completarse

Problema: El procedimiento alcanza cierto paso y se detiene, o finaliza en un estado de término sin completar todos los pasos esperados.

Solución: Esto suele deberse a patrones de diseño que confunden la capacidad de Fin para rastrear en qué punto del procedimiento se encuentra. Comprueba lo siguiente:

Declaraciones redundantes "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 instrucciones y deja que Fin avance por el procedimiento de forma natural según el flujo.
Instrucciones de salto de paso: Frases como "volver al paso 2" o "repetir el paso de verificación" pueden provocar que Fin entre en bucle entre pasos en vez de avanzar. Diseña cada paso para que exista una única vía clara hacia adelante.
Lógica de condiciones superpuestas: Si dos condiciones pueden evaluarse como verdaderas al mismo tiempo, Fin puede ramificarse de forma impredecible o quedarse atascado. Asegúrate de que tus condiciones sean mutuamente excluyentes: solo una rama debe ser verdadera en cada momento.
Subprocedimientos que finalizan 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 interpretar 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 > See more en el depurador de conversaciones para identificar exactamente en qué paso estaba Fin cuando el procedimiento finalizó inesperadamente.

Incompatibilidad de tipo de atributo provoca fallos al guardar

Problema: El procedimiento falla al guardar una respuesta en un atributo de la conversación.

Solución: Comprueba que el tipo de atributo coincida con el valor que el procedimiento intenta guardar. Si el procedimiento guarda una cadena (por ejemplo, una respuesta del cliente recopilada durante la conversación), el atributo de destino debe ser de tipo cadena. Usar un atributo de tipo lista con el mismo nombre provocará fallos al guardar. Para solucionarlo, actualiza el procedimiento para que haga referencia al atributo correcto, o ve a Settings > Data > Conversations para cambiar el tipo de atributo.

Problemas en móviles (iOS) con Procedures

En móvil (iOS), Procedures tienen requisitos adicionales:

Users only: Procedures solo se activan para Users en móviles: no se ejecutarán para Leads o Visitors independientemente de cómo esté configurada la audiencia en el procedimiento.
El canal iOS debe estar seleccionado: En la sección "When to use this procedure", iOS debe estar marcado como canal. El procedimiento no se activará en móvil si solo está marcada la opción Web.
El procedimiento debe estar publicado: Los procedimientos en borrador no se sirven a clientes móviles.
Comprueba 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 exista un bloque activo Let Fin Handle en el workflow relevante apuntando a iOS.
Workflows de mayor prioridad: Un workflow que se ejecute para el mismo desencadenante 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 de conectores de datos en Procedures

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

El conector funciona en las pruebas pero falla en un Procedure en vivo

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

Solución: Esto suele deberse a una de las siguientes causas:

Credenciales: Vuelve a guardar y republícalo tras rotar una clave. Comprueba caracteres ocultos como espacios finales en los valores del token.
Permisos: Un cambio reciente de seguridad en tu sistema externo puede haber eliminado el acceso.
Listas de permitidos por IP: Confirma que las IP de salida de Intercom están incluidas. Contacta con tu gerente de cuenta para los rangos actuales.

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

Errores de autorización 401 y 403

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

El conector no parece activarse

Comprueba los registros: Ve a Settings > Integrations > Data connectors > Logs. Si no hay entrada en los registros, probablemente se omitió el paso; revisa la lógica de la rama previa.
Comprueba los eventos de la conversación: Selecciona Logs desde cualquier evento de error en la Inbox para ver 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 a esto—no uses contenido de knowledge base."
Comprueba si la respuesta está vacía o es nula; Fin puede recurrir a otras fuentes si no encuentra datos utilizables.
Fin llama a un conector por turno: Si tu procedimiento necesita hacer varias llamadas a conectores en secuencia, cada llamada debe ser un paso distinto. Fin procesa una herramienta por turno de conversación—no puede encadenar varias llamadas a conectores dentro de una única instrucción de paso.

Importante: Fin solo puede procesar una llamada al conector por turno, así que si tu servidor MCP devuelve dos respuestas separadas por la misma secuencia SSE, Fin no podrá usar de forma fiable la primera respuesta para construir su respuesta.

El conector no aparece en el editor de procedimientos

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

Solución: Revisa estas comprobaciones en orden:

Confirma que el conector está en Live: Ve a Settings > Integrations > Data connectors y comprueba 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á Live.
Comprueba 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 tiene 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 con Fin Support: Si nada de lo anterior lo resuelve, ponte en contacto 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 ejecución automática

Problema: El data connector 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 un error visible en la conversación.

Solución: En modo de ejecución automática, Fin no puede omitir 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 reserva: 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 procesar. Esta es la solución más fiable porque Fin siempre recibe algo con lo que trabajar.
Añade un paso Condition después de la llamada al conector: Usa la salida status_code del conector para ramificar a un mensaje controlado o a una ruta de escalado cuando el conector falle. Consulta "Advanced failure handling with status_code" en este artículo para ver cómo configurarlo.

El conector devuelve 404 o los atributos de contacto no se escriben aunque parezca ejecutarse

Problema: El conector parece activarse — los registros muestran que se ejecutó — pero devuelve un error 404 y los atributos de contacto no se escriben, aunque todos los conectores parecen estar configurados correctamente.

Solución: Esto casi siempre es causado por una pastilla de atributo inválida en la URL de la solicitud. Uno de los parámetros de la URL se está resolviendo como un valor vacío en tiempo de ejecución, haciendo que la URL sea incorrecta.

La causa más común: se escribió manualmente un atributo como {{Attribute Name}} en lugar de seleccionarlo desde el Attribute Inserter. El editor convierte cualquier texto {{...}} en una pastilla que parece idéntica a un atributo válido — pero si el identificador no corresponde a un atributo real, se resuelve como vacío en tiempo de ejecución y la URL de la solicitud se vuelve inválida.

Para solucionar esto:

Abre el conector e inspecciona la URL de la solicitud y el cuerpo en busca de pastillas de atributo.
Elimina cualquier pastilla que se haya escrito manualmente y reemplázala seleccionando el atributo correcto desde el selector Attribute Inserter.
Si tu URL requiere el Intercom contact ID, selecciona Contact ID (user.id) desde el selector — no User ID (user_id). La Contacts API espera el ID de contacto generado por Intercom (user.id), no el user ID establecido externamente (user_id).

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

Problema: Un paso de data connector se ejecuta y devuelve los datos esperados, pero el valor no aparece como atributo de conversación — y 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.

Qué significa esto 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 instrucciones de pasos posteriores usando la sintaxis de salida @connector_name. El valor es accesible dentro del procedimiento — simplemente no aparecerá como 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 handoff, así que planifica tu flujo para completarlo antes del handoff.

Conector de datos configurado en READ en lugar de UPDATE

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

Solución: Comprueba el tipo de acción del data connector en el paso relevante. READ solo comprueba un valor almacenado existente — no pedirá al cliente que proporcione datos ni guardará nuevos datos. UPDATE recopila la entrada del cliente y la guarda en el atributo. Si tu procedimiento debe recopilar información del cliente (p. ej., una dirección de correo, 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 de data connector se expone como un atributo de salida. Puedes hacer referencia a esto en un Condition step para ramificar según códigos de respuesta HTTP específicos, dándote control preciso sobre cómo Fin maneja diferentes escenarios de falla en lugar de confiar en una sola rama de éxito/fracaso.

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

Consejo: Consulta How to write code conditions for Fin Procedures para ejemplos de código que usan status_code en un Condition step.

Validando correcciones con Simulations

Antes de poner tu Procedure en vivo, usa Simulations para verificar la corrección:

Preview vs. Simulations — ¿cuál debo usar? Preview muestra la experiencia completa para el cliente. Usar Preview mientras tu procedimiento está activo puede exponer mensajes de paso a clientes reales. Simulations ejecutan el procedimiento en segundo plano sin salida hacia 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úe como el cliente en el escenario que falla.
Revisa el resultado de aprobado/fallado y el juicio de la IA para confirmar que la lógica es fiable.

Preguntas frecuentes

¿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 desencadenó 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 Data connector?

Los registros de respuestas del data connector se almacenan hasta 14 days por defecto. Si tu workspace tiene requisitos de seguridad de datos más estrictos, Intercom puede reducir esto a 7 days previa solicitud — contacta a nuestro Support team para habilitarlo. Accede a tus registros en Settings > Integrations > Data connectors > Logs.

¿Puedo usar Simulations para probar las respuestas del Data connector?

Sí — las Simulations ejecutan el Procedure completo incluyendo cualquier paso de Data connector, lo que las convierte en la forma más fiable de validar el comportamiento del conector antes de ponerlo en vivo.

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

Workflows se ejecutan antes de que Fin evalúe la intención del procedimiento. Si un Workflow está activo para el mismo trigger de conversación, puede enrutar la conversación antes de que Fin tenga la oportunidad de coincidir un procedure. Para solucionarlo: revisa tus workflows activos por triggers que se solapen y asegura que el bloque Let Fin Handle esté configurado correctamente en la ruta del workflow donde quieres que los procedures estén disponibles.

¿Por qué mi Procedure se transfirió a un humano inesperadamente?

Hay dos formas en que un Procedure puede transferir a un humano:

Comportamiento de escalado predeterminado — Fin escala automáticamente según su lógica incorporada: cuando un cliente pide claramente 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 independientemente de cómo esté configurado tu Procedure.
Entrega configurada — Un paso de Handoff to team que has añadido en un punto específico del Procedimiento, o directrices específicas del Procedimiento que has escrito que instruyen a Fin para entregar en un escenario particular.

Si la entrega fue inesperada, 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 Orientación de Escalada dentro de un Procedimiento?

La Orientación de Escalada no se aplica dentro de un Procedimiento por defecto: necesitas habilitarla explícitamente en el panel Guidance del Procedimiento:

Abre tu Procedimiento, 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 orientación a nivel de espacio de trabajo que quieres aplicar, incluyendo Handover and escalation.
Fin combinará la orientación seleccionada del espacio de trabajo con cualquier orientación personalizada específica del procedimiento que hayas escrito.

Nota: El comportamiento de escalada predeterminado de Fin (el cliente solicita un humano, se detecta frustración, bucle repetitivo) siempre se activa dentro de un Procedimiento independientemente de la configuración de Guidance. El panel Guidance controla únicamente tu Orientación de Escalada y Reglas de Escalada a nivel de espacio de trabajo.

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

Ambos pasos finalizan el Procedimiento, pero enrutan la conversación de forma diferente:

Handoff to team — Finaliza el Procedimiento y entrega 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).
Handoff to 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 a especialistas). El Procedimiento no se reanudará después de que el Workflow termine.

¿Se factura una entrega de Procedimiento como un Fin Outcome?

Un Procedimiento 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 entrega a un equipo, compañero o workflow mediante un paso de Handoff configurado o una orientación específica del procedimiento que hayas establecido.
En ambos casos, se te cobra $0.99 — y solo una vez por conversación, independientemente de 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 pide hablar con un humano en cualquier momento, o la conversación termina por el comportamiento de escalada predeterminado de Fin o por las reglas de escalada 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 estar agotándose el tiempo?

Sí. Los Procedimientos se ejecutan dentro de un bloque Let Fin Handle en tu Workflow, y ese bloque tiene un tiempo de inactividad por defecto. Si un cliente tarda más que eso en responder, el bloque puede cerrarse antes de que el procedimiento se complete. Para solucionarlo, abre el bloque Let Fin Handle en la configuración de tu Workflow y aumenta el tiempo de 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 enrutar una conversación hacia uno. Los dos sistemas son separados: Guidance moldea el tono y las reglas de escalada de Fin; los Procedimientos definen flujos 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 (ver "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 dentro de un procedimiento en lugar de en la orientación.

Mi condición de código no está ramificando: ¿cómo lo 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á. Así es como diagnosticarlo:

Abre la conversación en el Inbox y habilita Show conversation events (ver "Acceder al depurador de conversaciones" arriba).
En Fin's thoughts, comprueba 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.
Comprueba estos patrones comunes de acceso a datos: • Dirección de correo: inputs["user"]["email"] — devuelve la dirección de correo del cliente si está disponible, de lo contrario None • Salida del conector: usa el nombre exacto del campo del esquema de respuesta de tu conector • Atributo de la conversación: inputs["conversation"]["attribute_name"]
Prueba tu bloque de código en un intérprete de Python antes de añadirlo 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 enruta a la rama incorrecta, añade 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.

Nota: El tipo de cliente (user vs. lead) no está actualmente disponible como atributo del Procedimiento. Si necesitas ramificar por tipo de cliente, usa una condición de Type en tu Workflow antes del paso Fin en su lugar.

Solución de problemas de Fin Procedures y conectores de datos