Módulo 3: Contratos entre workflows

4. La frontera del nodo Execute Sub-workflow

Siguiente →

Descripción

Al terminar esta lección vas a poder construir la llamada real entre dos workflows en n8n 2.0: agregar el nodo que hace que order-triage invoque a check-credit, entender qué datos cruzan la frontera en cada dirección, y declarar los campos de entrada de tu esquema dentro del sub-workflow para que n8n los reconozca. Vas a saber qué modo de ejecución elegir según lo que le pases, y por qué conviene que un sub-workflow tenga un solo punto de entrada. También vas a conocer el modelo de ejecución —cómo el workflow padre se pausa, el sub-workflow corre, y el padre continúa con el resultado—.

Esto importa porque hasta ahora el contrato vivió en papel: lo definiste (lección 2) y lo diseñaste como esquema (lección 3), pero no lo pusiste a funcionar. La frontera del nodo Execute Sub-workflow es donde el contrato deja de ser un documento y se vuelve una llamada real que ejecuta. Todo lo que valides (lección 5) y versiones (lección 6) ocurre alrededor de esta frontera; sin entender bien qué cruza por aquí y cómo, esas dos lecciones quedan en el aire.

Conexión con el módulo: la lección 3 diseñó el esquema de check-credit en papel. Esta lo transcribe al nodo Execute Sub-workflow Trigger y construye la llamada desde order-triage. Los campos que declares aquí son los que la lección 5 va a validar más a fondo, y los que la lección 6 va a versionar. Una nota sobre el nombre: en n8n 2.0 el nodo que hace la llamada se llama Execute Sub-workflow —en versiones anteriores se llamaba "Execute Workflow", y así lo vas a ver en tutoriales viejos y en algunas guías del ecosistema—. El concepto es idéntico; solo cambió la etiqueta. Como las etiquetas de n8n cambian de versión en versión, cuando el nombre exacto de un campo o botón sea importante te lo voy a decir y te voy a pedir que lo verifiques en tu propio panel.

Un solo punto de entrada: la puerta con portero

Piensa en un edificio de oficinas serio. No entras por la ventana, ni por el estacionamiento, ni por la puerta de servicio. Entras por la recepción, donde hay un portero que revisa quién eres, a qué vienes y si traes lo que necesitas para pasar. Ese único punto de entrada no es una molestia burocrática; es lo que hace que el edificio sea gobernable. Como todos entran por el mismo lugar, hay un solo sitio donde revisar, un solo sitio donde llevar el registro, un solo sitio que proteger. Un edificio con cinco entradas sin control es un edificio que nadie puede asegurar.

Un sub-workflow con contrato es ese edificio, y el nodo Execute Sub-workflow Trigger es su recepción. Es el primer nodo del sub-workflow, el único por donde entra una llamada de otro workflow. No importa quién llame —order-triage, otro workflow, un agente—: todos entran por la misma puerta, la que declara qué campos espera recibir. Ese único punto de entrada es lo que hace que el contrato sea gobernable: hay un solo lugar donde declarar el esquema (esta lección), un solo lugar donde validar la entrada (lección 5), un solo lugar donde saber qué versión del contrato estás sirviendo (lección 6).

Compáralo con la alternativa desordenada: un sub-workflow que asume que los datos "ya vienen bien" desde donde sea que lo llamaron, sin una puerta clara. Ese sub-workflow no tiene dónde poner al portero. Cada llamador podría mandarle cosas distintas, y no hay un punto único donde revisar. La frontera —el Execute Sub-workflow Trigger como recepción única— es la precondición de todo lo demás. Sin ella, no hay dónde parar al que no cumple el contrato.

Las dos piezas de la frontera

Una llamada entre workflows tiene dos nodos, uno de cada lado de la frontera. Conviene tenerlos claros porque es fácil confundirlos —los dos tienen "Sub-workflow" en el nombre—.

