Probar un journey

Antes de activar un journey conviene verificarlo de punta a punta: comprobar que el trigger entrega el contexto esperado, que las condiciones evalúan como se pensó, que los mensajes se arman bien con las variables dinámicas y que los scripts y llamadas a API devuelven lo que corresponde.

El modo prueba permite ejecutar el journey con un customer real del proyecto y seguir paso a paso qué hace el motor en cada nodo, viendo el detalle de cada decisión.

La prueba es real. Los emails y las notificaciones push se envían efectivamente al customer elegido, y los scripts y las llamadas a API se ejecutan de verdad, con los mismos efectos que en producción.

Conviene usar un customer propio o de prueba, y revisar el journey antes de ejecutarlo si incluye llamadas a sistemas externos que generen escrituras.

Cómo iniciar una prueba

Desde el editor de workflow, presionando Probar journey. Se ejecuta la versión guardada del journey, aunque esté en borrador y todavía no se haya activado, por lo que conviene guardar los cambios antes de probar.

Configuración de la prueba

Customer: el cliente con el que se ejecuta el journey. Se busca por email, nombre o id, y solo se pueden elegir customers conocidos del proyecto. Todas las notificaciones del journey se envían a este customer.

Interacción que dispara: permite elegir una de las interacciones recientes del customer, que entra al journey como context.item y context.itemData, igual que en producción. También puede ejecutarse sin item, disparando únicamente con el customer.

Acelerar esperas: los componentes de espera por tiempo se saltean y los de "esperar hasta" siguen enseguida, de modo que un journey con demoras de días se recorre completo en el momento. Queda registrado cuánto hubiera esperado realmente cada paso. Si se desactiva, la prueba respeta los tiempos reales del journey.

Seguir la ejecución: el panel salta automáticamente al paso que se está ejecutando, para no tener que buscarlo en el canvas.

Contexto inicial adicional (JSON): permite inyectar datos extra al contexto de la ejecución antes del primer paso. Es útil para probar ramas que dependen de valores que normalmente llegan desde el trigger o desde un sistema externo. Debe ser un objeto JSON válido.

Si el customer elegido ya tiene una ejecución en curso de ese journey, la plataforma lo advierte antes de ejecutar:

• Si el journey está configurado como una vez por customer, esa ejecución se cancela al iniciar la prueba.

• Si no, la prueba inicia una segunda ejecución en paralelo.

Seguimiento de la ejecución

Al ejecutar la prueba, el editor entra en modo prueba: el canvas queda en modo lectura y se muestra una barra superior con el customer elegido, el item que disparó la ejecución, si las esperas están aceleradas o son reales, y el estado actual —iniciando, ejecutando un paso, esperando, completado o con error—.

Sobre cada nodo del canvas aparece un resumen de una línea con lo que ocurrió en ese paso y cuánto tardó. Por ejemplo, "Verdadero → Sí" en una condición, "Enviado a …" en una notificación, "Espera de 30 minutos omitida" en un delay acelerado, o "Descartado" cuando el mensaje no se envió. Los estados se distinguen por color: ejecutado, descartado y error.

Detalle de cada paso

Al seleccionar un nodo —en el canvas o desde el panel de Recorrido— se abre el detalle de lo que pasó en ese paso. La información depende del tipo de componente:

• Trigger: el origen del disparo, el customer y el contexto inicial que ve el primer paso.

• Condiciones: cada campo evaluado con su operador, el valor esperado y el valor real del customer, además de la rama que se tomó. Es la forma más directa de entender por qué una ejecución se fue por un camino y no por otro.

• A/B testing: la variante asignada y su ratio.

• Esperas: el tiempo configurado, y en caso de haberse acelerado, cuándo hubiera retomado en producción.

• Canales: el destinatario, el asunto, el proveedor y el preview del mensaje ya templateado, con las variables dinámicas resueltas. Si el mensaje no se envió, se muestra el motivo del descarte.

• Acciones – Script: el contexto con el que se invocó la función, el objeto devuelto, lo que el script escribió en la consola y el contexto resultante luego del merge.

• Acciones – Invocar API: el request, el status, la respuesta recibida y en qué clave del contexto quedó guardada.

También puede consultarse el contexto acumulado en cada paso, para ver cómo se fue enriqueciendo a lo largo del recorrido.

Si el journey usa context.itemData y este no aparece, suele ser porque el item elegido no está en el catálogo del proyecto y el motor no pudo cargarlo. La plataforma lo indica como pista en el detalle del paso.

Repetir, historial y salida

Desde la barra del modo prueba es posible:

• Repetir: volver a ejecutar con el mismo customer y la misma interacción, útil para validar un cambio recién hecho.

• Nuevo test: abrir nuevamente la configuración para probar con otro customer, otra interacción u otras opciones.

• Historial: ver las pruebas anteriores de ese journey, con su customer, fecha y estado, y volver a abrir cualquiera de ellas para revisar su recorrido.

• Salir del modo prueba: volver al editor normal para seguir trabajando sobre el workflow.