Sub-Workflows: módulos en lugar de un monolito

Un workflow con cincuenta nodes, tres ramas IF anidadas y cinco fuentes de datos diferentes parece impresionante a primera vista, pero en la práctica es una pesadilla de mantenimiento. Cada pequeño cambio en la verificación de facturas rompe todo el workflow de pedidos de clientes, y cada nuevo compañero necesita una hora solo para entender qué hace realmente el workflow. Precisamente para este problema existen en n8n los Sub-Workflows: un workflow llama a otro, recibe su resultado de vuelta y continúa, de forma muy similar a una función en código clásico.

En lugar de un monolito, se crean así pequeños bloques autónomos que pueden probarse individualmente, modificarse individualmente y reutilizarse en varios workflows. Este artículo muestra cómo funcionan técnicamente los Sub-Workflows en n8n, cómo dividir una automatización existente en módulos y en qué debes fijarte respecto al flujo de datos y al manejo de errores. Fecha: julio de 2026.

Qué es realmente un Sub-Workflow

Según la documentación de n8n sobre la división de workflows puedes llamar a un workflow desde otro workflow. Esto te permite construir workflows modulares, similares a microservicios, en lugar de meter todo en un único proceso gigantesco. Un Sub-Workflow no es otra cosa que un workflow de n8n completamente normal, pero construido específicamente para ser activado por otro workflow y devolver un resultado.

Dos nodes forman la base de esta relación: en el workflow que llama, el workflow superior, se encuentra el Execute Sub-workflow Node, y en el workflow llamado se encuentra justo al principio el Execute Sub-workflow Trigger Node, también llamado "When Executed by Another Workflow". El trigger es obligatorio: sin él, un Sub-Workflow no se puede iniciar desde fuera.

Por qué merece la pena la división

Las ventajas se notan en la práctica, no son solo teóricas:

• Reutilización: Escribes una lógica como "validar datos de cliente" o "generar factura PDF" una vez como Sub-Workflow y la llamas desde tantos workflows superiores como quieras, en lugar de copiarla varias veces.
• Mantenibilidad: Si cambia una regla de negocio, la ajustas en un solo lugar, el Sub-Workflow, en lugar de buscar cada instancia en cinco copias diferentes.
• Claridad: Un workflow principal con siete llamadas a Sub-Workflow claramente nombradas es más comprensible de un vistazo que cincuenta nodes en un solo lienzo.
• Ahorro de recursos en workflows grandes: Según la documentación, las ejecuciones de Sub-Workflows no cuentan contra el límite mensual de ejecuciones o de workflows activos de tu plan, lo que además ayuda con problemas de memoria en workflows muy grandes.
• Responsabilidades separadas: Un equipo puede trabajar en la lógica de pedidos, otro en el envío de correos electrónicos, sin estorbarse mutuamente en el mismo workflow.

Cualquiera que automatice en la empresa muchos procesos recurrentes, como procesos de presupuestos o de facturación, se beneficia especialmente de esta modularización. Encontrarás más sobre este tipo de automatizaciones en empleados digitales de NordFlux.

Construir un Sub-Workflow: el Trigger Node

Para que un workflow se pueda usar como Sub-Workflow, añades el Execute Sub-workflow Trigger Node justo al principio. Según la documentación, debe ser el primer node del workflow. Para los datos de entrada esperados hay tres modos disponibles:

• Define using fields: Defines nombres de campo individuales y sus tipos de datos que el workflow que llama debe proporcionar.
• Define using JSON example: Proporcionas un JSON de ejemplo, del que n8n deduce la estructura y los tipos.
• Accept all data: El trigger acepta cualquier estructura de datos entrante sin restricciones.

Para Sub-Workflows usados en producción, la primera o la segunda variante suele ser la mejor opción, porque las entradas claramente definidas hacen visibles los errores pronto, en lugar de dejarlos aparecer solo a mitad del proceso.

Llamar a un Sub-Workflow: el Execute Sub-workflow Node

En el workflow superior, integras el Execute Sub-workflow Node y defines qué workflow debe ejecutarse. Según la documentación de n8n sobre el Execute Sub-workflow Node hay cuatro fuentes disponibles para ello:

• Database: Selección de una lista de workflows existentes o introducción directa del ID del workflow.
• Local File: Ejecución de un workflow que se encuentra localmente en el host de n8n como archivo JSON.
• Parameter: El código del workflow se introduce directamente como JSON en el node.
• URL: Un workflow se carga y ejecuta desde una dirección web.

Además, defines el modo de ejecución: o bien pasas todos los items de entrada al Sub-Workflow en una sola ejecución, o inicias el Sub-Workflow una vez por cada item de entrada por separado. Mediante la opción Wait for Sub-Workflow Completion determinas si el workflow superior espera el resultado o continúa de inmediato sin esperar a que finalice.

Flujo de datos entre el workflow principal y el Sub-Workflow

