Módulo 1: Por qué versionar tus workflows

3. Los límites de exportar e importar JSON

Siguiente →

Descripción

Al terminar esta lección vas a saber exactamente cómo se exporta e importa un workflow en n8n 2.0 —los menús, los formatos, los atajos— y, más importante, vas a poder explicar por qué esa forma de guardar y compartir JSON, que es lo que casi todo el mundo hace, no es control de versiones. Vas a nombrar las cuatro cosas que el export/import no te da —historial, revisión, rollback y colaboración— y vas a entender el caso real, tomado del foro de n8n, donde la falta de control de versiones llevó a un equipo a abandonar la herramienta.

Esto importa porque el error más común de un automatizador que "sabe que debería versionar" es creer que ya lo hace. Exporta sus workflows, los guarda en una carpeta o en Drive, y siente que tiene el problema resuelto. No lo tiene. Confundir "tengo copias del JSON" con "tengo control de versiones" es la trampa que esta lección desarma, y desarmarla es el paso previo obligatorio para que el Módulo 2 —donde aprendes Git— tenga sentido. Si no ves con claridad qué le falta al export/import, no vas a entender qué viene a resolver Git.

Conexión con el módulo: la lección 1 estableció que tener el archivo no es tener el control, y la lección 2 mostró por qué el mercado paga por el control. Esta lección es la prueba técnica de esa afirmación: te muestra con detalle qué puede y qué no puede la herramienta de export/import que ya usas. Es también el puente hacia las lecciones 4 y 5: para entender por qué copiar y pegar JSON falla, primero hay que ver que el JSON es un archivo de texto (lección 4) y que ese texto tiene partes que se rompen al moverlo (lección 5). Y es la base directa del proyecto de la lección 8, donde vas a exportar order-triage con tus propias manos.

Cómo se exporta e importa un workflow, hoy

Empecemos por lo que sí hace la herramienta, porque hay que conocerla bien para ver dónde se queda corta. En n8n 2.0 hay dos formas de sacar un workflow de tu instancia como JSON, y dos de meterlo.

Exportar a un archivo. Con el workflow abierto en el editor, arriba a la derecha hay un menú de tres puntos (⋯). Al abrirlo aparece la opción Download. Al elegirla, n8n te baja a tu computadora un archivo con extensión .json que contiene el workflow completo: todos sus nodos, cómo están conectados y cómo está configurado cada uno. Ese archivo es el workflow en forma de texto.

Verifica la etiqueta en tu panel. Esta guía se escribió con n8n 2.x a mediados de 2026. n8n publica versiones menores casi cada semana y las etiquetas de la interfaz cambian de vez en cuando —el menú de tres puntos podría estar en otro lugar, o la opción podría llamarse distinto en tu versión—. El concepto no cambia: hay una forma de bajar el workflow como archivo .json. Si no la encuentras con este nombre, búscala en el menú del workflow y confirma en la documentación oficial de tu versión.

Exportar copiando al portapapeles. Hay un atajo aún más rápido. Si en el lienzo seleccionas todos los nodos (por ejemplo con Ctrl+A) y copias (Ctrl+C), n8n pone en tu portapapeles el mismo JSON del workflow. Puedes pegarlo (Ctrl+V) en un mensaje, en un documento, o en el lienzo de otro workflow. Es la forma en que la gente comparte workflows en foros y chats: pega el JSON y del otro lado lo pegan en su n8n.

Importar desde un archivo. En el mismo menú de tres puntos hay una opción Import from File, que te deja elegir un archivo .json de tu computadora y lo carga como un workflow nuevo en tu instancia.

Importar desde una URL o pegando. También hay Import from URL, para traer un workflow publicado en una dirección de internet, y puedes pegar directamente en el lienzo un JSON copiado (Ctrl+V), y n8n lo convierte en nodos.

Eso es todo. Cuatro operaciones, dos de salida y dos de entrada. Es simple, funciona, y es genuinamente útil: así se comparten plantillas, así respaldas un workflow antes de un cambio grande, así mueves un flujo de tu máquina a un servidor. No hay nada malo en la herramienta. El problema no es la herramienta; es creer que la herramienta es algo que no es.

