Control de versiones en Make: guardar versión con descripción

Make acaba de meter control de versiones de verdad dentro del editor de escenarios. Lo ha contado el propio equipo en la categoría News de su foro oficial, y es una de esas novedades que no sale en ninguna portada pero que te cambia el día cuando llevas unos cuantos escenarios encima.

Lo nuevo son dos cosas pegadas: una opción que se llama Save as version y la posibilidad de ponerle tu propia descripción a cada versión que guardas. Todo dentro del Scenario Builder, sin salir a ningún otro sitio.

Ojo, que esto es más gordo de lo que parece. Vamos por partes.

Qué es exactamente "Save as version"

Hasta ahora, el historial de un escenario de Make era un historial, sí, pero mudo. El propio anuncio lo dice con una frase que me ha hecho reír porque la he vivido: volver atrás en un escenario no debería depender de que te acuerdes de una marca de tiempo.

Y es justo eso. Abrías el historial y veías una lista de momentos. Fechas, horas. Ninguna pista de qué narices habías cambiado en cada uno. Si el escenario se rompió el martes, tenías que ir probando versiones a ver cuál era la de antes del destrozo.

Lo que Make ha añadido es la opción de guardar explícitamente una versión y engancharle una descripción escrita por ti. Según el anuncio del equipo en su foro, la idea es dejar un rastro claro: usar Save as version para adjuntar una descripción concreta al estado guardado y registrar qué cambió.

O sea, pasas de "15:42" a "añadido el filtro de clientes de Polonia antes del módulo de Gmail". La diferencia entre las dos cosas es abismal.

¿Por qué esto importa si tu escenario ya funciona?

Porque tu escenario funciona hasta que lo tocas. Y lo vas a tocar.

Mira, el patrón es siempre el mismo. Montas una automatización, va bien, la dejas corriendo meses. Un día te piden un cambio pequeño. Entras, modificas dos módulos, guardas. A los tres días notas que algo no cuadra en los datos que llegan al final. ¿Qué cambiaste exactamente? Pues ya no te acuerdas, macho. Han pasado tres días y en medio has hecho otras cuarenta cosas.

El anuncio lo formula de una manera que me parece la clave de todo esto: para construir rápido sin perder la confianza en lo que tienes montado, necesitas un historial claro y trazable de qué cambió y por qué.

Ese "y por qué" es la parte que faltaba. Un historial por marca de tiempo te dice cuándo. Una descripción escrita por ti te dice por qué. Y el por qué es lo único que sirve cuando estás intentando entender tu propio escenario de hace cuatro meses.

Si estás empezando y todavía no tienes historial que proteger, esto te suena a problema de rico. Monta tu primer escenario en Make y vuelve a este post dentro de seis meses, cuando tengas ocho automatizaciones vivas y hayas olvidado cómo funciona la mitad.

El final de los escenarios "(copy)"

Esta parte es la que más me ha gustado del anuncio, porque es un vicio que tenemos todos.

Make reconoce negro sobre blanco que probar un flujo nuevo no debería obligarte a construir clones desordenados con "(copy)" en el nombre. Y ahí me ha pillado. Yo he tenido listas de escenarios con tres copias del mismo flujo, numeradas a mano, sin tener ni idea de cuál era la buena. "Pedidos v2". "Pedidos v2 (copy)". "Pedidos v2 (copy) BUENO".

Un desastre absoluto que además te come espacio mental cada vez que abres el panel.

Con versiones guardadas y descritas, la lógica cambia. Trabajas sobre el escenario de siempre, guardas una versión antes de ponerte a experimentar, y si la cosa sale mal vuelves a esa versión. Sin duplicar nada. Sin nombres inventados. Sin la duda de cuál de los tres clones es el que está realmente activo.

Para quien lleva automatizaciones de varios clientes esto pesa todavía más, porque el caos se multiplica por cada cuenta. Si es tu caso, te conté cómo organizar Make para una agencia con varios clientes y el problema de los clones aparecía por todas partes.

La barra de herramientas del editor también cambió

El anuncio de las versiones no viene solo. Make dice que llega junto a la renovación reciente de la barra de herramientas del escenario, y conviene entender las dos cosas juntas porque van de lo mismo.

La barra nueva separa los controles que usas mientras construyes y pruebas de los controles que usas para programar o activar un escenario terminado. La idea que sueltan es mantener juntas las acciones relacionadas, reducir distracciones mientras construyes y activar un escenario solo cuando está listo.

También cuentan que trabajaron con sus Community Champions para probar el cambio antes de sacarlo.

Y tiene sentido, ¿no? Si el editor va a tener un botón de "guardar como versión", ese botón necesita vivir en algún sitio donde no se confunda con el de activar el escenario. Guardar una versión y poner un escenario en producción son dos cosas que no te puedes permitir confundir a las ocho de la tarde con prisa.

¿Qué no dice el anuncio?

Esto es importante y lo digo claro: el anuncio no habla de precios ni de planes.

No dice si las versiones guardadas están disponibles en todos los planes, ni si hay un límite de cuántas puedes conservar, ni cuánto tiempo se guardan. Tampoco menciona nada sobre consumo. Si alguno de esos datos aparece después, no está en lo que ha publicado el equipo a fecha de octubre de 2026.

Así que no te voy a inventar una tabla de límites que no existe. Lo que hay confirmado es la función: guardar versión con descripción propia, dentro del constructor de escenarios. El resto, cuando lo publiquen.

Lo puedes mirar tú mismo en la web oficial de Make (enlace de afiliado: así me ayudas a seguir creando contenido) y en la categoría News de su foro, que es donde van cayendo estos avisos antes que a ningún otro lado.

Qué hacer con esto a partir de hoy

Tres cosas prácticas, porque si no te las digo esto se queda en noticia y no en cambio de costumbre.

Primera: antes de tocar un escenario que funciona, guarda una versión y descríbela. "Estado bueno antes de meter el nuevo filtro". Diez segundos. Te va a salvar una tarde entera algún día.

Segunda: escribe las descripciones como si las fuera a leer otra persona. Porque el tú de dentro de tres meses es, a efectos prácticos, otra persona. "Arreglo" no vale. "Cambio el módulo de Sheets por el de Airtable en el paso 4" sí vale.

Tercera: revisa tu lista de escenarios y mata los clones con "(copy)" que ya no usas. Ahora tienes una forma mejor de hacer lo que ellos hacían mal.

Parece una tontería, pero el control de versiones es una de esas cosas que no valoras hasta el día que lo necesitas con urgencia. Y ese día siempre llega.

¿Te sirve de algo todo esto o todavía estás en la casilla de salida con la IA y la automatización? Hazte el test y sal de dudas: ¿cuál es tu nivel de IA?