Los datos viajan en un patrón claro de dos etapas: el Execute Sub-workflow Node en el workflow principal envía sus datos al Execute Sub-workflow Trigger Node en el workflow llamado. Allí pasan por los demás nodes del Sub-Workflow, y el último node del Sub-Workflow envía su resultado de vuelta al Execute Sub-workflow Node en el workflow principal. El enlace "View sub-execution" permite rastrear esta ejecución en ambas direcciones, una herramienta importante al depurar automatizaciones anidadas.

Debes conocer una limitación importante: si el Sub-Workflow contiene errores, el workflow superior no puede activarlo con éxito. Un Sub-Workflow que funcione correctamente y esté probado es, por tanto, un requisito, no un extra.

Convertir un workflow existente en un Sub-Workflow

Si no quieres empezar de cero, puedes convertir directamente partes de workflow existentes. Según la documentación de n8n sobre la conversión a Sub-Workflows marcas los nodes deseados en el lienzo, haces clic derecho sobre el fondo y seleccionas "Convert to sub-workflow" en el menú contextual.

Para la selección se aplican reglas fijas:

• Los trigger nodes no deben formar parte de la selección.
• La selección debe ser conexa, con conexiones válidas al resto del workflow.
• Solo debe haber un punto de entrada, es decir, solo un node que reciba conexiones desde fuera de la selección, y eso a través de una única rama de entrada sin node de fusión.
• Del mismo modo, solo debe haber un punto de salida, un único node con conexiones hacia fuera, a través de una única rama de salida sin node IF.
• Todos los nodes entre el punto de entrada y el punto de salida deben estar incluidos en la selección.

También debes prever algunas trampas: según la documentación, la función está disponible en todos los planes a partir de la versión n8n 1.97.0, pero los Sub-Workflows recién creados usan el orden de ejecución v1, que puede diferir de la configuración del workflow original. En los nodes de IA el soporte es limitado, los sub-nodes conectados deben incluirse por completo en la selección y los nodes compartidos pueden necesitar duplicarse. También deberías revisar cuidadosamente las funciones de acceso como first(), last() y all(), así como la función itemMatching, que requiere índices numéricos fijos en lugar de expresiones, después de la conversión, antes de poner en producción el nuevo Sub-Workflow.

Ejemplo práctico: dividir un proceso de presupuestos en módulos

Imagina un workflow que revisa las solicitudes entrantes, crea un presupuesto, lo formatea como PDF y lo envía por correo electrónico. En lugar de agrupar todo eso en un solo proceso, se puede dividir limpiamente: un Sub-Workflow "validar datos de cliente", un segundo "calcular presupuesto", un tercero "generar y enviar PDF". El workflow principal llama a estos tres módulos uno tras otro y pasa los resultados. Si más adelante cambia la lógica de precios, solo se ajusta el segundo Sub-Workflow, todo lo demás permanece intacto. NordFlux implementa exactamente este tipo de automatización modular y fácil de mantener para clientes pyme, para que mantengas el control de tus procesos incluso con una complejidad creciente.

Preguntas frecuentes

¿Cuándo merece la pena un Sub-Workflow y cuándo no?

Un Sub-Workflow merece la pena en cuanto una lógica se necesita más de una vez o un workflow se vuelve tan grande que resulta confuso. Para procesos muy pequeños, usados una sola vez, con pocos nodes, en cambio, la sobrecarga adicional de la llamada rara vez merece la pena, aquí suele bastar un único workflow.

¿Puede un Sub-Workflow a su vez llamar a otro Sub-Workflow?

Sí, los Sub-Workflows se pueden anidar, un workflow llamado puede a su vez contener otro Execute Sub-workflow Node. En la práctica deberías vigilar la profundidad de anidamiento para que la estructura siga siendo comprensible y los errores se puedan seguir atribuyendo al depurar.

¿Qué ocurre si el Sub-Workflow falla?

Si el Sub-Workflow contiene errores, el workflow superior, según la documentación, no puede activarlo con éxito. Por eso cada Sub-Workflow debería probarse por separado y estar equipado con un manejo de errores limpio antes de que otros workflows dependan de él.

¿Cuentan las ejecuciones de Sub-Workflows para mi límite de n8n?

Según la documentación de n8n, las ejecuciones de Sub-Workflows no cuentan contra el límite mensual de ejecuciones o de workflows activos de tu plan. Esto hace que los módulos sean especialmente atractivos si tienes muchos subprocesos recurrentes que de otro modo correrían individualmente contra tu límite.

¿Puedo dividir a posteriori un workflow existente en módulos?

Sí. Mediante la función "Convert to sub-workflow" marcas nodes conectados con exactamente un punto de entrada y un punto de salida y los conviertes en un Sub-Workflow independiente mediante clic derecho. Después deberías revisar de nuevo el orden de ejecución y las expresiones utilizadas en el nuevo Sub-Workflow.