Del lado del que responde: el Execute Sub-workflow Trigger. Es el primer nodo del sub-workflow check-credit. En el lienzo, n8n lo muestra con la etiqueta "When Executed by Another Workflow" ("cuando otro workflow me ejecuta"), que describe exactamente su papel: este nodo se activa cuando otro workflow lo llama. Es la recepción vista desde adentro del edificio: donde llega la visita. Aquí es donde declaras qué campos espera tu sub-workflow.

Del lado del que llama: el nodo Execute Sub-workflow. Es un nodo que pones en order-triage, en el punto donde quieres invocar a check-credit. Es el visitante presentándose en la recepción del otro edificio. Aquí eliges a qué sub-workflow llamas y qué datos le mandas.

Los dos juntos forman la frontera. El diagrama de la lección 1 ahora tiene nombres reales:

order-triage (el llamador)                 check-credit (el que responde)
──────────────────────────                 ──────────────────────────────
[Webhook]                                   [Execute Sub-workflow Trigger]
   │                                         (etiqueta en lienzo:
[AI Agent]                                    "When Executed by Another Workflow")
   │                                                │
[Execute Sub-workflow] ─── entrada ──►        (consultar crédito, comparar, decidir)
   │           ◄────────── salida ──────────  [último nodo devuelve el resultado]
[HTTP Request al CRM]

Del lado del que responde: declarar el esquema en el trigger

Aquí es donde el esquema que diseñaste en la lección 3 entra a n8n. El nodo Execute Sub-workflow Trigger tiene una opción —que conviene verificar en tu panel, porque su etiqueta puede variar— llamada "Input data mode" (modo de datos de entrada), con tres opciones. Cada una es una forma distinta de declararle a n8n qué espera recibir tu sub-workflow.

"Define using fields below" (definir usando los campos de abajo). Eliges esta opción y n8n te deja listar los campos uno por uno: para cada uno, un nombre y un tipo (string, number, boolean o json). Es la transcripción directa de tu esquema. Para check-credit, listas customer_id como string, order_id como string, amount como number y currency como string. Lo poderoso de este modo: cuando otro workflow agregue un nodo Execute Sub-workflow y elija llamar a check-credit, n8n le muestra automáticamente estos campos en el nodo del llamador, ya listos para llenar. El esquema que declaraste una vez, en la recepción, aparece como una guía en cada visitante. Es el contrato ayudando activamente a que lo cumplan.

"Define using JSON example" (definir usando un ejemplo JSON). Eliges esta opción y en vez de listar campos uno por uno, le pegas un objeto de ejemplo —como el que armaste al final de la lección 3— y n8n deduce el esquema a partir de él: ve "amount": 1842.50 y deduce que amount es un número. Es más rápido si ya tienes un ejemplo representativo, y es la razón por la que ese ejemplo concreto que escribiste para documentar sirve también para declarar.

"Accept all data" (aceptar todos los datos). Eliges esta opción y el sub-workflow acepta lo que sea que le manden, sin declarar ningún campo esperado. Es el edificio sin portero: entra cualquiera con lo que traiga. Tiene su lugar —un sub-workflow genérico de utilidad que de verdad procesa cualquier item—, pero para un sub-workflow con contrato como check-credit es justo lo que no queremos: renuncia a la puerta que hace gobernable al contrato. Si tu sub-workflow tiene un contrato serio, este no es tu modo.

Para check-credit, la elección es clara: "Define using fields below", con los cuatro campos de tu esquema. Así la recepción sabe a quién dejar pasar y con qué, y los llamadores reciben la guía de qué mandar.

Un matiz importante, que conecta con la lección 5: declarar los campos en el trigger le dice a n8n los nombres y los tipos que esperas, y ayuda a los llamadores, pero no valida a fondo las reglas de negocio. El trigger sabe que amount debería ser un número; no sabe que un amount negativo no tiene sentido, ni que customer_id debe existir en tu base de clientes. Esa validación más profunda es el tema de la próxima lección. Por ahora quédate con que el trigger es la declaración del esquema; la validación completa se construye encima.

Del lado del que llama: invocar al sub-workflow

