Orden de ejecución y merge: por qué las ramas no se ejecutan como piensas

Cuando construyes en n8n un flujo de trabajo que se divide en varias ramas después de un nodo If o Switch, probablemente asumes que estas ramas se ejecutan al mismo tiempo y simplemente vuelven a encontrarse en el nodo Merge. Precisamente esta suposición causa confusión con regularidad, porque n8n no ejecuta las ramas en paralelo en el sentido de simultáneamente, sino en un orden fijo y comprensible. Quien no conoce este orden se sorprende de ejecuciones que parecen ocurrir en el orden equivocado, de llamadas API que se adelantan entre sí, o de un nodo Merge que parece quedarse colgado eternamente.

La buena noticia: la lógica detrás de esto está claramente documentada y se puede predecir de forma fiable con algunas reglas básicas. En este artículo veremos cómo n8n determina el orden de ejecución, qué cambió con la versión 1.0 y qué espera realmente el nodo Merge una vez que hayas entendido su lógica. Así mantienes el control de tus flujos de trabajo, incluso cuando se vuelven más complejos con cada rama adicional.

Dos lógicas de ejecución: v0 (legacy) y v1.0+

Según la documentación oficial sobre Execution Order, n8n distingue entre dos modos de ejecución fundamentalmente diferentes, dependiendo de cuándo se creó un flujo de trabajo:

• v0 (legacy): En los flujos de trabajo creados antes de la versión 1.0, se aplica por defecto la lógica antigua. n8n ejecuta primero el primer nodo de cada rama, después el segundo nodo de cada rama, y así sucesivamente. Las ramas se ejecutan así capa por capa una junto a la otra, no completamente una después de la otra.
• v1.0 y posterior: Desde la versión 1.0, n8n procesa una rama por completo antes de que empiece la siguiente. Una rama se ejecuta así por completo, incluidos todos los nodos que contiene, antes de que n8n pase a la siguiente rama.

Esta diferencia es el origen de la mayoría de los malentendidos. Quien trabaja con un flujo de trabajo más antiguo o reutiliza una plantilla de un tutorial antiguo experimenta un comportamiento distinto al de alguien que construye un flujo de trabajo recién creado en una versión actual de n8n. Según la documentación, ambos modos se pueden ajustar a través de la configuración del flujo de trabajo si necesitas específicamente el otro comportamiento.

Cómo determina n8n el orden de las ramas

Para los flujos de trabajo a partir de la versión 1.0 se aplica una regla fija y comprensible: n8n se orienta por la posición de los nodos en el lienzo. Las ramas se procesan de arriba hacia abajo. Si dos ramas están a la misma altura, decide la posición horizontal, ejecutándose primero la rama de la izquierda.

Esto significa en la práctica: si colocas dos o tres ramas paralelas después de un nodo Switch en tu flujo de trabajo, solo la disposición visual en el lienzo determina qué rama va primero, no el orden en que trazaste las conexiones, ni tampoco ningún ID interno. Esto es especialmente importante cuando ramas individuales tienen efectos secundarios, como accesos de escritura a la misma tabla, actualizaciones del mismo registro CRM o llamadas a la misma API con límite de velocidad. Si una rama se ejecuta antes que la otra, el resultado de la segunda rama puede depender de la primera, incluso si eso no era la intención en el diseño del flujo de trabajo.

El nodo Merge: qué espera realmente

El nodo Merge combina datos de varias fuentes en un solo flujo. En el modo Append se aplica una regla simple pero a menudo pasada por alto: el nodo espera hasta que todas las entradas conectadas hayan sido ejecutadas antes de continuar él mismo. Solo cuando cada entrada ha entregado datos, o explícitamente ningún dato, el nodo Merge produce una salida.

Esto explica dos observaciones frecuentes en la práctica:

• Un nodo Merge que parece colgado en realidad suele estar esperando una rama que aún no ha terminado o que nunca se ejecuta debido a una condición.
• Con flujos de datos de longitud desigual se aplica: los elementos que llegan a la entrada 1 tienen prioridad. Si el nodo Merge recibe, por ejemplo, cinco elementos en la entrada 1 y diez elementos en la entrada 2, procesa solo cinco elementos, porque la entrada 1 marca el límite superior.