Conviene entender cuándo usar cada forma de exportar, porque no son intercambiables en la práctica. El Download a un archivo .json es lo que vas a usar cuando el destino del workflow sea un repositorio o un respaldo: produce un archivo con nombre, que puedes guardar, versionar y volver a abrir después. El copiar al portapapeles es para el intercambio rápido y efímero: pegarlo en un mensaje, mostrárselo a alguien, moverlo entre dos workflows abiertos. En esta guía, la operación que más vas a usar de aquí en adelante es el Download, porque el archivo es lo que después va a vivir en el repositorio cumbre-automations. Y una advertencia que vale para las dos formas: lo que sale es el workflow tal como está guardado, no necesariamente lo último que tocaste en el editor sin guardar. Antes de exportar, guarda; es el primer tropiezo del que apura el paso.

Tener copias no es tener versiones

Aquí está el nudo de la lección, y conviene decirlo con una imagen antes que con una definición.

Piensa en cómo mucha gente "versiona" un documento importante —una tesis, un contrato, una propuesta— cuando no usa una herramienta de verdad. Guarda el archivo. Al día siguiente, antes de tocarlo, hace una copia: propuesta_v2.docx. Después propuesta_v2_revisada.docx. Después propuesta_FINAL.docx. Después, inevitablemente, propuesta_FINAL_esta_si.docx. Al cabo de un mes tiene catorce archivos con nombres cada vez más desesperados en una carpeta, y si le preguntas "¿qué cambió entre la v2 y la v2 revisada?", tiene que abrir los dos y compararlos a ojo, párrafo por párrafo. Y si dos personas trabajaron la misma propuesta, ahora hay veintiocho archivos en dos carpetas, y juntar el trabajo de ambos es una pesadilla manual.

Esa persona tiene copias. No tiene control de versiones. La diferencia no es de cantidad —tener más copias no la acerca al control—; es de naturaleza. Un montón de fotos sueltas no es una película, por más fotos que junten.

El control de versiones de verdad es un sistema que, en vez de copias con nombres, guarda una historia. Cada vez que guardas un cambio, el sistema registra tres cosas: qué cambió exactamente (hasta la línea), quién lo cambió, y por qué —una nota que tú escribes—. Y guarda esa historia de forma que puedas moverte por ella: ver el estado de hace un mes, comparar dos puntos cualquiera, volver a cualquiera de ellos. Un solo archivo con toda su historia adentro, en vez de catorce archivos sin historia.

Exportar el JSON de tu workflow y guardarlo en una carpeta es, exactamente, propuesta_FINAL_esta_si.json. Es una copia. Puede ser útil como respaldo puntual, pero no es control de versiones, y la diferencia se vuelve dolorosa justo cuando más la necesitas: cuando algo se rompió y tienes que volver atrás, o cuando dos personas tocaron lo mismo.

Ejemplo trabajado: dos personas, un workflow, un archivo perdido

Veamos qué pasa en la práctica, con Cumbre. El equipo de automatización tiene dos personas, a las que vamos a llamar A y B, y las dos pueden tocar el workflow order-triage. No usan control de versiones; usan export/import y una carpeta compartida en la nube. Es lunes.

9:00 — A baja el workflow. A quiere agregar un paso: que los pedidos de clientes nuevos pasen por una validación extra. Abre order-triage en su n8n, hace Download, y empieza a trabajar sobre su copia local.

9:30 — B baja el mismo workflow. Sin saber lo que hace A, B quiere arreglar otra cosa: la llamada al CRM está usando un campo viejo y hay que actualizarla. Abre el mismo order-triage, hace Download, y empieza a trabajar sobre su copia.

10:15 — B termina y sube. B hace su cambio en el editor, prueba que la llamada al CRM funciona, y para "respaldar" hace Download y sube su order-triage.json a la carpeta compartida, reemplazando el que había.

11:00 — A termina y sube. A termina su validación de clientes nuevos, la prueba, y sube su order-triage.json a la carpeta compartida, reemplazando el de B.