Ahora crucemos a order-triage, donde agregas el nodo Execute Sub-workflow en el punto donde quieres consultar el crédito. Este nodo tiene unos parámetros que conviene entender, porque cada uno es una decisión sobre cómo cruza la frontera. Los nombres exactos pueden variar entre versiones —verifícalos en tu panel—, pero el concepto de cada uno es estable.

Source (fuente). De dónde sale el sub-workflow que vas a llamar. La opción normal es elegirlo de tu lista de workflows en la misma instancia ("Database" / "From list"). Hay otras fuentes —un archivo, un parámetro, una URL— para casos avanzados, pero para llamar a un sub-workflow tuyo que vive en la misma instancia, eliges tu lista y seleccionas check-credit.

Workflow. Cuál sub-workflow. Aquí eliges check-credit del desplegable. Si en check-credit declaraste los campos con "Define using fields below", este es el momento en que n8n te muestra esos campos listos para llenar —la guía del contrato apareciendo del lado del llamador—.

Los inputs (los datos que le pasas). Aquí llenas los campos que el sub-workflow declaró: qué valor va en customer_id, cuál en order_id, cuál en amount. Estos valores salen de los datos que order-triage ya tiene en ese punto —por ejemplo, el customer_id del pedido que llegó por el webhook—. Es el visitante llenando la boleta de la recepción con sus datos.

Mode (modo). Cómo se ejecuta la llamada respecto de los items que le llegan al nodo. Tiene dos opciones, y la elección importa:

  • "Run once with all items" (una vez con todos los items). El sub-workflow se llama una sola vez, y recibe de golpe todos los items que tenga el nodo. Sirve cuando el sub-workflow está diseñado para procesar un lote completo.
  • "Run once for each item" (una vez por cada item). El sub-workflow se llama una vez por cada item que llegue al nodo. Si a order-triage le entraron tres pedidos, check-credit se ejecuta tres veces, una por pedido, cada una con su propia entrada y su propia salida.

Para check-credit, la elección natural es "Run once for each item": el contrato de check-credit está escrito para un pedido —un customer_id, un order_id, un amount—, así que quieres que se ejecute una vez por pedido. Esta decisión no es cosmética: cambia qué forma tiene la entrada que recibe el sub-workflow, y por lo tanto cómo escribes su validación en la lección 5. Un contrato diseñado para un item y llamado en modo "todos los items" es una fuente clásica de confusión.

"Wait for Sub-Workflow Completion" (esperar a que el sub-workflow termine). Una opción del nodo que, cuando está activa —que es lo normal—, hace que order-triage se detenga y espere a que check-credit termine y devuelva su resultado antes de continuar. Es lo que quieres casi siempre: order-triage necesita el approved para decidir, así que tiene que esperarlo. Desactivarla haría que order-triage dispare la llamada y siga sin esperar respuesta —útil para tareas que no necesitan resultado, pero no para nuestro caso, donde el resultado es justo el punto—.

El modelo de ejecución: pausar, ejecutar, continuar

Vale la pena ver en cámara lenta qué pasa cuando order-triage llega al nodo Execute Sub-workflow, porque entender esta secuencia te evita confusiones sobre por qué el workflow "se queda esperando" o de dónde salen los datos que continúan.

  1. order-triage llega al nodo Execute Sub-workflow con un pedido en la mano (un item con customer_id, order_id, amount).
  2. order-triage se pausa. Como la opción de esperar está activa, el workflow padre se queda quieto en ese punto. No avanza al HTTP Request al CRM todavía.
  3. check-credit se ejecuta. El item cruza la frontera y entra por el Execute Sub-workflow Trigger. Adentro, check-credit hace su trabajo —consulta el crédito, compara, decide— y su último nodo produce el resultado con la forma del contrato (el sobre ok con approved y available_credit).
  4. El resultado cruza la frontera de vuelta. Lo que produjo el último nodo de check-credit sale por la frontera y vuelve al nodo Execute Sub-workflow de order-triage.
  5. order-triage continúa con ese resultado como los datos del item. Ahora el siguiente nodo puede leer ok y approved y decidir qué hacer.

