> For the complete documentation index, see [llms.txt](https://academy.gopersonal.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://academy.gopersonal.ai/guia-de-usuario/journeys/probar-journey.md). # 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. {% hint style="danger" %} **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. {% endhint %} ## 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. {% hint style="warning" %} 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. {% endhint %} ## 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. {% hint style="info" %} 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. {% endhint %} ## 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.