Qué esperar de este final: el arreglo del CRM que hizo B desapareció. El archivo que quedó en la carpeta es el de A, que partió del order-triage de las 9:00 —antes del arreglo de B— y no lo incluye. Nadie lo borró a propósito. Nadie recibió un aviso. La llamada al CRM volvió a estar rota, y el equipo se va a enterar el día que un pedido falle en producción, sin ninguna pista de que hubo un cambio que se perdió.

Este patrón tiene nombre: sobrescritura silenciosa (lost update, "actualización perdida"). Es la falla número uno de "versionar con archivos". Y fíjate en lo insidioso que es: cada persona hizo todo bien desde su punto de vista. A construyó y probó. B construyó y probó. Los dos respaldaron. El sistema no falló por descuido; falló porque no había sistema. Copiar archivos no coordina a dos personas; solo les da a las dos la ilusión de que están respaldados.

Ahora compáralo con lo que habría pasado con control de versiones. Cuando A intentara subir su cambio, el sistema le diría: "espera, B ya subió un cambio sobre esta misma base que tú no tienes; no puedo dejarte sobrescribir sin reconciliar primero". A vería el arreglo del CRM de B, lo integraría con su validación de clientes, y subiría los dos cambios juntos. Nada se pierde. Esa reconciliación —se llama merge, y es del Módulo 2— es exactamente lo que el export/import no puede hacer, porque un archivo que reemplaza a otro no sabe nada del otro.

Las cuatro cosas que el export/import no te da

Desmenucemos la afirmación general en las cuatro capacidades concretas que faltan. Vale la pena nombrarlas una por una, porque cada una es una razón distinta y cada una duele en un momento distinto.

1. Historial: no sabes qué cambió ni cuándo ni por qué

Con export/import, cada archivo es un presente sin pasado. Abres order-triage.json y ves cómo está el workflow ahora, pero no cómo llegó a estar así. No hay respuesta a "¿esta condición de más de 5000 pesos, desde cuándo está y quién la puso?". La información no existe en ningún lado: el archivo solo guarda el estado final, no el camino.

El control de versiones guarda el camino. Cada cambio queda como una entrada en una bitácora —un commit, del Módulo 2— con su fecha, su autor y tu nota. Puedes leer la evolución del workflow como quien lee la historia clínica de un paciente: no solo cómo está hoy, sino cada cosa que le pasó y por qué. Cuando alguien pregunte "¿por qué está armado así?", la respuesta está escrita, no en tu memoria.

2. Revisión: no puedes leer un cambio antes de aceptarlo

Cuando B te manda su order-triage.json arreglado y te pide que lo apruebes, ¿qué haces? Tienes dos archivos gigantes de texto y ninguna forma cómoda de ver qué cambió entre uno y otro. Abrirlos lado a lado y buscar la diferencia a ojo es inviable: un workflow mediano son cientos de líneas de JSON, y un cambio de un campo puede estar enterrado en la línea 400.

El control de versiones te da el diff: una vista que resalta exactamente las líneas que cambiaron, lo que se quitó y lo que se agregó, ignorando todo lo que quedó igual. En vez de cientos de líneas, ves tres. Puedes revisar el cambio de un compañero —o de una IA que te ayudó a editar el workflow, tema del Módulo 6— en segundos, y decidir con conocimiento si lo apruebas. Leer un diff de workflow es una habilidad tan central que el Módulo 2 le dedica una lección entera.

3. Rollback: no puedes volver a una versión buena con garantía

Esta es la que más duele. Haces un cambio, lo activas en producción, y algo se rompe. Con export/import, tu plan de recuperación es "reimportar un archivo viejo". Pero, ¿cuál? ¿El de la semana pasada, si te acordaste de bajarlo? ¿Estás seguro de que ese funcionaba? ¿Y si el problema no lo introdujo tu último cambio sino uno de hace tres semanas que nadie notó? Sin historial, el rollback es adivinar.

