Las nuevas funciones If-else y Merge en Make importan por una razón muy simple: ayudan a dibujar mejor una decisión. Hasta ahora, muchos escenarios trataban como rutas paralelas cosas que, en realidad, solo debían terminar en un único camino. Eso parecía flexible, pero casi siempre dejaba el flujo más cargado, más repetido y más difícil de revisar.

Ese es el cambio que de verdad merece atención. No estamos hablando solo de dos módulos nuevos en el lienzo. Estamos hablando de una forma más clara de separar dos situaciones distintas: cuándo hay que elegir una sola salida y cuándo varias acciones deben ejecutarse a la vez. Mientras esas dos cosas se mezclan, el escenario puede funcionar, pero cuesta más entenderlo y mantenerlo.

Por eso el lanzamiento tiene más fondo de lo que parece. Make ya permitía abrir rutas. Lo que faltaba era una forma más natural de volver a un solo camino cuando la lógica del proceso lo pedía. If-else y Merge cubren precisamente ese hueco. Y al hacerlo, empujan a diseñar con más criterio.

If-else y Merge en Make ponen orden donde antes había mezcla

La mejora no consiste solo en poder hacer algo nuevo. La mejora consiste en poder representar mejor algo que ya pasaba en muchos procesos. Hay decisiones que solo deberían dejar una salida válida. Un ticket no puede tener dos prioridades al mismo tiempo. Un gasto no debería quedar aprobado y pendiente a la vez. Un caso entra por una vía o por otra, pero no por varias a la vez.

Antes, esa lógica muchas veces se resolvía con estructuras que visualmente se parecían más a un reparto de tareas que a una decisión. El flujo seguía adelante, sí, pero lo hacía con una forma menos clara de la necesaria. Ahora Make permite expresar mejor esa diferencia, y eso cambia bastante la calidad de lectura del escenario.

Visto así, el valor de If-else y Merge no está en el efecto visual del lanzamiento. Está en que ayudan a que el lienzo se parezca más a la lógica real del negocio. Y cuando el dibujo se parece más a lo que de verdad pasa, todo lo demás mejora detrás: revisión, mantenimiento y comprensión.

Qué cambia frente al router en Make

Aquí conviene ser muy directo. El router, módulo de rutas paralelas, sirve bien cuando un evento debe disparar varias acciones distintas al mismo tiempo. Por ejemplo, guardar datos en más de un sistema, mandar varias notificaciones o dejar varios rastros operativos a la vez. Su lógica es repartir trabajo.

En cambio, If-else, bloque para elegir una salida, sirve cuando solo una ruta debe continuar. Evalúa condiciones y deja pasar una sola rama. Después, Merge, unión del flujo, permite que ese camino vuelva a quedar unificado para continuar con un tramo común. La lógica aquí no es repartir. Es decidir y seguir.

Esa diferencia «router vs if-else» en make, que en teoría parece obvia, en la práctica se mezcló muchas veces. Y cuando se mezcla, el escenario deja de mostrar con claridad qué parte del proceso es una elección y qué parte es trabajo paralelo real. El resultado puede seguir funcionando, pero ya no se lee con la misma limpieza.

Si quieres probar este tipo de lógica directamente en Make, puedes crear tu cuenta aquí: probar Make.

El problema antiguo no era abrir rutas, era no poder cerrarlas bien

Make llevaba tiempo permitiendo ramificar escenarios. Ese no era el dolor. El dolor aparecía cuando varias ramas condicionales tenían que acabar en una continuación común y no existía una forma nativa y limpia de reconducirlas a un solo camino. Ahí era donde empezaban a aparecer las repeticiones.

Si dos ramas terminaban necesitando el mismo tramo posterior, lo habitual era duplicar módulos al final de cada una o construir soluciones auxiliares para simular una continuidad que el lienzo no ofrecía con naturalidad. Desde fuera, podía parecer un detalle menor. En mantenimiento, no lo era.

El coste real estaba en lo que pasaba después. Cada cambio obligaba a revisar más puntos. Cada corrección exigía comprobar si había otra rama con lógica parecida. Cada lectura del escenario pedía más atención de la que debería. No era un problema espectacular. Era un problema lento, repetitivo y caro de sostener.

Por qué la duplicación era peor de lo que parecía

La duplicación de módulos en make no solo hace un escenario más largo. También lo vuelve menos fiable. Cuantos más puntos equivalentes hay repartidos por ramas distintas, más fácil es tocar uno y olvidar otro. Y cuanto más se repite una misma intención en lugares separados, menos clara queda la lógica de fondo.

Eso tiene una consecuencia operativa bastante directa. El escenario deja de ser una pieza que se entiende de una pasada y pasa a ser una pieza que obliga a inspeccionar ramas para confirmar si la diferencia entre ellas es real o solo es una herencia de cómo se resolvió el flujo en su momento. Ahí es donde el diseño empieza a cansar.

Además, la repetición genera una ilusión peligrosa: como el proceso sigue funcionando, parece que el diseño es aceptable. Pero una cosa es funcionar y otra distinta es estar bien planteado. If-else y merge de rutas en make no arreglan todos los problemas de diseño, pero sí reducen uno de los más frecuentes: repetir estructura donde lo lógico era volver a una sola continuidad.

Ese mismo problema aparece también fuera de Make: cuando falta estructura, la operativa pierde claridad. Se ve bien en este caso sobre trazabilidad en stock, donde el coste real no está en el registro, sino en no poder leer bien el sistema después.

Qué mejora en lectura, mantenimiento y depuración

La primera mejora es visual, pero no superficial. Cuando un bloque muestra que solo una rama puede ganar, el escenario se entiende antes. No hace falta interpretar si varias rutas podrían activarse a la vez o si todo era, en realidad, una sola decisión mal expresada. El flujo gana claridad desde la primera lectura.