Desde la gran renovación del nodo Merge en la versión 0.194.0 y la ampliación a más de dos entradas, así como el modo de consulta SQL en la versión 1.49.0, también es posible fusionar más de dos ramas al mismo tiempo, lo que simplifica notablemente la lógica clásica de dos ramas en flujos de trabajo más grandes. Los detalles sobre todos los modos de fusión, como Append, Combine y Choose Branch, se encuentran en la guía sobre fusión de flujos de datos.

La trampa en flujos de trabajo antiguos: nodo If más Merge

Un comportamiento especialmente traicionero, según la documentación, afecta exclusivamente a los flujos de trabajo con el orden de ejecución legacy v0, es decir, por defecto a todos los flujos de trabajo creados antes de la versión 1.0. Si añades un nodo Merge a una estructura que contiene un nodo If en un flujo de trabajo así, puede ocurrir que se ejecuten ambos flujos de salida del nodo If, aunque el nodo If en realidad solo debía activar uno de los dos caminos. La razón: un flujo de datos activa el nodo Merge, que a su vez también ejecuta el otro flujo de datos, en realidad inactivo.

Este comportamiento se eliminó con la versión 1.0. Quien migra o mantiene un flujo de trabajo antiguo y observa ejecuciones duplicadas inexplicables después de un nodo If, a menudo encuentra aquí la causa. Un cambio al nuevo orden de ejecución en la configuración del flujo de trabajo suele resolver el problema de forma fiable.

Cómo comprobar y ajustar el orden de ejecución

Antes de depurar un flujo de trabajo existente, vale la pena echar un vistazo rápido a la configuración del flujo de trabajo: allí ves qué orden de ejecución está activo actualmente y puedes cambiar entre v0 y v1.0 si es necesario. Para flujos de trabajo nuevos se recomienda por lo general la lógica actual, porque es más predecible y la trampa If-más-Merge descrita no llega a producirse.

Para automatizaciones más complejas con varias ramas paralelas y efectos secundarios, también vale la pena utilizar deliberadamente la disposición del lienzo: coloca la rama que debe ejecutarse primero arriba o a la izquierda, y registra esta intención dentro del propio flujo de trabajo, por ejemplo mediante una nota adhesiva. Así queda comprensible para todo el equipo por qué se eligió exactamente ese orden, y nadie tiene que volver a adivinar la lógica en la próxima reestructuración. Si tus automatizaciones están tan ramificadas que el orden ya no se entiende de un vistazo, te apoyamos con nuestra automatización de n8n para estructurar los flujos de trabajo de forma limpia y comprensible.

Preguntas frecuentes

¿De verdad no se ejecutan las ramas en n8n en paralelo?

No, al menos no en el sentido de ejecución simultánea. En flujos de trabajo a partir de la versión 1.0, n8n procesa una rama por completo antes de que empiece la siguiente, controlado por la posición de los nodos en el lienzo. En flujos de trabajo v0 más antiguos, la ejecución se produce en cambio nodo por nodo, capa por capa, a través de todas las ramas, lo que tampoco es un paralelismo real.

¿Por qué mi nodo Merge parece esperar indefinidamente?

En el modo Append, el nodo Merge espera la ejecución de todas las entradas conectadas. Si una de las ramas anteriores no se completa, por ejemplo porque no se cumple una condición o un nodo genera un error, el nodo Merge nunca recibe una señal de esa entrada y, en consecuencia, no produce salida.

¿Qué ocurre si las dos entradas del nodo Merge entregan un número diferente de elementos?

Los elementos en la entrada 1 tienen prioridad. Si el nodo Merge recibe, por ejemplo, cinco elementos en la entrada 1 y diez en la entrada 2, procesa solo cinco elementos, porque la entrada 1 marca el límite superior del procesamiento.

¿La trampa If-más-Merge también afecta a los flujos de trabajo nuevos?

No. Según la documentación de n8n, este comportamiento se aplica exclusivamente a los flujos de trabajo con el orden de ejecución legacy v0, es decir, por defecto a todos los flujos de trabajo creados antes de la versión 1.0. En los flujos de trabajo creados recientemente con el orden de ejecución actual, este problema ya no se produce.

¿Puedo cambiar posteriormente el orden de ejecución de un flujo de trabajo existente?

Sí. El orden de ejecución se puede cambiar en la configuración del flujo de trabajo. Esto es especialmente útil en flujos de trabajo antiguos y migrados, si observas ejecuciones múltiples inexplicables después de nodos If o Switch y sospechas que la causa está en la lógica v0 obsoleta.