El control de versiones convierte el rollback en una operación precisa. Como cada versión quedó guardada con su fecha, puedes volver a cualquier punto anterior con la certeza de que es exactamente como estaba ese día. "Vuelve el workflow a como estaba el 3 de marzo a las 14:00" es un comando, no una búsqueda arqueológica en una carpeta. El Módulo 2 y el Módulo 6 tratan el rollback a fondo; por ahora quédate con que sin versionado el rollback es una esperanza, y con versionado es una garantía.

4. Colaboración: no hay forma de que dos personas trabajen sin pisarse

Es lo que viste en el ejemplo de A y B. Con archivos, dos personas que tocan el mismo workflow terminan, tarde o temprano, en una sobrescritura silenciosa. No hay mecanismo que detecte el conflicto ni que fuerce la reconciliación; el que guarda último gana, y el trabajo del otro se evapora.

El control de versiones fue inventado, literalmente, para resolver esto. Coordina a varias personas sobre los mismos archivos: detecta cuando dos cambios chocan, obliga a integrarlos antes de continuar, y mantiene el rastro de quién hizo qué. Es la diferencia entre un equipo y dos personas trabajando en paralelo con los dedos cruzados.

Fíjate en el patrón de las cuatro: historial es el pasado, revisión es el presente antes de aceptar, rollback es deshacer, colaboración es el trabajo en paralelo. El export/import no cubre ninguna de las cuatro, no porque esté mal hecho, sino porque no es para eso. Es una herramienta de transporte —sacar y meter un workflow—, no una herramienta de gestión de la historia. Confundir una con otra es el error que esta lección viene a corregir.

Ejemplo trabajado: el mismo cambio, con archivos y con un diff

Hagamos concreta la diferencia entre "comparar a ojo" y "leer un diff", porque es la que más se subestima. Supón que en order-triage cambias el umbral de revisión manual de 5000 a 3000 pesos. En el JSON exportado, ese cambio vive en algún nodo de decisión, rodeado de mucho contexto. Un fragmento del archivo, antes:

{
  "parameters": {
    "conditions": {
      "number": [
        { "value1": "={{ $json.order_total }}", "operation": "larger", "value2": 5000 }
      ]
    }
  },
  "name": "Route high-value orders",
  "type": "n8n-nodes-base.if",
  "position": [820, 300]
}

Y después del cambio, el mismo fragmento se ve así:

{
  "parameters": {
    "conditions": {
      "number": [
        { "value1": "={{ $json.order_total }}", "operation": "larger", "value2": 3000 }
      ]
    }
  },
  "name": "Route high-value orders",
  "type": "n8n-nodes-base.if",
  "position": [820, 300]
}

Si te doy los dos archivos completos —cada uno con cientos de líneas como estas— y te pido que encuentres el cambio a ojo, vas a tardar y probablemente lo pases por alto: 5000 y 3000 son dos caracteres en un mar de texto idéntico. Ese es el mundo del export/import.

Un diff, en cambio, te muestra solo esto:

-        { "value1": "={{ $json.order_total }}", "operation": "larger", "value2": 5000 }
+        { "value1": "={{ $json.order_total }}", "operation": "larger", "value2": 3000 }

La línea que empieza con - es lo que había; la que empieza con + es lo que quedó. Todo lo demás —los otros trescientos renglones que no cambiaron— el diff lo oculta, porque no aporta. En dos segundos ves qué cambió, dónde y de cuánto a cuánto. Qué esperar cuando aprendas a leer diffs en el Módulo 2: revisar el cambio de un compañero, o el de una IA que editó el workflow por ti, deja de ser una tarea de arqueología y pasa a ser un vistazo. Esa capacidad —imposible con archivos sueltos— es la mitad de por qué el versionado transforma cómo trabaja un equipo.

Guarda una pista de esto para la lección 4: fíjate en el campo position del fragmento, ese [820, 300]. Es la coordenada del nodo en el lienzo. Si mueves el nodo de lugar sin cambiar nada de su lógica, ese número cambia y aparece en el diff como si hubieras modificado algo, aunque el workflow haga exactamente lo mismo. Ese es un ejemplo de campo volátil, y manejar esos campos es lo que separa un diff legible de un muro de ruido. La lección 4 los estudia uno por uno.