La imagen mental es la del mesero en la ventanilla de la cocina: lleva la comanda (paso 1-3), se queda esperando en la ventanilla (paso 2), la cocina prepara (paso 3), sale el plato por la ventanilla (paso 4), y el mesero lo lleva a la mesa (paso 5). El comensal —los nodos que siguen en order-triage— nunca vio la cocina; solo recibió el plato terminado con la forma que el menú prometía.

Un detalle que sale de este modelo: lo que order-triage recibe de vuelta es lo que produjo el último nodo de check-credit. Si el último nodo de tu sub-workflow no tiene la forma del contrato —si devuelve datos internos, o un objeto a medias—, eso es lo que el llamador recibe, contrato o no. El contrato de salida no se cumple solo por estar escrito en el Sticky Note; se cumple porque tú te aseguras de que el último nodo del sub-workflow produzca exactamente esa forma. La lección 8 te hace construir ese último nodo con cuidado precisamente por esto.

Qué no cruza la frontera

Tan importante como saber qué cruza la frontera es saber qué no cruza, porque es una fuente frecuente de confusión y refuerza por qué el contrato tiene que ser explícito.

Por la frontera cruzan los datos del item: los campos que pusiste en los inputs del nodo Execute Sub-workflow van hacia adentro, y los campos que produce el último nodo del sub-workflow vuelven hacia afuera. Eso es todo. La frontera es angosta a propósito, como la ventanilla de la cocina: solo pasa la comanda y el plato.

Lo que no cruza es el resto del contexto de order-triage. check-credit no ve los demás nodos de order-triage, no tiene acceso a los datos que quedaron en nodos anteriores del llamador, y no comparte su memoria de ejecución. Es un edificio aparte: solo conoce lo que le entregaste explícitamente por la recepción. Si check-credit necesita un dato para trabajar, ese dato tiene que estar en el contrato de entrada —no puede "ir a buscarlo" al workflow que lo llamó—.

Esto tiene dos consecuencias prácticas que conviene grabarse:

Si un campo no está en el contrato de entrada, el sub-workflow no lo tiene. No hay una forma de que check-credit "alcance" un campo de order-triage que no le pasaste. Por eso el diseño del esquema de la lección 3 es tan importante: si olvidaste incluir un campo que el sub-workflow necesita, no hay una puerta trasera por donde recuperarlo; hay que agregarlo al contrato. La frontera te obliga a ser explícito, y esa obligación es una virtud —hace que las dependencias del sub-workflow sean visibles en su contrato, no escondidas en suposiciones—.

El estado no se comparte entre los dos lados. Cada workflow tiene su propio contexto de ejecución. Lo que un sub-workflow "recuerde" entre llamadas, o el estado que sobreviva a una ejecución, es un tema aparte —el del Módulo 4, el modelo de datos del sistema—. Aquí, en la frontera, cada llamada es una conversación limpia: entra lo que le pasas, sale lo que produce, y no queda memoria compartida por el solo hecho de haberse llamado. Esa limpieza es lo que hace que un sub-workflow sea predecible: su resultado depende solo de lo que le entra por el contrato, no de un estado invisible que arrastra de llamadas anteriores.

Ejemplo trabajado: conectar order-triage con check-credit

Vamos a construir la llamada completa, paso a paso. Si tienes una instancia de n8n a mano, síguelo; si no, léelo y hazlo después. Los nombres de botones y opciones pueden variar según tu versión —verifícalos en tu panel—.

Paso 1 — El sub-workflow con su recepción. Crea un workflow nuevo llamado check-credit. Su primer nodo es un Execute Sub-workflow Trigger (búscalo como "Execute Sub-workflow Trigger" o "When Executed by Another Workflow"). Ábrelo, pon "Input data mode" en "Define using fields below", y declara los cuatro campos de tu esquema:

customer_id : string
order_id    : string
amount      : number
currency    : string

Qué esperar: el nodo queda mostrando esos cuatro campos como la entrada esperada del sub-workflow. Todavía no hace nada con ellos —eso viene después—, pero ya declaró la puerta.

Paso 2 — Un cuerpo mínimo para el sub-workflow. Por ahora, para probar la frontera, conecta después del trigger un nodo Edit Fields (Set) que arme una respuesta de éxito con la forma del contrato. Pon en modo JSON algo así:

{
  "ok": true,
  "customer_id": "{{ $json.customer_id }}",
  "approved": true,
  "available_credit": 5000
}

No es la lógica real de crédito todavía —está fija—, pero tiene la forma del contrato, que es lo que necesitamos para probar la llamada. Guarda el workflow.

Qué esperar: check-credit ahora es un sub-workflow completo: recibe por la puerta, y su último nodo produce una respuesta con la forma del sobre ok.

Paso 3 — El llamador. Ve a order-triage (o crea un workflow de prueba con un Manual Trigger y un Edit Fields que arme un pedido de Cumbre con customer_id, order_id y amount). En el punto donde quieres consultar el crédito, agrega un nodo Execute Sub-workflow. En Source elige tu lista de workflows, y en Workflow selecciona check-credit.

Qué esperar: al seleccionar check-credit, n8n te muestra los campos que declaraste en el trigger —customer_id, order_id, amount, currency— listos para llenar. Ahí está el contrato ayudándote: no tienes que recordar qué espera check-credit, el nodo te lo dice.

Paso 4 — Llenar los inputs y elegir el modo. Llena cada campo con el valor correspondiente del pedido (customer_id con {{ $json.customer_id }}, y así). Pon Mode en "Run once for each item", porque el contrato es por pedido. Verifica que "Wait for Sub-Workflow Completion" esté activo. Ejecuta.

Qué esperar: el nodo Execute Sub-workflow de order-triage muestra en su salida la respuesta que produjo check-credit: { ok: true, customer_id: "...", approved: true, available_credit: 5000 }. Acabas de cruzar la frontera en las dos direcciones: mandaste una entrada con la forma del contrato y recibiste una salida con la forma del contrato. El siguiente nodo de order-triage ya puede leer ok y approved.

Si en vez de eso ves un error o una salida vacía, las causas típicas son dos: o el nodo anterior no se ejecutó y no hay pedido que mandar (revisa que el Edit Fields corrió), o algún campo obligatorio quedó sin llenar en los inputs del nodo Execute Sub-workflow. La frontera es exigente a propósito.

Errores comunes

Confundir el nodo llamador con el nodo trigger (práctico). Qué pasa: alguien pone un Execute Sub-workflow Trigger en el workflow que llama en vez del que responde, o al revés, y la llamada no se conecta —el sub-workflow "no recibe nada" o el llamador "no encuentra a quién llamar"—. Por qué pasa: los dos nodos tienen "Sub-workflow" en el nombre y es fácil agarrar el equivocado del panel de nodos. Cómo detectarlo: recuerda la regla de la recepción —el Trigger ("When Executed by Another Workflow") va como primer nodo del que responde; el Execute Sub-workflow va en medio del que llama—. Si tu sub-workflow no empieza con el Trigger, o tu llamador no tiene el nodo Execute Sub-workflow, ahí está el cruce. Cómo corregirlo: el que responde empieza con el Trigger; el que llama tiene el Execute Sub-workflow en el punto de la llamada. Uno es la recepción, el otro es el visitante.

Elegir el modo equivocado y recibir una forma de entrada inesperada (práctico). Qué pasa: el contrato de check-credit está escrito para un pedido, pero el llamador lo invoca en modo "Run once with all items", así que el sub-workflow recibe un lote de varios pedidos de golpe en vez de uno; la lógica interna, escrita para un solo pedido, procesa mal o solo el primero. Por qué pasa: el modo por defecto y el mental no siempre coinciden, y el efecto no salta a la vista hasta que llegan dos o más items juntos. Cómo detectarlo: pregúntate "¿el contrato de este sub-workflow está escrito para un item o para un lote?" y compáralo con el modo elegido en el nodo Execute Sub-workflow. Si el contrato es por item pero el modo es "all items", hay desajuste. Cómo corregirlo: para un sub-workflow con contrato por item —como check-credit—, usa "Run once for each item", de modo que se ejecute una vez por pedido con la entrada que su contrato espera. Alinea el modo con la forma para la que diseñaste el contrato.

