Ejecución y pruebas
Un workflow se ejecuta siguiendo las conexiones desde Inicio. En cada turno recupera el estado de la conversación, la memoria acumulada y el nodo donde quedó esperando.

Cómo avanza
- Comienza en el primer nodo ejecutable conectado a Inicio.
- El nodo recibe el mensaje actual, metadata, memoria y resultado anterior disponible.
- Ejecuta su función.
- Si tiene una salida, continúa por esa conexión.
- Si tiene ramas, elige una salida identificada.
- Si debe esperar, persiste el estado y responde al usuario.
- Con el siguiente mensaje, reanuda desde el punto pendiente.
- Finaliza al llegar al cierre del camino o al nodo de salida configurado.
Varios nodos pueden ejecutarse en el mismo turno. Por ejemplo: Router conversacional → Pedir datos ya completos → Crear contacto → Mensaje fijo. En cambio, si falta un dato, Pedir datos responde, guarda lo que tenga y espera.
Después de ejecutar un nodo, el runtime también aplica las acciones configuradas en Al finalizar este paso. Si el nodo limpia memoria, esos facts dejan de contarse como valores capturados para los pasos siguientes. Si configura Próximo turno empieza en, esa reanudación solo se usa cuando el nodo no tiene una salida conectada por la que continuar.
Datos ya informados
La captura no comienza desde cero cada vez que cambia de nodo. Pedir datos revisa facts y el contenido previo de la conversación.
Ejemplo:
- El usuario escribe: “Hola, mi módem no funciona, me llamo Federico”.
- Router conversacional elige Soporte.
- Pedir datos necesita nombre, DNI y problema.
- Reconoce nombre y problema en el mensaje inicial.
- Pregunta únicamente el DNI.
- Guarda los tres valores y continúa por Completo.
Probá siempre usuarios que entregan un campo, varios campos juntos, corrigen un valor o responden con un formato inválido.
Si necesitás que el usuario vuelva a elegir un profesional, fecha, sede u otro dato ya guardado, limpiá las claves correspondientes al cerrar la rama anterior. La clave puede seguir apareciendo en el editor porque está definida por el workflow, pero en esa ejecución ya no tiene un valor capturado hasta que el usuario lo informe de nuevo.
Nodos que esperan
Pueden detener temporalmente el recorrido:
- El bot responde en modo Esperar respuesta;
- Mensaje fijo cuando envía una pregunta y espera;
- Pedir datos mientras falten campos;
- Enviar WhatsApp Flow mientras espera el formulario;
- Aprobación humana hasta aprobar, rechazar o vencer.
En un nodo de IA configurado para esperar, definí datos requeridos y una condición para avanzar. La condición debe describir el resultado, no una frase exacta: “avanzar cuando estén nombre, teléfono y zona” es mejor que “avanzar si dice todos los datos”.
Cómo se eligen las ramas
| Nodo | Criterio |
|---|---|
| Elegir camino | Valor estructurado de input, output o facts |
| Condición por mensaje | Texto del último mensaje del usuario |
| Condición por inicio | Iniciador y mensaje/metadata proactiva |
| Router conversacional | Intención interpretada con IA |
| Router por canal | Canal de la conversación |
| Pedir datos | Completitud y validación de campos |
| HTTP / CRM NEXUS | Éxito o error de la operación |
| Aprobación humana | Aprobado, Rechazado o Vencido |
Conectá el fallback aunque esperes que nunca ocurra. Un canal nuevo, metadata ausente o frase ambigua pueden activar ese camino.
Simular Condición por inicio
Abrí un nodo Condición por inicio y desplegá Probar el ruteo. Esta prueba es aislada: no ejecuta nodos, no consume la conversación real y no guarda mensajes.
Podés simular:
- quién inició la conversación;
- si existe mensaje proactivo;
- texto enviado por el agente;
- plantilla;
- campaña;
- automatización;
- tipo de mensaje;
- canal.
El panel muestra la salida seleccionada. Probá al menos un caso configurado, otro mensaje proactivo, una conversación iniciada por el usuario y origen desconocido.
Probar como conversación
En el encabezado cambiá de Editar a Probar. El panel permite conversar con el workflow antes de activarlo.
Durante la prueba revisá:
- mensajes del usuario y respuestas;
- nodo que está ejecutándose;
- nodos completados y fallidos;
- duración de cada paso;
- rama elegida;
- tools usadas;
- variables y resultado;
- logs técnicos y respuesta final.
Una prueba satisfactoria debe validar tanto el texto visible como las acciones internas. No alcanza con recibir una respuesta correcta si se creó dos veces un ticket o se guardó un ID equivocado.
Try en nodos individuales
Los nodos Code y Google Sheets incluyen Try en su panel de configuración. Try ejecuta solamente el nodo seleccionado, muestra su respuesta y conserva una muestra para ofrecer sus campos como variables en los pasos posteriores.
En Google Sheets, Obtener datos es una lectura. Guardar, Editar y Borrar modifican el documento real y muestran una confirmación antes de continuar. No uses una hoja productiva para experimentar con operaciones mutantes; prepará una pestaña de prueba y verificá los criterios antes de confirmar.
Usá el Blackboard para confirmar el orden y el estado de los datos guardados. Los facts capturados, los resultados por nodo y los valores globales se muestran como registros de memoria; cuando un fact fue limpiado no debería verse como valor vigente, aunque el selector de variables pueda seguir ofreciéndolo como destino o placeholder definido por el workflow.
Historial de ejecuciones
Desde el menú de tres puntos elegí Ejecuciones. El historial ayuda a diagnosticar conversaciones reales o pruebas anteriores mediante:

- estado general;
- nodo actual o último nodo;
- tiempos;
- errores;
- input y output por nodo;
- decisiones de routers;
- requests y respuestas permitidas;
- estado pendiente de aprobación.
Evitá copiar en tickets de soporte contenido personal o credenciales que no sean necesarias para diagnosticar.
Escenarios guardados
En el menú de tres puntos elegí Validar workflow. Un escenario guarda un input y resultados esperados para repetirlos después de cambiar nodos, conexiones o prompts.
Definí:
- nombre representativo;
- mensaje del usuario;
- rama o intención esperada;
- valores esperados en
facts.
Cada expectativa es opcional, pero el escenario necesita al menos una validación. Configuración avanzada permite editar input y expectativas como JSON cuando necesitás metadata, contexto o casos especiales.
Al ejecutar, cada condición aparece como Correcta o No coincide, con el valor esperado y el obtenido. Podés correr un escenario o usar Ejecutar todos como prueba de regresión.
Matriz mínima antes de activar
- Camino principal completo.
- Usuario que entrega todos los datos juntos.
- Usuario que entrega solo una parte.
- Dato inválido y posterior corrección.
- Cambio de intención.
- Condición sin coincidencia.
- Canal no configurado.
- Inicio por agente, inicio por usuario y origen desconocido.
- Error de HTTP o CRM NEXUS.
- Registro externo reintentado sin duplicarse cuando aplique idempotencia.
- Aprobación, rechazo y vencimiento.
- Derivación humana.
- Respuesta final y variables importantes.
Diagnóstico rápido
| Síntoma | Qué revisar |
|---|---|
| Salta un nodo | Conexiones, salida elegida y nodos alcanzables desde Inicio |
| Vuelve a preguntar un dato | Clave del campo, facts, historial disponible y validación |
| Queda esperando | Modo de continuidad, datos requeridos y condición para avanzar |
| No vuelve a un paso esperado | Salidas conectadas del nodo y configuración de Próximo turno empieza en |
| Reutiliza una selección anterior | Claves configuradas en Limpiar memoria y valores vigentes del Blackboard |
| Toma una rama incorrecta | Orden de reglas, operador, mayúsculas, ejemplos o metadata |
| No encuentra el contacto | Identidad del canal, facts.email, facts.phone y conexión Nexus |
| No se guardó el cambio | Estado del botón Guardar y error de red |
| Se duplicó una operación | Reintentos, idempotencia de la integración y ejecución seleccionada |