Módulo 2: Branching y Decisiones Avanzadas

Sub-Workflows para Manejar Complejidad

Siguiente →

Descripción de la cápsula

Hasta ahora todos tus workflows han sido monolíticos — un trigger, todo el procesamiento, y los nodos finales, en un solo canvas. Funciona perfecto para workflows pequeños. Pero cuando crecen — sea por cantidad de nodos, por lógica compleja, o por reutilización — un solo canvas se vuelve insostenible.

Sub-workflows son la solución: divides tu workflow en piezas más pequeñas, cada una con su propio canvas, y las conectas con el nodo Execute Workflow. Es el equivalente a "funciones" en programación — extraes lógica reutilizable y compleja a su propia "función" (otro workflow).

En esta cápsula vas a aprender cuándo extraer a sub-workflows, cómo configurar Execute Workflow node, cómo pasar datos entre workflows, los 3 patrones principales (utility, branch extractor, multi-tenant), y las trampas de organización al usar muchos sub-workflows.

Lo que vas a aprender

Al terminar esta cápsula serás capaz de:

  • ✅ Identificar cuándo extraer a sub-workflow es la mejor decisión
  • ✅ Crear y configurar un sub-workflow llamable
  • ✅ Llamarlo desde otro workflow con Execute Workflow
  • ✅ Pasar datos correctamente entre workflows
  • ✅ Aplicar 3 patrones comunes de sub-workflows
  • ✅ Organizar tu account de n8n con sub-workflows sin caos

Cuándo extraer a sub-workflow

Criterio 1: Reutilización

Tienes lógica que se repite en 2+ workflows. Ejemplo: "validar formato de email + verificar dominio" se necesita en 3 workflows.

Solución: crear [UTIL] validate-email como sub-workflow. Los 3 workflows lo llaman.

Criterio 2: Complejidad de una rama

Una rama de tu Switch tiene 8+ nodos. El canvas principal pierde claridad.

Solución: extraer esa rama a [PROC] manejar-enterprise y llamarlo desde el Switch.

Criterio 3: Equipos / responsabilidades distintas

Un workflow es mantenido por 2 personas distintas según la sección. Cada uno responsable de una parte.

Solución: separar en sub-workflows con dueños claros.

Criterio 4: Testing independiente

Quieres testear la lógica X aisladamente sin disparar todo el workflow.

Solución: extraer X a sub-workflow que puedes ejecutar con datos de prueba.

Criterio 5: Versionamiento independiente

Cierta lógica cambia frecuentemente, otra es estable. Quieres tocar solo la parte cambiante.

Solución: sub-workflows separan los ciclos de cambio.

Cuándo NO extraer

  • Workflow simple (<10 nodos) — no hay complejidad para justificar
  • Lógica de uso único — si solo se usa en este lugar, sub-workflow es overhead
  • Performance crítica — Execute Workflow agrega latencia microscópica (raramente importa, pero existe)
  • Cuando el sub-workflow sería casi vacío — 1-2 nodos no justifica un workflow propio

Crear un sub-workflow llamable

Paso A: Crear el workflow

  1. Workflows → + Add workflow
  2. Nombre con convención (ver más abajo)
  3. Crear

Paso B: Trigger especial

El primer nodo NO es Webhook ni Schedule — es Execute Workflow Trigger (también llamado When Executed by Another Workflow).

  1. Agregar primer nodo: busca Execute Workflow → elige Trigger (no Action)
  2. Configurar el input schema opcional — qué campos espera recibir

Paso C: Lógica del sub-workflow

Después del trigger, agrega los nodos que hacen el procesamiento.

Paso D: Output

El último nodo debería producir el output que devuelve al workflow padre. Si no hay output explícito, el padre recibe lo que sea que tenga el último nodo.

Paso E: Save y activar (?)

  • Save siempre
  • Activate: depende. Para sub-workflows llamados sincrónicamente, no necesita estar activo — Execute Workflow node puede llamarlo de cualquier modo. Para llamadas asíncronas o como Error Workflow, sí debe estar activo.

Llamar a un sub-workflow

En el workflow padre

  1. Agregar nodo Execute Workflow (Action, no Trigger)
  2. Workflow: elige el sub-workflow del dropdown
  3. Pass Data: elige qué datos pasar:
    • All input items (default — pasa todos los items que llegaron al nodo)
    • Specified fields (pasa solo campos específicos)
  4. Save

Cómo se ejecuta