Dejar el sub-workflow en "Accept all data" y creer que tiene contrato (conceptual). Qué pasa: alguien crea check-credit, deja el Input data mode en "Accept all data" porque "así acepta lo que le manden", y luego se sorprende de que el nodo llamador no le muestre ningún campo guía y de que nada verifique lo que entra. Por qué pasa: "aceptar todo" suena flexible y cómodo, y esconde que se renunció a la puerta que hace gobernable al contrato. Cómo detectarlo: abre el Execute Sub-workflow Trigger de tu sub-workflow con contrato; si está en "Accept all data" y no lista campos, no está declarando su esquema. Cómo corregirlo: para todo sub-workflow con contrato, usa "Define using fields below" (o "Define using JSON example") y declara los campos. "Accept all data" es para utilidades genéricas que de verdad procesan cualquier item, no para un sub-workflow que promete una forma específica.

Ejercicios

Ejercicio 1 — Ubica cada nodo. Para la llamada entre order-triage y check-credit, di en qué workflow va cada uno de estos nodos y en qué posición (primero, en medio), y qué papel cumple en la analogía de la recepción:

(a) Execute Sub-workflow Trigger. (b) Execute Sub-workflow.

Ver solución

(a) Execute Sub-workflow Trigger — va en check-credit (el que responde), como su primer nodo. Es la recepción del edificio vista desde adentro: donde llega la visita y donde se declara qué se necesita para pasar. En el lienzo aparece como "When Executed by Another Workflow".

(b) Execute Sub-workflow — va en order-triage (el que llama), en medio, en el punto donde se necesita consultar el crédito. Es el visitante presentándose en la recepción del otro edificio: elige a quién llamar y llena la boleta con sus datos.

Por qué funciona: la confusión entre estos dos nodos es de las más comunes, y la regla de la recepción la resuelve de un golpe: el Trigger es el que recibe (primero, en el que responde); el Execute Sub-workflow es el que va a visitar (en medio, en el que llama). Si tienes clara la dirección de la flecha —quién llama a quién—, tienes claro dónde va cada nodo.

Ejercicio 2 — Elige el Input data mode. Para cada uno de estos sub-workflows, decide qué modo de datos de entrada usarías en su Execute Sub-workflow Trigger ("Define using fields below", "Define using JSON example" o "Accept all data") y por qué:

(a) check-credit, con su esquema de cuatro campos ya diseñado. (b) Un sub-workflow log-anything que recibe cualquier item y lo guarda tal cual en un log, sin importar su forma. (c) Un sub-workflow nuevo para el que ya tienes un objeto JSON de ejemplo representativo pero no has escrito la lista de campos.

Ver solución

(a) "Define using fields below". Tienes el esquema explícito con cuatro campos, tipos y obligatoriedad; transcribirlo campo por campo es lo más claro y hace que los llamadores reciban la guía. Es el modo natural para un sub-workflow con contrato serio.

(b) "Accept all data". Es el caso legítimo de este modo: log-anything de verdad no tiene un contrato de forma —su trabajo es aceptar cualquier item—, así que declarar campos no tendría sentido. Aquí "aceptar todo" no es renunciar a un contrato; es que el contrato de este sub-workflow es, literalmente, "acepto lo que sea".

(c) "Define using JSON example". Ya tienes el ejemplo representativo; pegarlo y dejar que n8n deduzca el esquema es más rápido que transcribir campos a mano, y aprovecha el trabajo que ya hiciste. Después puedes revisar que los tipos que dedujo coincidan con tu intención.

Por qué funciona: el modo no se elige por costumbre, se elige por lo que el sub-workflow promete. Un contrato explícito pide "fields below"; un ejemplo ya escrito pide "JSON example"; la ausencia genuina de contrato de forma pide "accept all data". Confundir el tercer caso (utilidad genuinamente genérica) con un sub-workflow que sí tiene contrato pero al que le da pereza declararlo es el error de la sección anterior.

