Módulo 3: Loops e Iteraciones

Iteración Implícita en n8n

Siguiente →

Descripción de la cápsula

Antes de aprender SplitInBatches y loops explícitos, necesitas entender cómo n8n itera por default. Si has trabajado con G1, ya viste el comportamiento sin saberlo: lees 50 filas de un Sheet, y el Slack node siguiente manda 50 mensajes. Nadie escribió un loop — n8n iteró automáticamente. Eso es iteración implícita.

Entenderla bien es importante porque: (1) muchos workflows se rompen por NO entenderla (esperaban 1 ejecución, hubo 50), (2) define cuándo necesitas iteración explícita (SplitInBatches), (3) es la base para entender Aggregate y todos los nodos que manipulan colecciones.

En esta cápsula vas a ver cómo funciona, las 3 reglas que la gobiernan, los patterns comunes, y los límites que te llevan a iteración explícita.

Lo que vas a aprender

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

  • ✅ Explicar la iteración implícita con propias palabras
  • ✅ Reconocer las 3 reglas que la gobiernan
  • ✅ Predecir cuántas veces ejecutará un nodo dados N items de input
  • ✅ Identificar los límites que requieren iteración explícita
  • ✅ Manejar correctamente items que producen múltiples outputs

Las 3 reglas de iteración implícita

Regla 1: Un nodo se ejecuta una vez por cada item de input

Si llegan 50 items al input de un nodo, el nodo se ejecuta 50 veces. Cada ejecución opera sobre 1 item.

Ejemplo:

[Sheets: 50 filas] → [Set: agregar campo X]

El Set se ejecuta 50 veces. Cada vez, opera sobre 1 fila. Output: 50 items con el campo X agregado.

Regla 2: Si un nodo produce N outputs, propaga al siguiente

Algunos nodos producen múltiples items por cada input. Ejemplo: HTTP Request que devuelve un array de 5 elementos → produce 5 items por cada llamada.

Ejemplo:

[Manual] → [HTTP Request: devuelve array de 5] → [Slack]
  • Manual produce 1 item
  • HTTP Request se ejecuta 1 vez, devuelve 5 items
  • Slack se ejecuta 5 veces (una por item del HTTP)

Regla 3: Algunos nodos colapsan N items en 1

Nodos como Aggregate (cápsula 06) o ciertos modos de Merge (G1-M07-04) colapsan múltiples items en un único item agregado.

Ejemplo:

[50 items] → [Aggregate: junta todos] → 1 item con array adentro → [Slack: 1 mensaje]

Aggregate convierte 50 items en 1 item con un array. El siguiente nodo se ejecuta 1 sola vez.

Implicación práctica

Cuando construyes un workflow, mentalmente cuenta cuántos items se generan en cada paso:

[Trigger]                    → 1 item
[Sheets read all rows]       → N items (depende del Sheet)
[Set]                        → N items
[IF: filter]                 → ≤N items
[Slack send]                 → ≤N ejecuciones (1 mensaje por item)

Saber esto te dice cuánto va a tardar y cuántas llamadas al servicio externo habrá.

Cuándo iteración implícita es perfecta

Caso 1: Procesar N items independientes

  • 50 leads del Sheet → mandar email a cada uno
  • 100 pedidos → crear factura para cada uno
  • 20 usuarios → enviar mensaje personalizado

Cada item se procesa independientemente. No necesitas coordinar entre items.

Caso 2: Pipeline lineal

  • Trigger → Set → IF → Slack
  • Cada nodo opera sobre items de manera independiente
  • No hay agregación ni dependencias entre items

Caso 3: Volumen pequeño/medio

  • 1-100 items: implícita es perfecta, sin overhead
  • 100-500 items: aún manejable
  • 500+ items: empieza a tener sentido considerar control explícito

Cuándo iteración implícita no alcanza

Límite 1: Rate limits de APIs externas

Tu workflow llama una API que permite 1 request por segundo. Si tienes 100 items, n8n hace 100 requests lo más rápido posible (puede ser 0.1s entre cada uno). La API te bloquea por rate limit.

Solución: SplitInBatches con Wait entre batches (cápsulas 03, 05).

Límite 2: Timeout del workflow

Si tu workflow tarda más de cierto tiempo (5-30 min según plan), n8n puede cortarlo. Procesar 10,000 items en línea puede no alcanzar el tiempo.

Solución: SplitInBatches procesando en lotes + scheduling.

Límite 3: Memoria

Items grandes (con binary, con muchos campos) × cantidad grande = consumo de memoria. n8n puede quedarse sin RAM.

Solución: SplitInBatches + procesar de a poco para que la memoria se libere entre lotes.

Límite 4: Operaciones que dependen de items previos

Algo como "procesar pedidos en orden, esperando que el anterior termine antes de empezar el siguiente". Iteración implícita no garantiza orden estricto en algunos casos.

Solución: SplitInBatches con Batch Size = 1 = procesar de a uno, en orden estricto.

Casos confusos comunes

Caso confuso 1: "Esperaba 1 mensaje y mandó 50"

Qué pasa: Configuras Slack node, esperando "1 notificación con todos los leads". Pero como había 50 items, mandó 50 mensajes separados.

Por qué: Iteración implícita. Cada item → 1 mensaje.