La segunda mejora está en el mantenimiento. Si varias ramas condicionales terminan en un mismo tramo común, ese tramo puede vivir después de Merge y no repetirse al final de cada ruta. Eso reduce copia y también reduce la posibilidad de incoherencias cuando el escenario evoluciona.

La tercera mejora aparece en la depuración. Cuando el diseño deja claro que solo una salida puede continuar, revisar por qué pasó algo resulta más predecible. Se estrecha el número de posibilidades y se vuelve más fácil localizar si el problema está en la condición, en el dato de entrada o en la lógica posterior. Menos caminos plausibles casi siempre significa menos tiempo perdido.

Qué no resuelven If-else y Merge, y por qué eso es bueno

Conviene no vender este cambio como una solución total. If-else y Merge no convierten cualquier escenario viejo en un diseño limpio. Tampoco vienen a unir cualquier grupo de rutas de cualquier manera. Su alcance es más concreto, y esa limitación es sana.

Si Merge pudiera coser cualquier topología sin distinción, la plataforma volvería a mezclar cosas que conviene mantener separadas. Una cosa es elegir un camino. Otra muy distinta es repartir tareas que deben correr a la vez. Poner una frontera clara entre ambos casos hace el sistema menos ambiguo.

Puede parecer una renuncia de flexibilidad, pero en realidad es una ganancia de precisión. Y en automatización visual, la precisión de diseño vale más que una libertad aparente que después deja escenarios difíciles de explicar o modificar con seguridad.

Si quieres revisar este cambio desde la fuente, Make ha publicado la documentación oficial de If-else / Merge, donde se ve con claridad qué resuelven y qué límites mantienen.

Cuándo sí conviene migrar un escenario existente

Hay una señal bastante clara para decidirlo: si, en el fondo, ya sabías que solo una rama debía ganar, probablemente tienes un buen candidato para migrar. Estados mutuamente excluyentes, prioridades, umbrales, rutas de aprobación o clasificación operativa suelen entrar en ese grupo.

En esos casos, el beneficio no está solo en ahorrar módulos. Está en dejar más clara la lógica real del proceso. Cuando el flujo refleja mejor lo que el negocio ya estaba diciendo, se vuelve más fácil de leer, explicar y mantener. Esa mejora vale mucho más que el simple efecto de “tener menos piezas”.

Ahora bien, no conviene forzar la migración donde sí hay paralelismo auténtico. Si varias acciones deben ejecutarse de verdad al mismo tiempo y todas son necesarias, el router sigue teniendo sentido. El error no es usar router. El error es usarlo para representar una decisión que nunca fue paralela.

Y si quieres ver cómo este tipo de criterio afecta a un sistema real, aquí hay un ejemplo útil de decisiones exclusivas en automatización aplicado a estados, reintentos y cierre defendible.

Checklist simple para detectar si tu flujo está mal planteado

Bloque 1. Señales de forma

• Solo una ruta debería ganar, pero el escenario deja abiertas varias.
• La continuación del proceso es común, pero está repetida en más de una rama.
• Te cuesta explicar en una frase qué ruta debía ejecutarse y por qué.

Bloque 2. Costes operativos

• Cada cambio pequeño obliga a revisar demasiados puntos.
• La depuración se alarga porque varias trayectorias parecen plausibles.
• El flujo funciona, pero leerlo ya requiere demasiado esfuerzo.

Bloque 3. Señales de criterio

• La lógica del negocio es exclusiva, pero la forma visual no lo refleja.
• Hay más sensación de flexibilidad que claridad real.
• La copia aparece porque el flujo no vuelve con naturalidad a un solo camino.

Si reconoces varias de estas señales, el problema probablemente no está en un detalle aislado. Está en la forma de pensar el flujo. Y ahí es donde If-else y Merge aportan más valor.

Preguntas incómodas antes de celebrar la novedad

Bloque 1. Sobre el problema real

• ¿Tu escenario estaba mal porque faltaba un módulo o porque la lógica estaba mezclada?
• ¿Estabas abriendo rutas porque el proceso lo pedía o porque el lienzo te llevaba ahí?

Bloque 2. Sobre el coste oculto

• ¿Cuánta copia has normalizado solo porque el flujo “ya funciona”?
• ¿Cuánto tiempo se pierde revisando ramas que nunca debieron competir entre sí?

Bloque 3. Sobre la decisión de migrar

• ¿Qué parte de tu escenario es de verdad una decisión y qué parte es paralelismo real?
• ¿Dónde te conviene ganar claridad aunque no cambie demasiado el número total de módulos?

Lo que este cambio dice sobre la madurez de Make

En escenarios pequeños, esta mejora puede parecer solo una comodidad. En escenarios medianos o grandes, ya no lo es. Cuanto más crece un flujo, más se nota la diferencia entre una estructura que solo funciona y una estructura que además se deja revisar con criterio. Ahí es donde este cambio pesa de verdad.

If-else y Merge en Make no son importantes porque el lienzo tenga dos piezas nuevas y llamativas. Son importantes porque introducen una forma más precisa de expresar algo que ya estaba ocurriendo en los procesos: a veces hay que elegir una sola salida, y a veces hay que repartir trabajo. Cuando esa frontera se ve bien, el escenario gana claridad, continuidad y mantenibilidad.

Si al revisar tus escenarios en Make ves que una decisión sigue dibujada como si fueran varias rutas compitiendo a la vez, ya tienes una pista seria sobre dónde empezar a corregir.

Si quieres probar Make por tu cuenta, puedes hacerlo desde aquí: crear cuenta en Make.

Si quieres mirar tus flujos con más criterio y menos copia, este cambio merece bastante más atención de la que parece.