El caso del foro: cuando la falta de versiones expulsa

No es teoría. En el foro oficial de la comunidad de n8n aparecen, de tanto en tanto, hilos donde equipos cuentan por qué dejaron n8n o por qué consideraron dejarlo, y entre las razones que se repiten hay una frase concreta: "poor version control" —control de versiones pobre—.

La historia típica detrás de esa frase es más o menos así. Un equipo adopta n8n, construye decenas de workflows, y en algún momento cruza un umbral de complejidad donde la falta de versionado deja de ser una molestia y se vuelve un riesgo. Alguien rompe un workflow crítico y no hay cómo volver atrás con certeza. Dos personas se sobrescriben el trabajo. Nadie puede revisar el cambio de nadie antes de que llegue a producción. Un workflow importante se comporta distinto de un mes atrás y no hay forma de saber qué cambió. El equipo concluye que "n8n no tiene buen control de versiones" y migra a otra herramienta, a veces a costa de meses de trabajo.

Aquí está el matiz honesto, y es importante: en la mayoría de esos casos, el problema no era que n8n no pudiera versionarse; era que el equipo nunca aprendió a hacerlo. Todo lo que ese equipo necesitaba —versionar el JSON con Git, entornos separados, revisión por diff, rollback— se puede hacer con n8n Community, gratis, y es exactamente lo que enseña esta guía. La queja "poor version control" es, en buena medida, una queja sobre una capacidad que estaba disponible y no se usó, porque nadie explicó cómo.

Por eso esta guía existe. No para defender a n8n de una crítica, sino para que tú no seas ese equipo. La diferencia entre "n8n no sirve para equipos serios" y "n8n versionado como cualquier sistema profesional" no es una feature que falte: es el conocimiento que estás adquiriendo ahora. La herramienta de export/import no basta, sí. Pero la solución no es cambiar de herramienta; es sumarle la disciplina que este curso te da.

Errores comunes

Creer que respaldar es versionar (conceptual). Qué pasa: alguien configura una rutina que baja el JSON de todos sus workflows cada noche a una carpeta, y siente que ya tiene control de versiones. Un día necesita saber qué cambió en un workflow entre el martes y el jueves, y descubre que tiene dos archivos idénticos en apariencia sin forma de compararlos, y ninguna nota de qué se tocó. Por qué pasa: "backup" y "version control" se usan como sinónimos, y no lo son. Un backup es una copia por si se pierde el original; el versionado es una historia navegable con motivos. Cómo detectarlo: si tu sistema no puede responder "quién cambió esto y por qué", es backup, no versionado. Cómo corregirlo: los backups tienen su lugar —son la red bajo la red—, pero no reemplazan el versionado. Lo que enseña esta guía a partir del Módulo 2 registra el porqué de cada cambio, no solo el estado final.

Compartir workflows pegando JSON en un chat como método de trabajo (práctico). Qué pasa: un equipo coordina cambios mandándose el JSON del workflow por Slack o correo —"aquí va la versión nueva, péguenla en su n8n"—. Funciona para una plantilla puntual y se vuelve un caos como forma de trabajo continuo: nadie sabe cuál es la versión buena, las credenciales viajan pegadas en el texto, y cada persona tiene una copia distinta. Por qué pasa: pegar JSON es lo más fácil y n8n lo hace cómodo, así que se convierte en hábito. Cómo detectarlo: si la respuesta a "¿cuál es la última versión de este workflow?" en tu equipo es "creo que la que mandó fulano ayer", tienes el problema. Cómo corregirlo: un repositorio compartido reemplaza el chat como fuente de verdad; todos parten del mismo lugar y el sistema coordina los cambios. Es exactamente lo que montas en el Módulo 2 y estructuras en el Módulo 3.