Ejercicio 3 — Traza la ejecución. order-triage recibe dos pedidos en un mismo disparo y llama a check-credit en modo "Run once for each item", con "Wait for Sub-Workflow Completion" activo. Describe, paso a paso, qué ocurre: cuántas veces se ejecuta check-credit, cuándo se pausa y continúa order-triage, y qué recibe de vuelta.

Ver solución

Como el modo es "Run once for each item" y llegaron dos pedidos, check-credit se ejecuta dos veces, una por pedido:

  1. order-triage llega al nodo Execute Sub-workflow con los dos pedidos.
  2. Para el primer pedido: order-triage se pausa, el pedido cruza la frontera, check-credit se ejecuta con ese único pedido, produce su respuesta ({ ok: true, approved: ..., available_credit: ... }), y esa respuesta vuelve.
  3. Para el segundo pedido: se repite lo mismo —check-credit se ejecuta otra vez, ahora con el segundo pedido, y devuelve su propia respuesta—.
  4. order-triage continúa con dos resultados, uno por pedido, y su siguiente nodo procesa cada uno.

Como "Wait for Sub-Workflow Completion" está activo, order-triage no avanza hasta tener el resultado de cada llamada. Si el modo hubiera sido "Run once with all items", check-credit se habría ejecutado una sola vez recibiendo los dos pedidos juntos —y, como su contrato está escrito para un solo pedido, probablemente habría procesado mal—.

Por qué funciona: este ejercicio junta el modo con el modelo de ejecución. "Run once for each item" convierte N items en N llamadas, cada una respetando el contrato por-pedido de check-credit; y "Wait for Completion" garantiza que cada resultado esté listo antes de seguir. Entender esta mecánica es lo que te deja predecir cuántas veces corre tu sub-workflow y con qué entrada —lo cual, cuando el sub-workflow tiene un efecto como issue-refund, es literalmente la diferencia entre un reembolso y varios—.

Resumen y siguiente paso

En esta lección pusiste el contrato a funcionar. Viste la frontera del nodo Execute Sub-workflow como la puerta única con portero que hace gobernable a un sub-workflow: un solo punto de entrada donde declarar el esquema, validar y saber qué versión sirves. Distinguiste las dos piezas de la frontera —el Execute Sub-workflow Trigger (etiqueta "When Executed by Another Workflow"), primer nodo del que responde, la recepción; y el nodo Execute Sub-workflow, en el que llama, el visitante—. Declaraste el esquema de check-credit en el trigger eligiendo "Define using fields below", y viste que ese esquema aparece automáticamente como guía en el nodo del llamador. Del lado del que llama, entendiste los parámetros clave: Source, Workflow, los inputs, el Mode ("Run once for each item" para un contrato por-pedido) y "Wait for Sub-Workflow Completion". Y trazaste el modelo de ejecución —pausar, ejecutar el sub-workflow, cruzar el resultado de vuelta, continuar—, notando que lo que el llamador recibe es lo que produzca el último nodo del sub-workflow, tenga o no la forma del contrato. Y recordaste que en n8n 2.0 este nodo se llama "Execute Sub-workflow", antes "Execute Workflow", con las etiquetas exactas siempre por verificar en tu panel.

Antes de avanzar a la lección 5 deberías poder: construir una llamada entre dos workflows, poniendo cada nodo del lado correcto; declarar el esquema en el trigger con el modo adecuado; y explicar la secuencia de pausa y continuación cuando un workflow llama a otro.

Lo que tienes hasta aquí es la puerta y el portero parado en ella —pero el portero todavía no revisa nada a fondo—. Declarar los campos en el trigger le dice a n8n los nombres y los tipos, pero no comprueba las reglas de negocio: no impide un amount negativo, ni un customer_id que no existe, ni un dato malformado que se coló. La lección 5 le da trabajo real al portero: validar la entrada en la frontera, rechazar lo que no cumple el contrato con un mensaje claro, y asegurarse de que un dato malo nunca llegue al efecto —que en el caso de un issue-refund sería un reembolso equivocado que no se deshace—.

Recursos

← Anterior3. Diseñar el esquema de entrada y de salidaSiguiente →5. Validar las entradas en la frontera