Buenas prácticas de Sub Workflow

Un Sub Workflow ejecuta otro workflow como un paso dentro del flujo actual. Bien usado, convierte flujos gigantes e imposibles de mantener en piezas pequeñas, reutilizables y fáciles de probar. Mal usado, esconde lógica y crea dependencias difíciles de seguir. Esta guía te ayuda a decidir cuándo conviene y cómo hacerlo bien.

Cuándo usarlo

• Reutilizar lógica: una misma secuencia (facturar, notificar, calcular impuestos) que se repite en varios flujos. La escribes una vez y la llamas desde donde haga falta.
• Dividir un flujo grande: cuando un workflow tiene decenas de nodos, extraé bloques con sentido propio (“Onboarding”, “Cobro”, “Envío”) a sub-workflows. El flujo principal queda legible.
• Procesar en lote: con el modo parallel, un array de entrada lanza una instancia por elemento (p. ej. procesar 50 pedidos en paralelo).
• Separar por responsabilidad o equipo: cada sub-workflow puede tener su propio dueño, su historial y sus versiones.
• Orquestar procesos largos: con el modo async lanzás un sub-proceso y seguís sin esperarlo (fire & forget).

Cuándo NO usarlo

• Para un solo nodo o dos: si el “sub-proceso” son dos pasos, ponelos en el mismo flujo. Un Sub Workflow añade una capa de indirección que no compensa.
• Si necesitás el resultado inmediato y el hijo es lento: en sync el padre espera. Para tareas largas que no bloqueen, usá async o la cola.
• Como sustituto de un bucle simple: para recorrer un array a menudo alcanza con Iterator; reservá parallel para cuando cada elemento dispara un flujo real.
• Cuando crearías un ciclo: si A llama a B y B termina llamando a A, tenés recursión infinita. El editor te avisa (ver más abajo), pero el diseño hay que corregirlo.

Elegir el modo de ejecución

Modo	Qué hace	Cuándo usarlo
sync	El padre espera el resultado del hijo antes de continuar.	Necesitás el dato de salida del sub-workflow en el paso siguiente.
async	Lanza el hijo y continúa sin esperar (fire & forget).	Tareas que no bloquean: enviar un email, registrar un evento, avisar a un sistema.
parallel	Si el input es un array, lanza una instancia por elemento (máx. 5 simultáneas por defecto).	Procesamiento en lote donde cada elemento es un flujo completo.

Precaución

En sync, el timeout_ms limita la espera. Para sub-workflows que pueden tardar, subí el timeout o pasá a async; si no, el padre puede cortar antes de tiempo.

Pasar datos y estado

• input_data: lo que le mandás al hijo como entrada. Acepta JSON o variables dinámicas ({{...}}). Si lo dejás vacío, el hijo recibe el data de entrada del nodo.
• pass_state (por defecto activado): hereda el workflowState del padre para compartir contexto entre flujos. Desactivalo si querés que el hijo arranque “limpio”, sin heredar el estado del padre.

Recomendación: pasá al hijo solo lo que necesita, no todo el estado. Un contrato de entrada explícito (un input_data con los campos justos) hace que el sub-workflow sea reutilizable y fácil de probar por separado.

Demo: dividir un onboarding en sub-workflows

Un alta de cliente que hace de todo (facturar, cobrar, avisar a contabilidad, dar la bienvenida) es un candidato perfecto para sub-workflows.

1. Creá los sub-workflows hoja primero: “Enviar bienvenida” y “Notificar contabilidad”. Son flujos normales, sin nada especial.

2. Encadená los intermedios: “Cobrar” llama (Sub Workflow) a “Notificar contabilidad”; “Facturar cliente” llama a “Cobrar”.

3. Armá el flujo principal “Onboarding cliente”: desde el Start, un Sub Workflow a “Facturar cliente” (sync, porque el alta depende de que se facture) y otro a “Enviar bienvenida” (async, no hace falta esperarlo).

4. Verificá el árbol desde el listado de workflows: cada padre muestra un chevron que despliega los sub-workflows que invoca, sin abrir el editor.

Resultado: “Onboarding cliente” → Facturar cliente → Cobrar → Notificar contabilidad, más Enviar bienvenida en paralelo. Cada pieza se prueba, versiona y reutiliza por separado.

Evitá la recursión

El error más común con sub-workflows es cerrar un ciclo: A llama a B, B a C, y C vuelve a llamar a A. Eso produce ejecuciones infinitas.

Al elegir el workflow hijo, el editor detecta el ciclo —directo o indirecto— y muestra el camino completo. Si ves ese aviso rojo, cambiá el diseño (normalmente el último eslabón no debería volver al primero).

Consejo

Cuando no hay ciclo, el panel te muestra la cadena de llamadas aguas abajo (p. ej. Facturar → Cobrar → Notificar), útil para entender el alcance de lo que estás llamando.

Y si un ciclo se cuela en ejecución

Aunque el editor no lo haya avisado (p. ej. un workflow_id armado dinámicamente), en ejecución hay una red de seguridad que detecta la recursión, aplica un tope de profundidad y aborta la ejecución en segundos — sin colgar la plataforma ni reiniciar procesos.

Gestionarlo desde el editor

• El nodo en el lienzo muestra el workflow hijo, el modo y un enlace ↗ para abrirlo en una pestaña nueva: no hace falta memorizar a qué apunta cada Sub Workflow.
• El listado muestra el árbol de dependencias con el chevron, así detectás de un vistazo qué flujos dependen de cuáles.

Checklist

• El sub-workflow tiene una responsabilidad clara (un “verbo”: facturar, cobrar, notificar).
• Elegiste el modo correcto: sync si necesitás el resultado, async si no, parallel para lotes.
• Pasás en input_data solo lo necesario, no todo el estado.
• Ajustaste el timeout_ms si el hijo puede tardar (en sync).
• No hay ciclos: el panel no muestra aviso de recursión.
• Nombraste los flujos de forma que el árbol del listado se entienda solo.

Nodos relacionados

• SubWorkflow (referencia) - parámetros, salidas y notas del nodo
• Iterator - recorrer arrays sin lanzar un flujo completo por elemento
• Decision - elegir qué sub-workflow ejecutar