Serie N8N (V): Control de flujo – Condiciones, decisiones y ramificaciones
- josejotxe
- 7 ene
- 8 Min. de lectura
Hasta ahora hemos creado workflows lineales: un trigger inicia el flujo, los nodos se ejecutan uno detrás de otro y el proceso termina. Este tipo de workflows funcionan muy bien para tareas simples, pero en cuanto el proceso crece aparece una necesidad clara: tomar decisiones.
En la automatización real, muchas veces ocurre algo como esto:
si pasa una cosa → hago una acción
si pasa otra → hago algo distinto
Es decir, el flujo se divide.
En N8N esto se representa de forma visual mediante ramificaciones, donde un workflow deja de ser una línea recta y se convierte en un diagrama con varios caminos posibles.
Este capítulo trata precisamente de eso: aprender a controlar el flujo, decidir qué camino seguir y entender cómo N8N gestiona esas decisiones.
Nota: el workflow que haremos se podrá descargar en un enlace al final de este artículo.
Qué es una condición (explicado para humanos)
Una condición no es más que una pregunta que puede tener dos respuestas posibles:
sí / no
verdadero / falso
En el día a día tomamos decisiones así constantemente, casi sin pensarlo:
¿Está el archivo vacío?
¿Existe este dato?
¿El valor es mayor que cero?
En automatización ocurre exactamente lo mismo. Un workflow recibe datos y, en función de esos datos, decide qué hacer a continuación.
Con condiciones, un workflow:
se adapta a los datos,
reacciona a situaciones distintas,
y se comporta de forma más inteligente.
Este es el primer gran salto desde “automatizar tareas” hacia automatizar procesos reales.
N1. El nodo IF: el corazón de las decisiones en N8N
En N8N, las condiciones se implementan mediante un nodo muy concreto: el nodo IF. Este nodo es el encargado de evaluar una condición y decidir por qué camino debe continuar el workflow.
Qué hace exactamente el nodo IF
El nodo IF funciona siempre de la misma forma:
Recibe datos del nodo anterior.
Evalúa una condición que tú defines.
Según el resultado:
si la condición se cumple → sale por TRUE,
si no se cumple → sale por FALSE.
No hay más lógica oculta. Es una bifurcación clara y visual.
Cómo se ve un nodo IF en un workflow
Cuando añades un nodo IF al lienzo, verás algo muy característico:
una entrada por la izquierda,
dos salidas por la derecha:
TRUE
FALSE
Cada una de esas salidas puede llevar a nodos distintos. Esto es lo que convierte un workflow lineal en un workflow con ramificaciones.
Qué tipo de preguntas puede hacer un IF
El nodo IF puede evaluar cosas muy simples, por ejemplo:
si un campo existe,
si un texto está vacío o no,
si un valor es mayor o menor que otro,
si un texto coincide con algo concreto.
En este capítulo nos quedaremos con condiciones muy sencillas, para centrarnos en el concepto, no en la complejidad.
Idea clave que debes quedarte
👉 El nodo IF no ejecuta ambas ramas. Solo ejecuta una, según el resultado de la condición.
N2. Nodo Set / Edit Fields: preparar los datos antes de decidir
Antes de tomar decisiones en un workflow, hay algo fundamental que conviene entender: 👉 las decisiones se toman sobre datos,y esos datos deben estar claros, limpios y bien estructurados. Ahí es donde entra el nodo Set, también llamado Edit Fields en la interfaz.
Qué es el nodo Set
El nodo Set sirve para crear, modificar o simplificar datos dentro de un workflow.
Con él puedes:
seleccionar solo los campos que te interesan,
renombrar campos,
crear nuevos valores,
eliminar información innecesaria.
No toma decisiones ni ejecuta acciones externas. Su función es preparar la información para los siguientes nodos.
Por qué es tan importante antes de un IF
Muchas APIs o servicios devuelven datos complejos, con muchos campos y estructuras internas.
Si usas esos datos directamente en un IF, el workflow puede volverse:
difícil de leer,
confuso de mantener,
propenso a errores.
El nodo Set te permite decir: "De todo esto, solo me quedo con lo que necesito para decidir”.
Ejemplo conceptual
Imagina que recibes estos datos:
{
"content": "Nunca es tarde para ser quien podrías haber sido.",
"author": "George Eliot",
"length": 52,
"tags": ["inspirational"]
}Con un nodo Set, puedes transformarlos en algo tan simple como:
{
"frase": "Nunca es tarde para ser quien podrías haber sido.",
"autor": "George Eliot"
}Ahora el workflow es mucho más fácil de entender.
Cómo encaja el nodo Set en el flujo
A nivel de estructura, el Set suele colocarse:
Trigger → Fuente de datos → Set → IF
Primero recibes datos, luego los ordenas, y después decides. Este orden es una buena práctica que te ahorrará muchos problemas más adelante.
N3. Merge: volver a unir ramas del workflow (concepto clave)
Cuando introduces decisiones en un workflow usando un IF, ocurre algo natural: el flujo se divide en dos caminos distintos. Hasta aquí todo bien. Pero en muchos procesos reales ocurre otra cosa igual de importante:
👉 después de decidir, el flujo vuelve a unirse. Ahí es donde entra el nodo Merge.
Qué es el nodo Merge
El nodo Merge sirve para volver a unir dos ramas de un workflow en un único flujo. No toma decisiones ni transforma datos complejos.
Su función es puramente estructural: “Después de hacer cosas distintas, seguimos por el mismo camino”.
Cuándo tiene sentido usar Merge
Usarás un nodo Merge cuando:
has tomado una decisión con un IF,
cada rama hace algo distinto,
pero después quieres continuar con el mismo proceso.
Ejemplos muy típicos:
enviar una notificación tanto si pasa una cosa como otra,
guardar resultados finales en un mismo sitio,
continuar con un proceso común tras distintas acciones.
Cómo se ve un Merge en un workflow
Visualmente, el nodo Merge:
tiene dos entradas,
y una única salida.
Cada entrada viene de una rama distinta del workflow.
Idea importante para este capítulo
En este capítulo no vamos a profundizar en todos los modos del Merge. Lo importante ahora es entender el concepto:
👉 ramifico → hago cosas distintas → vuelvo a unir
Caso práctico completo: decidir, actuar y continuar el flujo
En este apartado vamos a unir todas las piezas que hemos visto hasta ahora en un único workflow real y fácil de entender. La idea no es aprender algo nuevo, sino ver cómo encajan IF, Set y Merge trabajando juntos.
Objetivo del workflow
El workflow hará lo siguiente:
Obtiene una frase del día desde una API.
Prepara los datos con un nodo Set.
Decide con un IF si la frase tiene autor o no.
Ejecuta una acción distinta según el caso.
Vuelve a unir el flujo con un Merge para continuar.
Estructura general del workflow
Visualmente, el flujo completo quedará así:
Trigger
↓
HTTP Request
↓
Set (preparar datos)
↓
IF (¿hay autor?)
├─ TRUE → Write Binary File (con autor)
└─ FALSE → Write Binary File (sin autor)
↓
Merge
↓
(siguiente paso común)Este esquema es muy representativo de muchos workflows reales.
Paso 1: Obtener los datos
Partimos de algo que ya conoces:
Un nodo Trigger (Manual, Schedule o el que prefieras).
Un nodo HTTP Request que llama a la API de la frase del día.
Es lo mismo que hicimos en artículo Serie N8N(III) donde hicimos nuestro primer workflow
Method: GET
Hasta aquí, el workflow es lineal y sencillo.
Paso 2: Preparar los datos con Set
Añadimos un nodo Set / Edit Fields justo después del HTTP Request.
En este nodo creamos dos campos simples:
frase → contenido de la frase, para lo cual escribimos como name "frase" y en el campo value arrastramos la frase de la HTTP Request o escribimos directamente "{{ $json.q }}" para asignarle ese valor de todo lo que devuelve el HTTP Request.
autor → autor de la frase, para lo cual escribimos como name "autor" y en el campo value arrastramos la frase de la HTTP Request o escribimos directamente "{{ $json.a }}" para asignarle ese valor.
Con esto conseguimos:
datos claros,
nombres entendibles,
y una estructura perfecta para decidir después.
Este paso no cambia la lógica del workflow, solo lo ordena.
Paso 3: Tomar la decisión con IF
Ahora añadimos el nodo IF después del Set.
La condición es muy simple:
Pregunta: ¿existe el campo autor?
Según el resultado:
TRUE → la frase tiene autor
FALSE → la frase no tiene autor
A partir de aquí, el workflow se divide en dos ramas visibles.
Para esto configuramos la condición en el nodo if con el valor del autor (arrastrando el valor al campo "value1") y como condición String: is not empty.
Paso 4: Ejecutar acciones distintas
En cada rama conectamos un nodo diferente, por ejemplo:
Rama TRUE → guardar la frase en frase_con_autor.json
Para ello usaremos un nodo "Convert to File" y tras este un nodo "Read/Write Files from disk" para guardar el archivo con nombre "frase_con_autor.json". Esto ya lo hicimos en el flujo de trabajo del artículo Serie N8N (III)
Nodo Convert to file
Operation: Convert to JSON
Put Output File in Field: data
Nodo Read/Write Files from Disk
Operation: Write file to disk
File Path and Name: {{'C:\\Users\\josek\\Downloads\\frase_con_autor_' + $now.format('yyyyLLdd_HHmm') + '.json' }}
Rama FALSE → guardar la frase en frase_sin_autor.json
Se igual que la rama TRUE pero cambiando esto:
Nodo Read/Write Files from Disk
File Path and Name: {{'C:\\Users\\josek\\Downloads\\frase_sin_autor_' + $now.format('yyyyLLdd_HHmm') + '.json' }}
No es importante qué acción haces, sino entender que:👉 cada rama puede hacer cosas distintas.
Paso 5: Volver a unir el flujo con Merge
Después de las dos acciones, añadimos un nodo Merge.
Este nodo:
recibe la salida de ambas ramas,
las vuelve a unir,
y permite continuar el workflow con un único camino.
A partir de aquí podrías:
enviar una notificación,
guardar un log,
o simplemente terminar el flujo.
Qué has aprendido con este ejemplo
Con este workflow ya sabes:
preparar datos antes de decidir (Set),
tomar decisiones claras (IF),
crear ramificaciones visuales,
y volver a unir el flujo (Merge).
Este patrón se repite constantemente en automatizaciones reales, desde tareas simples hasta procesos complejos.
Errores comunes al empezar con IF, Set y Merge
Cuando empiezas a trabajar con decisiones en N8N es normal cometer algunos errores. Verlos ahora te ahorrará tiempo y frustración más adelante.
1. Usar IF sin preparar los datos
Uno de los errores más habituales es evaluar directamente datos complejos que vienen de una API.
👉 Solución: Usa siempre un Set / Edit Fields antes del IF para: quedarte solo con los campos necesarios, renombrarlos de forma clara y facilitar la lectura del workflow.
2. Pensar que el IF ejecuta ambas ramas
El nodo IF nunca ejecuta las dos ramas. O sale por TRUE, o sale por FALSE. Nunca por ambas.
Si una rama no se ejecuta, es porque la condición no se ha cumplido, no porque haya un error.
3. Olvidar conectar una de las ramas
A veces se configura correctamente el IF, pero:
la rama TRUE tiene nodos,
la rama FALSE queda vacía (o al revés).
Esto no es un error técnico, pero sí un error lógico si esperabas que algo ocurriera en ambos casos.
4. No entender qué datos llegan a cada nodo
Cuando algo no funciona como esperas, el problema casi siempre está en los datos.
👉 Revisa siempre:
la salida del Set,
qué datos llegan al IF,
qué recibe cada rama antes del Merge.
La sección Executions es tu mejor aliada para esto.
Conclusión
En este capítulo has dado un paso clave en tu aprendizaje de N8N:has pasado de workflows lineales a workflows con lógica y decisiones.
Ahora ya sabes:
preparar datos con Set / Edit Fields,
tomar decisiones con IF,
crear ramificaciones claras,
y volver a unir el flujo con Merge.
Este patrón —preparar → decidir → actuar → continuar— se repite constantemente en automatizaciones reales, desde tareas sencillas hasta procesos complejos de negocio.
Antes de pasar al siguiente capítulo, te recomiendo algo muy concreto: 👉 descarga el workflow de este artículo, ábrelo en tu n8n y...
cambia la condición del IF,
añade un tercer campo en el Set,
modifica una de las ramas,
o elimina el Merge y observa qué ocurre.
Cuanto más experimentes aquí, más fácil será lo que viene después.
🌐 Recursos útiles
🌍 Web oficial de N8N: 👉 https://n8n.io/
📘 Documentación oficial
💙 En Lozkorp
📦 Descargar el workflow del capítulo:
👉 LK_n8n_wf_ControlFlujo.json (Importable directamente en tu N8N)