Guardar credenciales al exportar sin darse cuenta (práctico y de seguridad). Qué pasa: alguien exporta un workflow y lo comparte —lo sube a un foro, se lo manda a un cliente— sin revisar que el JSON incluye los nombres y los IDs de las credenciales que usa. Los IDs no son secretos, pero los nombres a veces sí revelan información —"CRM Producción - API Key Principal"—, y si el workflow tiene un nodo HTTP Request importado desde un cURL, puede llevar cabeceras de autenticación con secretos reales dentro del JSON. Por qué pasa: al exportar uno piensa en el workflow, no en lo que arrastra consigo. Cómo detectarlo: abre el JSON exportado y busca las palabras credentials, Authorization, apiKey o token antes de compartirlo. Cómo corregirlo: la documentación oficial lo recomienda explícitamente —quita o anonimiza los nombres de credencial y cualquier cabecera de autenticación antes de compartir un JSON—. El manejo limpio de credenciales fuera del workflow es un tema central de esta guía: lo introduces en la lección 5 y lo resuelves en los Módulos 3 y 4.

Pensar que el problema se arregla cambiando de herramienta de automatización (conceptual). Qué pasa: un equipo golpeado por la falta de versionado concluye que n8n "no sirve para equipos" y evalúa migrar a otra plataforma, asumiendo que la siguiente sí traerá el problema resuelto. Por qué pasa: es más fácil culpar a la herramienta que descubrir la disciplina que faltaba, y la migración se siente como una solución. Cómo detectarlo: si tu diagnóstico es "n8n no tiene versionado" en vez de "no sé versionar n8n", revisa el diagnóstico. Cómo corregirlo: casi todas las plataformas de automatización tienen el mismo límite de fábrica; el versionado serio siempre se agrega con Git alrededor, no viene mágicamente adentro. Aprender a hacerlo aquí te sirve sin importar la herramienta, y te ahorra una migración que probablemente no resolvería nada.

Ejercicios

Ejercicio 1 — Exporta y mira el archivo. Toma cualquier workflow que tengas en tu n8n (o construye uno mínimo con dos nodos). Expórtalo con Download. Abre el archivo .json resultante con un editor de texto y respóndete: ¿cuántas líneas tiene? ¿Podrías, mirándolo, decir en qué se diferencia de una versión que hubieras exportado ayer? ¿Encuentras la palabra credentials en algún lado?

Ver solución

Lo que la mayoría descubre: incluso un workflow simple genera un archivo de decenas o cientos de líneas de JSON, con mucha estructura repetitiva (posiciones de nodos, identificadores, parámetros). Comparar dos de estos a ojo para encontrar un cambio pequeño es, en la práctica, imposible: el cambio de un valor puede estar rodeado de cientos de líneas idénticas.

Sobre credentials: si tu workflow usa algún nodo con credenciales (un HTTP Request, un nodo de Gmail, un AI Agent), vas a encontrar una sección credentials con un nombre y un ID. Ese es justo el campo que estudias en la lección 4 y que se rompe al reimportar en la lección 5.

Por qué funciona: este ejercicio te hace sentir en carne propia el problema de la revisión (capacidad 2). Hasta que no intentas encontrar un cambio a ojo en un JSON real, la afirmación "no se puede revisar sin un diff" es abstracta. Después de intentarlo, es obvia. Guarda este archivo: lo vas a reusar en el proyecto de la lección 8.

Ejercicio 2 — Diagnostica la sobrescritura. Vuelve al ejemplo de A y B. Escribe, en tus palabras, en qué momento exacto se perdió el trabajo de B y por qué el sistema no lo avisó. Después propón, sin usar todavía Git, una regla de proceso manual que el equipo podría seguir para reducir el riesgo, y explica por qué esa regla es frágil.

Ver solución

El trabajo de B se perdió a las 11:00, cuando A subió su archivo y reemplazó el de B. Pero la causa raíz fue anterior: a las 9:30, cuando B bajó una copia y empezó a trabajar en paralelo sin que existiera ningún mecanismo que registrara "hay dos ramas de trabajo sobre la misma base". El sistema no avisó porque una carpeta de archivos no compara contenidos ni conoce la historia: solo guarda el último archivo que llega, encima del anterior.