Cuando el workflow padre llega a Execute Workflow:

  1. Pausa el workflow padre
  2. Ejecuta el sub-workflow con los datos del input
  3. Cuando termina, devuelve los items del último nodo del sub-workflow
  4. Reanuda el workflow padre con esos datos

3 patrones principales

Patrón 1: Utility workflows (reusables)

Propósito: lógica que se usa en múltiples workflows.

Ejemplos:

  • [UTIL] validate-email: recibe {email}, devuelve {is_valid, reason}
  • [UTIL] enrich-with-clearbit: recibe {email}, devuelve datos enriquecidos de la persona
  • [UTIL] check-spam-domain: recibe {email}, devuelve {is_spam: true|false}

Convención de nombre: [UTIL] prefix para identificarlos rápido en la lista.

Patrón 2: Branch extractors (extraer ramas complejas)

Propósito: sacar una rama compleja del Switch principal.

Ejemplos:

  • [BRANCH-PROY-X] manejar-lead-enterprise: lógica de 15 nodos para procesar enterprise
  • [BRANCH-PROY-X] manejar-lead-trial: lógica equivalente para trial

Convención: prefijo [BRANCH] + nombre del proyecto/workflow padre.

Patrón 3: Multi-tenant / per-client logic

Propósito: mismo workflow base, lógica específica por cliente/inquilino.

Ejemplos:

  • [CLIENT-ACME] custom-validation: validaciones específicas de Acme
  • [CLIENT-BETA] custom-validation: equivalente de Beta

Workflow padre: decide qué sub-workflow llamar según el cliente:

[Switch sobre client]
├─→ "acme" → Execute Workflow [CLIENT-ACME] custom-validation
├─→ "beta" → Execute Workflow [CLIENT-BETA] custom-validation
└─→ default → Execute Workflow [CLIENT-DEFAULT] custom-validation

Pasar datos: el contrato implícito

Cuando el padre llama al sub-workflow, pasa items JSON. El sub-workflow opera sobre esos items, los modifica/procesa, y devuelve items al padre.

Buena práctica: documentar el "contrato"

En el primer nodo (Execute Workflow Trigger) del sub-workflow, agrega un Sticky Note con:

INPUT esperado:
{
  email: string (required)
  name: string (required)
  amount: number (optional, default 0)
}

OUTPUT devuelto:
{
  ...input,
  is_valid: boolean,
  invalid_reason: string,
  category: string
}

Esto es el contrato del sub-workflow. Quien lo llama sabe qué pasar y qué esperar.

Si cambias el contrato

Si cambias campos de input/output del sub-workflow:

  • Todos los callers se afectan
  • Si no actualizas los callers, algo se rompe

Implicación: los contratos deberían ser estables. Cambiarlos requiere coordinación.

Organización: sin caos

Si extraes muchas cosas a sub-workflows, tu lista en n8n puede tener 50+ workflows. Necesitas organización.

Convención de nombres

Prefijos por tipo:

PrefijoSignificaEjemplo
[PROY-XYZ]Workflow principal de un proyecto[PROY-M07] Cotizaciones
[UTIL]Utility reutilizable[UTIL] validate-email
[BRANCH]Rama extraída de otro workflow[BRANCH-Cotizaciones] manejar-enterprise
[GUARDIAN]Error Workflow[GUARDIAN] Error Notifier
[CLIENT-X]Específico de cliente[CLIENT-ACME] validation

Folders (si tu plan los soporta)

n8n Cloud tiene folders. Crear:

  • Production / Project A
  • Production / Project B
  • Utilities
  • Error Workflows

Tags

Etiquetar workflows por estado:

  • production
  • staging
  • experimental
  • deprecated

Ejemplo completo: refactor con sub-workflow

Workflow original

[Webhook]
   │
[Set: validar]
   │
[IF: válido]
├─ TRUE → [Switch sobre type]
│         ├─→ "enterprise" → [nodos 1-8 procesando enterprise]
│         ├─→ "mid"        → [nodos 1-6 procesando mid]
│         └─→ "small"      → [Send Email simple]
└─ FALSE → [log rechazado]

20+ nodos en un canvas. La rama "enterprise" sola tiene 8 nodos.

Refactorizado con sub-workflows

Workflow principal:

[Webhook]
   │
[Execute Workflow: [UTIL] validate-lead] ← devuelve is_valid
   │
[IF: is_valid]
├─ TRUE → [Switch sobre type]
│         ├─→ "enterprise" → [Execute Workflow: [BRANCH] proc-enterprise]
│         ├─→ "mid"        → [Execute Workflow: [BRANCH] proc-mid]
│         └─→ "small"      → [Send Email simple]
└─ FALSE → [log rechazado]

