El Problema del Monolito
Un workflow único que hace todo — desde recibir el webhook hasta enviar la notificación, pasando por validación, transformación, base de datos y logging — es:
- Inmantenible: cambiar una validación requiere navegar entre 20 nodos.
- No reusable: la misma lógica de validación la necesitas en 3 flujos distintos.
- Frágil: un error en un nodo secundario puede derribar todo el flujo.
Principio de Arquitectura
"Divide y vencerás". Cada subworkflow debe hacer una sola cosa y hacerla bien. Esta es la base de los microservicios aplicados a automatizaciones.
El Nodo Execute Workflow
El nodo Execute Workflow permite a un flujo principal llamar a otro flujo (subworkflow) como si fuera un nodo más. El subworkflow recibe parámetros de entrada y devuelve un resultado JSON.
// Flujo Principal
Webhook trigger → Code Node → Execute Workflow (sub_validador) → IF → Telegram
└─ Parámetros: { "json_input": $json }
// Subworkflow "validador" (Workflow independiente)
Execute Workflow Trigger ─ parámetro configurado ─→ Code Node (validación)
─→ Return { "validez": true, "errores": [] }
| Ventaja | Explicación |
|---|---|
| Reutilización | El mismo subworkflow "validador" puede llamarse desde 5 flujos distintos. |
| Test independiente | Puedes ejecutar solo el subworkflow y probarlo aisladamente. |
| Error aislado | Si el subworkflow falla, el flujo principal recibe el error y puede reaccionar. |
| Mantenimiento | Corregir una validación en un solo lugar afecta todos los flujos. |
Creando un Subworkflow desde Cero
Paso a paso
- Crear nuevo workflow: "+" en el dashboard, nombralo
sub_validador_leadcomo sub. - Añadir Execute Workflow Trigger: este nodo especial recibe los parámetros del flujo padre. No uses Webhook Trigger — eso solo para flujos disparados desde afuera.
- Define los parámetros de entrada: en el trigger, añade un campo con nombre y tipo (ej.
lead_json: Object). - Construye la lógica de validación (nodo Code o IF según sea necesario).
- Termina con el nodo Return: añade los campos que quieres devolver al flujo principal (ej.
"valido" → booleano,"mensaje_error" → string). - Guarda y publica el subworkflow.
- En el flujo principal: añade Execute Workflow y selecciona "sub_validador_lead".
Dato crítico
El nodo de entrada del subworkflow solo puede tener un único branch de entrada y salida. Si intentas convertir un grupo que tiene ramas condicionales (IF, Switch) no funcionará — esos casos van mejor con el node Split In Batches.
Comparativa: Subworkflow, Split In Batches, Loop
| Técnica | Propósito | Cuando usar |
|---|---|---|
| Execute Workflow | Llamar otro flujo como función | Reutilizar lógica, separar responsabilidades, testar aislado |
| Split In Batches | Procesar muchos items en lotes pequeños | 100+ items, APIs con rate limiting, procesamiento por lotes |
| Loop Node | Repetir hasta cumplir condición | Escenarios con condición dinámica: "volver a buscar hasta que el estado sea 'completado'" |
Checklist del Módulo 10
Desafío de Arquitecto
Micro Subworkflow Validador
Crea un patrón modular de validación que puedas usar en cualquier proyecto futuro:
- Crea un subworkflow llamado
sub_validadorque reciba un parámetrolead(tipo Object). - La validación debe comprobar: que el email tenga formato correcto (contiene
@y.), y que el camponombreno esté vacío. - Configura el Return con dos campos:
"valido"(boolean) y"errores"(array de strings). - Crea un flujo principal que use este subworkflow: recibe un webhook con JSON de lead, lo pasa al validador, y si es válido,inserta en SQL. Si no, envía un email de corrección al lead.
- Verifica que puedes probar el subworkflow en aislamiento desde el dashboard de n8n sin el flujo principal.