n8n Execute Sub-workflow: practica un contrato de contactos
Crea un flujo invocador y un normalizador de contactos con n8n Execute Sub-workflow y comprueba valores ausentes, tipos y múltiples elementos.
Comprobado con las fuentes citadas el .
Ejercicio editorial: define el contrato de contactos
Practica n8n Execute Sub-workflow creando un normalizador de contactos reutilizable y un flujo invocador de desarrollo independiente. Tu tarea consiste en definir su contrato compartido, implementarlo y recopilar las salidas o los errores reales de cuatro casos de prueba propuestos. Este es un ejercicio editorial, no una solución ejecutada ni validada.
Usa tu propio entorno de desarrollo de n8n, contactos sintéticos y ningún servicio externo. Debes saber ya cómo añadir nodos y mapear campos. Construye el ejercicio manualmente y mantén la ejecución síncrona; quedan fuera de su alcance la publicación en producción, los permisos, las ejecuciones pausadas, el enrutamiento a flujos de errores y la extracción automática de nodos existentes.
Usa el siguiente contrato propuesto. Exige valores no vacíos para email y name; elimina los espacios de los extremos de ambos y convierte email a minúsculas. Solo para este ejercicio, acepta un correo si contiene una @ con texto a ambos lados y ningún espacio en blanco. Es una comprobación deliberadamente limitada, no una validación exhaustiva de correos electrónicos.
| Dirección | Campo | Tipo | Regla |
|---|---|---|---|
| Entrada | Cadena de texto | Obligatorio; normalizar y comprobar | |
| Entrada | name | Cadena de texto | Obligatorio; eliminar espacios de los extremos |
| Salida | success | Booleano | true solo si es válido |
| Salida | Cadena de texto | Valor normalizado, o vacío si falla | |
| Salida | name | Cadena de texto | Valor sin espacios en los extremos, o vacío si falla |
| Salida | error | Cadena de texto | Vacío si tiene éxito; motivo si falla |
Creemos que escribir el contrato de retorno antes de construir los nodos hace que este ejercicio sea más útil: proporciona un objetivo concreto para cada comprobación.
Construye el flujo hijo con n8n Execute Sub-workflow Trigger
Inicia el flujo hijo con n8n Execute Sub-workflow Trigger y declara email y name como entradas de tipo cadena de texto. La documentación de n8n establece este disparador como el primer nodo del flujo hijo; las entradas declaradas con tipos se convierten en parámetros que el flujo invocador puede rellenar.
Para la implementación propuesta, conecta un nodo Code que valide y normalice cada elemento y, después, un nodo Edit Fields llamado Return. La secuencia siguiente define la lógica propuesta. n8n devuelve la salida del último nodo del flujo hijo, y sus recomendaciones aconsejan un nodo Set / Edit Fields final para exponer el contrato de retorno; esto no impone automáticamente un esquema de salida completo.
- Comprueba si hay null, valores ausentes y valores que no sean cadenas de texto antes de llamar a métodos de cadenas.
- Elimina los espacios de los extremos de ambas cadenas, convierte email a minúsculas y comprueba después si hay valores vacíos y si se cumple la regla de correo del ejercicio.
- Si falla, genera success con valor false, cadenas vacías para email y name, y una cadena error explicativa.
- Si tiene éxito, genera success con valor true, email normalizado, name sin espacios en los extremos y una cadena error vacía.
- Configura Return para exponer únicamente success, email, name y error.
Para los fallos de validación previstos, conserva los mismos nombres y tipos de campo. Esto sigue la recomendación de n8n de usar una estructura de retorno coherente con un indicador success y un campo error.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflowtrigger.md at main · n8n-io/n8n-docs · GitHub, skills/skills/n8n-subworkflows-official/SKILL.md at main · n8n-io/skills · GitHub
Construye el flujo invocador de desarrollo
Crea un flujo invocador independiente con Manual Trigger, datos sintéticos de prueba y n8n Execute Sub-workflow. La documentación de n8n presenta Code y Edit Fields como formas de generar conjuntos de datos de prueba personalizados. En Execute Sub-workflow, selecciona Database / From list, elige el flujo hijo y mapea sus entradas declaradas.
Activa Wait for Sub-Workflow Completion y desactiva inicialmente Attempt to convert types. La espera permite que el flujo padre continúe después de que termine el hijo; no valida los datos devueltos. Empieza con el modo que pasa todos los elementos de entrada a una sola ejecución. Ninguno de los dos modos garantiza la cantidad de elementos de salida que buscas.
Los campos mapeados no aparecen cuando el flujo hijo usa Accept all data, así que utiliza aquí entradas explícitas con tipos. Puedes fijar los datos de prueba de desarrollo para repetir las comprobaciones, pero esta función no está disponible en las ejecuciones de producción; estas comprobaciones no permiten establecer el comportamiento en producción.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflow.md at main · n8n-io/n8n-docs · GitHub, n8n-docs/docs/build/work-with-data/pin-and-mock-data.md at main · n8n-io/n8n-docs · GitHub
Comprueba cuatro casos a través del flujo invocador
Ejecuta estos datos de prueba propuestos a través de la interfaz del flujo invocador y registra lo que ocurre realmente. Los valores esperados que aparecen a continuación son objetivos del ejercicio, no resultados de pruebas realizadas.
| Caso | Entrada | Objetivo u observación |
|---|---|---|
| Válido | email: ' ALICE@EXAMPLE.COM '; name: ' Alice ' | true; alice@example.com; Alice; error vacío |
| Falta name | Correo válido; mapeo de name eliminado | false; email/name vacíos; error explicativo |
| Tipo incorrecto | email: 12345; name: Alice | Registra el rechazo del flujo invocador o el resultado del hijo |
| Múltiples elementos | Dos contactos válidos distintos | Objetivo: dos resultados normalizados en ambos modos de ejecución |
La documentación de n8n indica que eliminar el mapeo del campo solicitado name envía null.
En su guía del proveedor de 2026, Jahanzaib Ahmed informa de que su prueba con Docker en n8n 2.43.4 rechazó un email numérico en el flujo padre con la conversión desactivada; al activarla, lo pasó a la validación del flujo hijo como una cadena de texto. Este es el resultado que él comunica, no un comportamiento verificado de forma independiente en distintas instalaciones. Repite por tu cuenta ambas configuraciones; según la regla de correo propuesta, la cadena 12345 debería fallar la validación. No des por hecho que un rechazo del flujo invocador se convierte en una fila de fallo generada por el hijo.
Sources: n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflow.md at main · n8n-io/n8n-docs · GitHub, n8n Sub Workflow: Build One and Handle Failures
Revisa las discrepancias y termina el ejercicio
Si el resultado difiere de tu contrato, inspecciona primero las entradas declaradas y los mapeos del flujo invocador y, después, el tratamiento de null y la configuración de conversión. Si faltan datos de retorno, inspecciona el modo de ejecución, la configuración de espera y la salida del último nodo del flujo hijo. Compara los nombres de campo, los tipos y la cantidad de elementos en el flujo invocador.
En la revisión, separaríamos el rechazo en la interfaz del fallo de validación de negocio: cada uno indica algo distinto sobre dónde falló el contrato.
Completa el ejercicio con las pruebas indicadas a continuación. Como reflexión, explica por qué una llamada rechazada podría no tener un objeto de retorno del flujo hijo y cómo la conversión cambia lo que recibe tu validación.
Sources: skills/skills/n8n-subworkflows-official/SKILL.md at main · n8n-io/skills · GitHub, n8n-docs/docs/integrations/builtin/core-nodes/n8n-nodes-base.executeworkflow.md at main · n8n-io/n8n-docs · GitHub