5 nodos en el canvas principal. Limpio.

Sub-workflows:

  • [UTIL] validate-lead: 4 nodos (validaciones diversas)
  • [BRANCH] proc-enterprise: 8 nodos (lógica original de enterprise)
  • [BRANCH] proc-mid: 6 nodos

Beneficios:

  • Canvas principal legible de una mirada
  • Sub-workflows testables independientemente
  • validate-lead reutilizable en otros workflows

Trampas comunes

Trampa 1: Sub-workflow demasiado pequeño

Qué pasa: Extraes 2 nodos a sub-workflow "por consistencia". Ahora tienes overhead de llamada para casi nada.

Cómo evitar: sub-workflow con menos de 5 nodos generalmente no vale la pena (excepción: utility muy reutilizado).

Trampa 2: Cambiar contrato sin avisar a callers

Qué pasa: Renombras un campo del output del sub-workflow. 3 workflows que lo usan ahora fallan silenciosamente porque el campo viejo no existe.

Cómo evitar:

  • Documentar el contrato con Sticky Note
  • Antes de cambiar, buscar qué workflows llaman al sub (en n8n hay forma de ver llamadas, o grep manual)
  • Versionar: en lugar de cambiar, crear [UTIL] validate-email-v2 y migrar callers gradualmente

Trampa 3: Sub-workflows que se llaman entre sí formando ciclos

Qué pasa: A llama a B, B llama a C, C llama a A. Loop infinito.

Cómo evitar: n8n debería detectar y prevenir, pero documenta tus llamadas para evitar accidentes.

Trampa 4: Demasiados sub-workflows

Qué pasa: Refactorizaste todo a sub-workflows. Tienes 80 workflows en tu lista. Encontrar algo es imposible.

Cómo evitar: balance. Sub-workflows solo para casos justificados. No es virtud por sí mismo.

Trampa 5: Sub-workflow sin tests

Qué pasa: Tienes [UTIL] validate-email usado en 5 workflows. Lo modificas. Algo se rompe en 1 de los 5 que no testeaste.

Cómo evitar:

  • Mantener casos de prueba para cada sub-workflow
  • Antes de modificar, probar con esos casos
  • Si los 5 callers usan el sub diferente, considerar que cada uno tenga su propio sub específico

Ejercicio: identificar candidatos a extraer

Objetivo: mirar tus workflows existentes y identificar candidatos.

Tu tarea

Revisa los workflows que has construido (G1 + G2). Para cada uno, hazte:

  1. ¿Hay alguna rama compleja (5+ nodos) que se beneficiaría de extraer?
  2. ¿Hay lógica duplicada entre workflows (validación email, etc.)?
  3. ¿Hay alguna parte que cambiarías frecuentemente mientras el resto se queda igual?

Anota los candidatos. Si tienes 1-3, considera extraerlos. Si tienes 0, tus workflows están bien tamaños actuales — no fuerces sub-workflows sin necesidad.

Resumen y siguiente paso

  • Sub-workflows = piezas reutilizables/extraídas, llamadas con Execute Workflow
  • 5 criterios para extraer: reutilización, complejidad de rama, equipos diferentes, testing aislado, versionamiento
  • 3 patrones: utilities reutilizables, branch extractors, multi-tenant
  • Contrato implícito: documentar input/output esperado con Sticky Note
  • Convención de nombres: [UTIL], [BRANCH], [CLIENT-X], [GUARDIAN]
  • 5 trampas: sub demasiado pequeño, cambiar contrato sin avisar, ciclos, demasiados subs, sub sin tests

Antes de avanzar deberías poder:

  • Crear un sub-workflow callable y llamarlo desde otro
  • Decidir cuándo extraer es beneficioso
  • Aplicar convenciones de nombre para mantener orden

Lo que sigue (cápsula 08):

Cierre del módulo: mini-proyecto que aplica todos los patrones. Vas a construir un árbol de decisión de 3 niveles para procesar tickets de soporte — con pre-cómputo, filtros en cadena, Switch consolidado, y sub-workflows. Es la consolidación práctica del módulo.

Recursos adicionales

  1. Execute Workflow Node - Referencia oficial.
  2. Workflow Composition Patterns - Patrones avanzados.
  3. Don't Repeat Yourself (DRY) - Principio que motiva extracción.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorIf Hell y Cómo RefactorizarSiguiente →Mini-Proyecto: Árbol de Decisión de 3 Niveles