Subescenarios: dividir y reutilizar automatizaciones
Nota de alcance: reconstrucción editorial basada en la documentación oficial, capturada el 2026-05-16. Describe esa versión histórica; no acredita funciones, límites ni disponibilidad actuales. Consulta la fuente vigente antes de configurar un flujo nuevo.
Un escenario principal puede llamar a otros escenarios para delegar tareas concretas. La captura utiliza Scenarios > Call a scenario en el principal y Scenarios > Start scenario en el subescenario. Cuando hace falta devolver datos, utiliza Scenarios > Return output.
Esta división resulta útil para centralizar una consulta de clientes, una actualización de inventario o una notificación que varios flujos necesitan.
Elegir el modo de llamada
| Modo | Qué hace el escenario principal | Uso habitual |
|---|---|---|
| Síncrono | Espera a que el subescenario devuelva el resultado | Decidir el siguiente paso a partir del resultado |
| Asíncrono | Continúa sin esperar las salidas | Delegar una tarea independiente |
El ajuste descrito es Wait for the scenario to finish: Yes para esperar y No para continuar. No mapees salidas del subescenario como si ya estuvieran disponibles cuando eliges el modo asíncrono.
Preparación
Define primero las entradas y, si las necesitas, las salidas. La versión documentada requería que el subescenario estuviera activo y programado on demand.
La captura limitaba las llamadas de la aplicación Scenarios a escenarios del mismo equipo. Para otros equipos u organizaciones remitía a Make > Run a scenario o a webhooks. No asumas que cambiar de mecanismo concede acceso: verifica permisos y autenticación.
Ejemplo síncrono: registrar participantes
- En el escenario principal, conecta Jotform > Watch for Submissions al formulario que recoge nombre y correo.
- Añade Scenarios > Call a scenario y crea o selecciona el subescenario.
- Define las entradas
nameyemail, y las salidasstatus,nameyemail. - En el subescenario, mapea el correo de Start scenario a una búsqueda con Google Sheets > Search Rows.
- Comprueba que la búsqueda permita continuar cuando no encuentre registros. Sin una salida utilizable en ese caso, el filtro posterior no resolverá por sí solo la ausencia.
- Usa un Router con rutas excluyentes: cero resultados y más de cero resultados.
- En la primera ruta, añade la fila y devuelve el estado «Participante añadido». En la segunda, devuelve «Participante existente» sin volver a añadirlo.
- Activa el subescenario, déjalo bajo demanda y guarda.
- En el principal, mapea las entradas y establece la espera en Yes.
- Añade un filtro antes de Gmail > Send an email para enviar la bienvenida únicamente cuando el estado sea «Participante añadido».
Prueba un correo nuevo y repite el mismo envío. El segundo no debe generar otra fila ni otra bienvenida. Esta búsqueda previa no equivale a una garantía contra duplicados si dos solicitudes simultáneas consultan antes de que se escriba la fila.
Variante asíncrona
Si solo necesitas delegar el almacenamiento, define las entradas, añade la acción de escritura y no dependas de una respuesta inmediata. La guía permite retirar Return output cuando no se va a devolver información y establece la espera en No en el principal.
Cualquier paso posterior debe usar los datos que el principal ya tiene. Si necesitas confirmar que la escritura se completó antes de enviar un correo, utiliza el modo síncrono.
Mantener una lógica compartida
Agrupa tareas con una responsabilidad clara: actualizar inventario, crear un contacto o asociarlo a una campaña. Evita convertir cada módulo trivial en un subescenario. Antes de cambiar un contrato compartido, comprueba sus llamadores y prueba las rutas de éxito y de error. Esta reconstrucción no hace afirmaciones sobre el coste actual de las llamadas.