Una regla manual posible: "avisar en el chat del equipo antes de bajar un workflow para editarlo, y no bajar uno que alguien más anunció que está tocando". Reduce el riesgo, pero es frágil por razones humanas: alguien olvida avisar, dos personas avisan casi al mismo tiempo, alguien está de vacaciones y no ve el mensaje, o el equipo crece y el chat se vuelve inmanejable. Depende de que todos recuerden y respeten una convención, que es exactamente el tipo de garantía que no escala.

Por qué funciona: el ejercicio te muestra que el problema de la colaboración (capacidad 4) no se arregla con disciplina humana, sino con un sistema que hace la coordinación por ti. Esa es, precisamente, la razón por la que Git existe, y por la que "avisar en el chat" nunca fue suficiente en ningún equipo serio.

Ejercicio 3 — Empareja el dolor con la capacidad. Para cada una de estas situaciones, di cuál de las cuatro capacidades ausentes (historial, revisión, rollback, colaboración) es la que falta:

(a) "El workflow se comporta distinto que el mes pasado y nadie sabe qué se tocó." (b) "Mi compañero me pasó una versión nueva y no tengo forma de ver qué cambió antes de aceptarla." (c) "Subí un cambio, rompió producción, y no estoy seguro de cuál archivo viejo funcionaba." (d) "Los dos editamos el mismo workflow ayer y uno de los cambios desapareció."

Ver solución

(a) Historial. El problema es que no existe un registro de qué cambió, cuándo y por qué. Es el pasado sin bitácora.

(b) Revisión. El problema es no poder leer el cambio antes de aceptarlo; falta el diff.

(c) Rollback. El problema es no poder volver con certeza a un estado bueno conocido.

(d) Colaboración. Es la sobrescritura silenciosa: dos cambios en paralelo y ningún mecanismo que los reconcilie.

Por qué funciona: si pudiste emparejar las cuatro sin dudar, ya internalizaste que "no tengo control de versiones" no es un problema único, sino cuatro problemas distintos que aparecen en momentos distintos. Reconocer cuál te está doliendo en cada momento es lo que te permite explicar el valor de versionar con precisión —en una entrevista, o ante un jefe que no ve por qué invertir tiempo en esto—.

Resumen y siguiente paso

En esta lección viste cómo se exporta e importa un workflow en n8n 2.0 —el menú de tres puntos con Download e Import from File, el atajo de copiar y pegar el JSON— y por qué esa herramienta, aunque útil para transportar y respaldar, no es control de versiones. Entendiste que tener copias no es tener versiones: catorce archivos con nombres desesperados no son una historia, igual que un montón de fotos no son una película. Viste, con A y B en Cumbre, cómo el trabajo de una persona desaparece en silencio cuando el equipo "versiona con archivos" —la sobrescritura silenciosa—, y desmenuzaste las cuatro capacidades que el export/import no te da: historial (qué cambió y por qué), revisión (leer un cambio antes de aceptarlo, con un diff), rollback (volver a un estado bueno con garantía) y colaboración (que dos personas no se pisen). Y viste el caso real del foro, donde la queja "poor version control" expulsó equipos que en realidad tenían la solución disponible y gratis, y nunca la usaron.

Antes de avanzar deberías poder: describir las dos formas de exportar y las dos de importar en n8n; nombrar las cuatro capacidades ausentes y un dolor concreto de cada una; y explicar en una frase por qué "respaldar" no es "versionar".

Lo que sigue es abrir el archivo que tanto mencionamos. Hasta aquí hablamos del JSON del workflow como una caja cerrada de "cientos de líneas". La lección 4 la abre: vas a ver qué hay dentro exactamente —los nodos, las conexiones, la configuración, los identificadores, las referencias a credenciales—, y vas a aprender a distinguir los campos estables de los volátiles. Esa distinción no es un detalle técnico: es lo que decide si un diff de tu workflow es legible o es un muro de ruido, y es la base para entender, en la lección 5, exactamente qué se rompe cuando mueves ese archivo de una instancia a otra.

Recursos

← Anterior2. Constructor de workflows vs dueño del sistemaSiguiente →4. Anatomía del JSON de un workflow