Automatizaciones
Pruebas y ejecuciones
Prueba tu automatización de forma segura, mira cada bloque ejecutarse en vivo, inspecciona cada resultado y reintenta desde el paso exacto que falló
Probar una automatización es como un ensayo general: el mismo escenario, el mismo guion, y tú estás en el público viendo cada movimiento — para que la noche del estreno no haya sorpresas. Test Run en la barra de herramientas del lienzo inicia una, y lo que pasa después depende de tu disparador.
Iniciar una prueba
| Disparador | Qué hace Test Run |
|---|---|
| Manual | Abre Ejecutar con datos de entrada, completado con los datos de demo de la automatización. Cambia cualquier valor solo para esta ejecución — para conservar un cambio, guárdalo como datos de demo en la configuración del disparador. |
| Disparador de app | Abre un selector. Con datos de demo guardados, Usar los datos de demo aparece primero: muestra los datos, editables, y Ejecutar con estos datos empieza de inmediato. La segunda opción es Esperar un evento real (la ejecución empieza en el momento en que la app envía uno) — o, para las apps que Nirvai revisa con un temporizador, Traer el evento más reciente (trae el último de inmediato). Sin datos de demo, esa segunda opción aparece primero. |
| Webhook | Espera la próxima solicitud enviada a tu dirección de webhook y se ejecuta con ella. Aquí los datos de demo llenan el selector de variables; no reemplazan la solicitud real en una prueba. |
| Programado | Se ejecuta de inmediato, tal como lo haría el temporizador — los pasos que leen datos del disparador reciben los datos de demo |
Capturar un evento real mientras pruebas un disparador de app también lo guarda como datos de demo, así tu próxima prueba puede reproducirlo al instante.
La vista en vivo
El lienzo se convierte en un escenario: los bloques se iluminan uno tras otro mientras se ejecutan, las ramas no tomadas se atenúan con la razón ("omitido: la condición fue verdadera"), y los bucles se animan mientras corren sus pasadas. Puedes detener una ejecución en curso desde la barra de herramientas. Mira cómo se despliega la ejecución de abajo y luego haz clic en cualquier bloque para inspeccionar su resultado:
12 elementos → 3 conservados
Inspeccionar un paso
Haz clic en cualquier bloque terminado para ver exactamente qué hizo — cada tipo cuenta su propia historia:
| Bloque | Qué ves |
|---|---|
| Filtro | Cuántos elementos entraron, cuántos sobrevivieron, y los sobrevivientes |
| Condición / Switch | El veredicto y qué camino tomó la ejecución |
| Herramienta | La herramienta, los campos con los que se ejecutó, y cualquier advertencia de "valor que no resolvió a nada" |
| Base de datos | La acción, la base de datos, y las filas exactas afectadas |
| Cualquier bloque que maneje archivos | Una nota por archivo — p. ej. "invoice.pdf: attached (96 KB)" o "photo.jpg: temporary public link created (expires in 7 days), converted to JPEG" (Archivos en automatizaciones) |
| Código | El resultado y todo lo que el código imprimió |
| For Each / Loop | Resultados pasada por pasada con un paginador |
| Agente | La conversación completa y su respuesta |
Cada paso también muestra qué recibió como entrada, y cada lista puede alternar entre una tabla y la vista sin procesar. Los bloques gratuitos llevan un chip de "Sin costo de créditos".
Reintentar desde un paso
Cuando una ejecución falla, no empiezas de cero. Reintentar desde el paso fallido (o "Reintentar desde este paso" en cualquier bloque) inicia una nueva ejecución que reutiliza todo lo anterior — los pasos de agente previos no se vuelven a ejecutar ni a cobrar — y re-ejecuta solo desde el fallo en adelante. Primero corrige la configuración del bloque, y luego reintenta.
Este es el ciclo de depuración más barato que existe: un paso de investigación costoso que tuvo éxito queda pagado una sola vez, mientras tú corriges y reintentas el paso barato que se rompió después.
Activar y monitorear
Cuando una prueba se vea bien, activa el interruptor de activación. A partir de entonces:
- Las ejecuciones aparecen en el historial de ejecuciones de la automatización, y cada una abre la misma vista en vivo e inspección de pasos.
- Estados de ejecución: completada, fallida (con el paso que falló marcado), detenida (la detuviste tú), en progreso.
- Los eventos que una app envió pero que un filtro descartó no crean ejecuciones — eso es a propósito y no cuesta nada.
Solución de problemas
| Problema | Solución |
|---|---|
| La salida de un paso está vacía | Abre el paso y busca la advertencia de "no resolvió a nada" — una {{variable}} no encontró su valor. Revisa su ruta en Datos entre pasos. |
| Los bloques después de un fallo muestran "omitido" | Esa es la regla: cuando un paso falla, todo lo que depende de él se omite y la ejecución se marca como fallida. Corrige el paso y luego usa Reintentar desde el paso fallido. |
| "Esperar un evento real" nunca empieza | Provoca el evento en la otra app (crea el negocio, envía el formulario). La ventana espera una entrega real. |
| Una ejecución antigua muestra menos detalle que las nuevas | Las ejecuciones más antiguas se registraron antes de que existieran las vistas detalladas por bloque — las nuevas muestran todo. |
Qué sigue
Protege tu construcción funcional con Versiones y seguridad.