Solución:

  • Aggregate antes de Slack → 1 item con array de leads → 1 mensaje resumen
  • O construir el mensaje completo en un Set previo que tome todos los items

Caso confuso 2: "Mi HTTP Request se llama N veces, no quiero eso"

Qué pasa: Tienes 100 leads. Un HTTP Request que llama una API. Esperabas 1 llamada con los 100 leads. Pero se ejecutó 100 veces.

Por qué: Iteración implícita.

Solución:

  • Si la API acepta batch, Aggregate antes + 1 request con array
  • Si la API solo acepta 1 item por request, iteración implícita es correcta (necesario)

Caso confuso 3: "El Set no agregó campo X a todos"

Qué pasa: Configuras Set para agregar processed: true a todos los items. Inspeccionas el output y solo algunos lo tienen.

Por qué: Probablemente hay un nodo previo (IF o Filter) que dividió los items en dos ramas. Set solo se ejecutó en la rama que conectaste.

Solución: revisar el flujo — ¿el Set está en la rama correcta?

Caso confuso 4: "Cada item produce N items y se me multiplican"

Qué pasa: Tienes 10 leads. Llamas API que devuelve 5 productos por lead. Resultado: 50 items en el siguiente nodo (10 leads × 5 productos).

Por qué: Regla 2 — n8n propaga el "fan-out". Cada lead → 5 productos → 5 items.

Solución:

  • Si querías mantener relación 1 lead → 1 grupo de productos: Aggregate después agrupando por lead
  • Si quieres procesar cada producto independientemente: el comportamiento default es correcto

Trampas en iteración implícita

Trampa 1: Olvidar Aggregate cuando lo necesitas

Qué pasa: Quieres "resumen diario de leads". Configuras Slack que dice "Hoy llegaron leads: [lista]". Pero la lista está vacía o solo muestra 1 — porque cada mensaje muestra solo el item actual.

Cómo evitar: Aggregate antes para juntar todos los items en uno con array → mensaje único con la lista completa.

Trampa 2: Asumir paralelismo

Qué pasa: Asumes que tus 50 nodos Slack se ejecutan en paralelo. En realidad, n8n los ejecuta secuencialmente en la mayoría de casos.

Cómo evitar: Saber que es secuencial por default. Si tienes 50 mensajes y cada uno tarda 1s, son 50s totales.

Trampa 3: Workflows que se ralentizan con volumen

Qué pasa: Workflow funciona con 10 items. Pruebas con 1000, tarda 30+ min o falla.

Cómo evitar: Test con volumen real durante development, no solo con 5 items mock.

Trampa 4: Order assumptions

Qué pasa: Asumes que los items se procesan en el mismo orden que llegan. En la mayoría de casos sí, pero hay excepciones.

Cómo evitar: Si el orden es crítico, Sort node explícito al inicio + SplitInBatches con batchSize: 1 para procesamiento secuencial estricto.

Ejercicio: predecir comportamiento

Objetivo: practicar visualizar la iteración antes de ejecutar.

Tu tarea

Para cada workflow, predice cuántas veces se ejecuta cada nodo:

Workflow A

[Manual] → [Sheets: 30 filas] → [Set] → [Slack]

Workflow B

[Webhook: 1 request] → [HTTP: devuelve array 10] → [Aggregate] → [Slack]

Workflow C

[Sheets: 100 filas] → [IF: pasa 60] → [Send Email]
Respuestas

A:

  • Manual: 1×
  • Sheets: 1× (produce 30 items)
  • Set: 30×
  • Slack: 30 ejecuciones, 30 mensajes

B:

  • Webhook: 1×
  • HTTP: 1× (produce 10 items)
  • Aggregate: 1× (colapsa 10 → 1)
  • Slack: 1×

C:

  • Sheets: 1× (produce 100)
  • IF: 100× evaluaciones, 60 pasan
  • Send Email: 60×

Resumen y siguiente paso

  • Iteración implícita: n8n ejecuta cada nodo 1 vez por item de input
  • 3 reglas: un input → una ejecución, un nodo puede producir N outputs (fan-out), algunos nodos colapsan N → 1 (aggregation)
  • Implicación: mentalmente cuenta items en cada paso para predecir behavior
  • Cuándo implícita está bien: items independientes, volumen pequeño/medio, pipeline lineal
  • Límites: rate limits API, timeout, memoria, orden estricto → necesitas explícito
  • 4 trampas: olvidar Aggregate, asumir paralelismo, no testear volumen real, asumir orden

Antes de avanzar deberías poder:

  • Predecir cuántas veces se ejecuta cada nodo dados N items
  • Identificar cuándo implícita no alcanza
  • Reconocer cuándo Aggregate es necesario

Lo que sigue (cápsula 03):

Cuando implícita no alcanza, entra SplitInBatches — el nodo que te permite control explícito sobre cómo se procesan los items. Vas a aprender su configuración, los 3 modos principales, y patrones de uso típicos.

Recursos adicionales

  1. n8n Data Concepts - Cómo n8n maneja items.
  2. Looping in n8n - Conceptos de loops.

Creado: Mayo 11, 2026 Versión: 1.0

← AnteriorIntroducción al Módulo: Loops e IteracionesSiguiente →SplitInBatches: El Nodo Principal de Loops