Saltearse al contenido

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.

Chat de prueba con trazas por nodo, datos del workflow y conversación simulada

Cómo avanza

  1. Comienza en el primer nodo ejecutable conectado a Inicio.
  2. El nodo recibe el mensaje actual, metadata, memoria y resultado anterior disponible.
  3. Ejecuta su función.
  4. Si tiene una salida, continúa por esa conexión.
  5. Si tiene ramas, elige una salida identificada.
  6. Si debe esperar, persiste el estado y responde al usuario.
  7. Con el siguiente mensaje, reanuda desde el punto pendiente.
  8. 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:

  1. El usuario escribe: “Hola, mi módem no funciona, me llamo Federico”.
  2. Router conversacional elige Soporte.
  3. Pedir datos necesita nombre, DNI y problema.
  4. Reconoce nombre y problema en el mensaje inicial.
  5. Pregunta únicamente el DNI.
  6. 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

NodoCriterio
Elegir caminoValor estructurado de input, output o facts
Condición por mensajeTexto del último mensaje del usuario
Condición por inicioIniciador y mensaje/metadata proactiva
Router conversacionalIntención interpretada con IA
Router por canalCanal de la conversación
Pedir datosCompletitud y validación de campos
HTTP / CRM NEXUSÉxito o error de la operación
Aprobación humanaAprobado, 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:

Historial de ejecuciones con sesión, turno, respuesta y detalle técnico de los nodos

  • 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íntomaQué revisar
Salta un nodoConexiones, salida elegida y nodos alcanzables desde Inicio
Vuelve a preguntar un datoClave del campo, facts, historial disponible y validación
Queda esperandoModo de continuidad, datos requeridos y condición para avanzar
No vuelve a un paso esperadoSalidas conectadas del nodo y configuración de Próximo turno empieza en
Reutiliza una selección anteriorClaves configuradas en Limpiar memoria y valores vigentes del Blackboard
Toma una rama incorrectaOrden de reglas, operador, mayúsculas, ejemplos o metadata
No encuentra el contactoIdentidad del canal, facts.email, facts.phone y conexión Nexus
No se guardó el cambioEstado del botón Guardar y error de red
Se duplicó una operaciónReintentos, idempotencia de la integración y ejecución seleccionada