5. Qué cambia y qué se rompe al reimportar

Descripción

Al terminar esta lección vas a poder mirar el JSON de un workflow y señalar, uno por uno, cada campo que se rompería si lo importaras ingenuamente en otra instancia de n8n: los IDs de credencial, los IDs de nodo, los identificadores y URLs de webhook, y las referencias a variables de entorno. Vas a entender por qué "lo exporté y lo importé" es una operación que falla en silencio —sin un error grande que te avise— y qué tienes que controlar para que no te pase.

Esto importa porque es la trampa más costosa de toda la automatización con n8n, y la que más gente aprende a golpes. Mueves un workflow que funcionaba, lo importas en otro lado, ves que todos los nodos llegaron, lo activas confiado, y días después descubre que nunca funcionó de verdad: el agente de IA no tenía credencial, la llamada al CRM apuntaba a la nada, el webhook cambió de dirección y quien lo llamaba ya no lo encuentra. Todo eso pudo evitarse si supieras, antes de mover, exactamente qué se iba a romper. Esta lección te da esa lista.

Conexión con el módulo: la lección 4 te enseñó a leer el JSON y a distinguir campos estables de volátiles, y cerró señalando que algunos volátiles —credentials.id, el id de nodo, el webhookId— son "volátiles peligrosos". Esta lección explica exactamente por qué son peligrosos y qué desastre causan. Es la culminación técnica del argumento de las lecciones 3 y 4: no solo el export/import no versiona (lección 3) y el JSON tiene campos volátiles (lección 4), sino que esos campos volátiles se rompen activamente al mover el workflow. Y es lo que hace indispensable todo lo que viene: separar credenciales del workflow (Módulo 3) y manejar credenciales por entorno (Módulo 4) son, en el fondo, las soluciones al problema que esta lección instala. El proyecto de la lección 8 te pide escribir la "nota de riesgos de portabilidad" que es, básicamente, el resultado de aplicar esta lección a order-triage.

Importar un workflow es como mudar un teléfono viejo

Imagina que te compras un teléfono nuevo y quieres pasar tus marcaciones rápidas del viejo. En el teléfono viejo tenías configurado: marcación rápida 1 = tu mamá, marcación rápida 2 = el trabajo, marcación rápida 3 = tu mejor amigo. Ahora supón que, en vez de copiar los números de teléfono reales, alguien copia solo las etiquetas de las marcaciones: "marcación rápida 1", "marcación rápida 2", "marcación rápida 3".

En el teléfono nuevo, esas marcaciones rápidas están vacías —o peor, ya tenían otros números asignados—. Aprietas "marcación rápida 1" esperando a tu mamá y llamas a un número equivocado, o a nadie. Las etiquetas se copiaron perfectamente. Los números, no. Y el teléfono no te avisa: se ve todo bien, las tres marcaciones están ahí, hasta que aprietas una y llamas a quien no querías.

Eso es, casi exactamente, lo que pasa al importar un workflow. El JSON copia las referencias —"usa la credencial 27", "el nodo tiene el ID tal", "este webhook está en la ruta cual"—. Pero esas referencias significan algo solo en la instancia original. En la instancia nueva, la credencial 27 no existe o es otra cosa; el ID del nodo se regenera; el webhook recibe una dirección nueva. Los nodos llegan todos, se ven perfectos en el lienzo, y el workflow está roto por dentro, sin un solo mensaje de error que te lo diga hasta que lo ejecutas.

Recuerda la idea de la lección 4: el JSON guarda referencias, no secretos ni identidades absolutas. Esa decisión de diseño, buena para la seguridad, es exactamente la que hace que mover un workflow sea peligroso. Lo que se copia bien es el "qué" (qué nodos, cómo conectados, con qué parámetros); lo que se rompe es el "cuál concreto de esta instancia" (cuál credencial, cuál ID, cuál dirección de webhook). Vamos a recorrer los cuatro puntos frágiles, del más común al más sutil.

Punto frágil 1: los IDs de credencial

Este es el que rompe más workflows, con diferencia. Vuelve a la sección credentials de un nodo de order-triage:

"credentials": {
  "httpHeaderAuth": {
    "id": "27",
    "name": "Cumbre CRM - Header Auth"
  }
}

Como viste en la lección 4, ese "id": "27" no es el secreto: es un número que apunta a una credencial guardada en la base de datos de esta instancia. Aquí está el problema al mover: los IDs de credencial se asignan por instancia, en el orden en que las creaste. La credencial 27 de tu instancia es "Cumbre CRM - Header Auth" porque fue la vigésima séptima que creaste. En la instancia de tu compañero, la credencial 27 puede ser la de Gmail, o puede no existir porque él solo creó cinco credenciales, o puede ser la del CRM también pero de una cuenta distinta.

Cuando importas el workflow, pueden pasar tres cosas, todas malas:

1. La credencial 27 no existe en la instancia nueva. El nodo queda apuntando a la nada. Al ejecutar, falla con un error de credencial faltante.
2. La credencial 27 existe pero es otra cosa. El nodo apunta a una credencial equivocada —digamos, la de Gmail en vez de la del CRM—. Al ejecutar, falla de forma confusa, o peor, hace algo con la credencial equivocada.
3. No hay ninguna credencial 27. El campo queda en blanco y n8n te muestra el nodo con un aviso de "seleccionar credencial", que es lo mejor que puede pasar porque al menos es visible.

Fíjate en que order-triage tiene dos credenciales —la del CRM y la del proveedor de IA del nodo AI Agent—, así que este problema lo tiene por partida doble. Y como el nombre (name) sí se copia, el nodo puede verse correcto —dice "Cumbre CRM - Header Auth"— mientras el ID por debajo apunta al vacío. El nombre es la etiqueta de la marcación rápida; el ID es el número que no se copió.

Esta es la razón número uno por la que "lo exporté y lo importé y no funciona" es la queja más común de n8n. Y es también la razón por la que el Módulo 4 dedica lecciones enteras a manejar credenciales por entorno: la solución no es "acordarse de reconfigurar las credenciales a mano cada vez", sino un sistema donde cada entorno tiene sus credenciales con una identidad predecible.

Punto frágil 2: los IDs de nodo

Cada nodo tiene un id —ese "a1b2c3d4-..." que parece código de barras—. n8n lo usa internamente para identificar el nodo de forma única. Cuando importas un workflow en otra instancia, n8n puede regenerar esos IDs: les asigna valores nuevos para garantizar que sean únicos dentro de la instancia de destino.

En la mayoría de los casos, esto no rompe nada visible, y por eso es más sutil que el problema de las credenciales. Recuerda que las conexiones entre nodos se describen por el nombre del nodo, no por su ID (lección 4), así que regenerar los IDs no rompe las flechas del workflow. El flujo sigue funcionando.

¿Por qué importa, entonces? Por dos razones:

Primera, para el versionado. Si los IDs se regeneran cada vez que el workflow pasa por una instancia, el diff entre dos versiones se llena de cambios de id que no significan nada —ruido puro, del que hablamos en la lección 4—. Un workflow que va y viene entre instancias acumula un historial ilegible si no controlas esto. La solución es normalizar (Módulo 3): fijar o ignorar estos IDs para que no ensucien el diff.

Segunda, para las referencias que sí usan IDs. Aunque las conexiones normales usan nombres, hay lugares donde algo puede referirse a un nodo o a un elemento por su ID —ciertas configuraciones internas, algunas expresiones—. Si un ID cambia y algo lo referenciaba por ese ID, esa referencia se rompe. Es raro, pero pasa, y es del tipo de error que cuesta horas encontrar porque no es obvio.

La conclusión práctica: los IDs de nodo no suelen romper el flujo al importar, pero ensucian el historial y son una fuente ocasional de fallas difíciles. Es un "volátil peligroso" de bajo grado, comparado con las credenciales, pero conviene conocerlo.

Verifica el comportamiento en tu versión. Si n8n regenera o preserva los IDs de nodo al importar puede depender de la versión y de cómo importes (archivo, pegado, CLI). No lo des por sentado con base en esta lección: haz la prueba en tu instancia —exporta, importa en otra, y compara los id— y confirma qué hace tu versión. El Módulo 3 vuelve sobre esto con la CLI, que da más control que el import del editor.

Punto frágil 3: los webhooks

Este es el que rompe cosas fuera de n8n, y por eso puede ser el más caro. order-triage empieza con un nodo Webhook: la puerta por donde entran los pedidos. Un webhook es una dirección de internet —una URL— que n8n publica para que un sistema externo la llame. Cuando la tienda en línea de Cumbre registra un pedido, hace una llamada a esa URL, y eso dispara el workflow.

Aquí está la fragilidad. Un nodo Webhook tiene dos cosas relevantes en el JSON:

• Un path —una parte de la URL que tú defines—, por ejemplo "path": "order-triage".
• Un webhookId —un identificador que n8n genera—, ese "f4b9c2a1-..." que viste en el esqueleto de la lección 4.

n8n genera para cada webhook una URL de prueba y una URL de producción. La forma exacta de esa URL depende de la dirección de tu instancia (su dominio) y de estos identificadores. Y ahí está el problema: cuando mueves el workflow a otra instancia, la URL del webhook cambia, porque la instancia nueva tiene otra dirección y puede generar otro identificador.

La consecuencia es la más traicionera de todas: el workflow importado puede funcionar perfectamente si tú lo ejecutas a mano desde el editor, y aun así estar roto para el mundo real, porque el sistema externo —la tienda de Cumbre— sigue llamando a la URL vieja, la de la instancia original. Los pedidos se mandan a una dirección que ya no responde, o que responde con un workflow distinto. Nadie en n8n ve un error: desde adentro, todo se ve bien. El error está afuera, en el sistema que llama a una puerta que se mudó.

Por eso mover un workflow con webhook no es solo "importarlo": es importarlo y actualizar a cada sistema externo que lo llama para que apunte a la URL nueva. Eso es coordinación fuera de n8n, y es justo el tipo de cosa que una nota de riesgos de portabilidad (el proyecto de la lección 8) tiene que dejar anotada, para que nadie lo olvide.

Verifica en tu versión y tu despliegue. Los detalles de cómo se compone la URL de un webhook, si el webhookId se preserva o se regenera al importar, y cómo se comportan las URLs de prueba contra las de producción, dependen de tu versión de n8n y de tu configuración de despliegue (dominio, proxy, ruta base). La documentación confirma que hay una URL de prueba y una de producción por webhook; los detalles finos, confírmalos en tu panel. Lo que no cambia es el concepto: la dirección del webhook está atada a la instancia, y mover el workflow puede cambiarla.

Punto frágil 4: variables de entorno y valores embebidos

El cuarto punto es más silencioso pero igual de real. Un workflow puede depender de valores que viven fuera de sus nodos, o de valores fijos escritos dentro de ellos, y al mover el workflow esos valores no viajan bien.

Variables de entorno. n8n permite que un workflow lea variables del entorno donde corre —por ejemplo, la URL base del CRM podría venir de una variable en vez de estar escrita en el nodo—. La idea es buena: separa la configuración del workflow. Pero significa que el workflow, por sí solo, está incompleto: necesita que la instancia de destino tenga definidas las mismas variables. Si importas el workflow en una instancia que no las tiene, las expresiones que las leen devuelven vacío, y el workflow se comporta raro sin un error claro. (Una nota técnica importante que profundiza el Módulo 3: n8n 2.0 endureció el acceso a variables de entorno desde el nodo Code; hay reglas sobre qué se puede leer y cómo, y conviene no depender de leerlas directamente desde código.)

Valores fijos embebidos. Al revés: a veces la URL del CRM, un umbral, un identificador de cuenta están escritos a mano dentro de un nodo. Esos sí viajan en el JSON —son parte de parameters, un campo estable—. El problema no es que se pierdan, sino que viajan demasiado bien: si en la instancia original ese valor apuntaba al CRM de producción, al importar el workflow en un entorno de prueba sigue apuntando al CRM de producción. Es decir, tu "entorno de prueba" le escribe a los datos reales, que es exactamente lo que no querías. Este es el problema espejo del anterior, y es la razón por la que el Módulo 4 insiste en sacar los valores específicos de entorno fuera de los nodos.

La lección de fondo de este punto: un workflow rara vez es autosuficiente. Depende de credenciales, de variables, de direcciones que viven en el entorno. Mover el JSON mueve el workflow, pero no mueve su entorno, y la diferencia entre los dos es donde se esconden los bugs.

Ejemplo trabajado: order-triage cruza a una instancia nueva

Juntemos los cuatro puntos en una sola historia. El equipo de Cumbre quiere pasar order-triage de la instancia de una persona a un servidor compartido nuevo. Alguien hace Download en la instancia vieja e Import from File en la nueva. Esto es lo que ve, paso a paso, y lo que está pasando por debajo.

Al importar. El workflow aparece completo en el lienzo de la instancia nueva. Los tres nodos —el webhook, la llamada al CRM, el AI Agent— están ahí, conectados con sus flechas, con sus nombres correctos. Qué ve la persona: todo bien. Qué pasó por debajo: n8n importó las referencias, no las credenciales ni la identidad de la instancia. No hubo ningún error grande. Este es el momento del engaño: se ve perfecto.

Al abrir el nodo del CRM. La persona hace doble clic en "Get customer from CRM". El campo de credencial muestra un aviso: la credencial "Cumbre CRM - Header Auth" no está seleccionada, o aparece en rojo. Qué pasó: el "id": "27" apuntaba a una credencial de la instancia vieja que no existe en la nueva. Punto frágil 1.

Al abrir el nodo AI Agent. Lo mismo: la credencial "Cumbre OpenAI - Dev" no está. Qué pasó: el segundo ID de credencial, "id": "14", también quedó huérfano. La persona tiene que recrear las dos credenciales en la instancia nueva y reasignarlas a mano.

Al mirar el webhook. La URL de producción del webhook es distinta de la que tenía en la instancia vieja, porque el servidor nuevo tiene otro dominio. Qué pasó: punto frágil 3. Aunque la persona arregle las credenciales y el workflow funcione al ejecutarlo a mano, la tienda de Cumbre sigue mandando los pedidos a la URL vieja. Hasta que alguien actualice la tienda para que llame a la URL nueva, los pedidos reales no llegan al workflow nuevo.

Al ejecutar a mano, después de arreglar las credenciales. Funciona. Y aquí está la trampa final: la persona concluye "listo, ya migré el workflow", porque lo vio correr. Pero los pedidos reales siguen sin llegar (webhook), y si el servidor nuevo era para pruebas, el workflow todavía apunta al CRM de producción (punto frágil 4). El workflow "funciona" en la demo y está roto en la realidad.

Qué esperar si haces esta migración sin una lista de verificación: vas a arreglar lo visible (las credenciales, porque n8n te las marca en rojo) y a pasar por alto lo invisible (el webhook, los valores de entorno, porque nada te los marca). Con una nota de riesgos en la mano —la lista de esta lección—, revisas los cuatro puntos a propósito y no te queda ninguna sorpresa.

Por qué falla en silencio (y por qué eso es lo peligroso)

Vale la pena nombrar de frente la característica que hace tan costoso este problema: casi nada de esto produce un error en el momento de importar.

Un error ruidoso —una pantalla roja que dice "esto está mal"— es, en el fondo, una bendición: te avisa dónde mirar. El problema del re-import es que es silencioso. El workflow se importa "exitosamente". Los nodos están todos. El lienzo se ve idéntico. Las únicas señales —el aviso de credencial en rojo— solo aparecen si abres cada nodo a mirar, y los otros problemas (webhook, valores de entorno) no dan ninguna señal en absoluto hasta que un pedido real falla, días después, lejos del momento de la importación.

Esa distancia entre la causa (importaste sin verificar) y el síntoma (un pedido se perdió el jueves) es lo que hace el problema tan difícil. Cuando el pedido falla, nadie piensa "ah, es que la migración del lunes no actualizó el webhook"; piensan que hay un bug nuevo, y buscan en el lugar equivocado.

La única defensa contra una falla silenciosa es una verificación proactiva: no esperar a que algo grite, sino revisar a propósito, con una lista, cada punto que sabes que se rompe. Esa lista es el producto de esta lección, y es literalmente lo que vas a escribir en el proyecto del módulo. La disciplina del dueño del sistema no es "arreglar rápido cuando algo falla"; es "verificar antes de que falle, porque sé exactamente qué falla".

Qué hay que controlar para que no pase

Cerremos con la parte constructiva: dado que sabes qué se rompe, ¿qué controlas? Esta lección no te da todavía las soluciones completas —viven en los Módulos 3 y 4— pero sí el mapa de lo que hay que resolver:

• Credenciales fuera del workflow, y recreadas en cada entorno. No dependas de que el ID de credencial coincida entre instancias. Cada entorno (dev/staging/prod) tiene sus propias credenciales, y el workflow se conecta a las del entorno donde corre. Esto es el Módulo 4.
• IDs normalizados para el versionado. Fija o ignora los IDs volátiles al versionar, para que el diff muestre lógica y no ruido de identificadores. Esto es el Módulo 3.
• Webhooks documentados y su re-cableado planificado. Deja anotado qué sistemas externos llaman a cada webhook, para que al mover el workflow sepas a quién avisar de la URL nueva. Parte de la documentación del Módulo 3 y del runbook del Módulo 6.
• Configuración de entorno separada de los nodos. Los valores que cambian entre entornos —URLs, umbrales, identificadores de cuenta— salen de los nodos y entran como configuración del entorno, para que el mismo workflow apunte a prueba en dev y a producción en prod sin editar el JSON. Esto es el Módulo 4.

Verás que las cuatro soluciones son, en el fondo, la misma idea: separar el workflow de su entorno. El JSON describe el "qué hace" de forma portable; todo lo que es "cuál concreto de esta instancia" —credenciales, direcciones, valores— vive aparte, en la configuración del entorno. Cuando esa separación está bien hecha, mover el workflow deja de ser un campo minado. Pero para hacerla bien, primero tenías que saber exactamente qué se rompe, y ahora lo sabes.

Errores comunes

Confiar en que "se importó bien" porque los nodos aparecieron (práctico). Qué pasa: alguien importa un workflow, ve todos los nodos en el lienzo, no ve ningún error, y da la migración por terminada. Días después algo falla en producción y nadie relaciona el fallo con la importación. Por qué pasa: la importación es silenciosa por diseño; la ausencia de un error se confunde con la presencia de éxito. Cómo detectarlo: si tu criterio de "migración exitosa" es "no salió ningún error rojo", tienes este problema. Cómo corregirlo: adopta una verificación proactiva. Después de importar, abre cada nodo con credenciales y confirma que apunta a una credencial válida del entorno nuevo; revisa las URLs de webhook; y ejecuta una prueba real, no solo una a mano desde el editor. "No hubo error" no es "funciona".

Reconfigurar credenciales a mano cada vez, como método (práctico). Qué pasa: alguien aprende que las credenciales se rompen al mover, y su solución es "las reasigno a mano en cada instancia". Funciona una vez, pero no escala: con varios workflows, varios entornos y varias credenciales, la reasignación manual se vuelve un trabajo propenso a errores, y basta olvidar una para tener un bug silencioso. Por qué pasa: es la solución obvia y de corto plazo. Cómo detectarlo: si tu proceso de despliegue incluye el paso "acordarse de reasignar las credenciales", es frágil. Cómo corregirlo: la solución de dueño del sistema es estructural, no manual: credenciales por entorno con una identidad predecible, de modo que el mismo workflow encuentre las credenciales correctas en cada entorno sin intervención. Es el Módulo 4. La reasignación a mano es aceptable como parche puntual, nunca como proceso.

Olvidar los webhooks porque n8n no los marca (práctico). Qué pasa: alguien arregla las credenciales al migrar —porque n8n se las marca en rojo— y se olvida por completo del webhook, porque nada se lo señala. Los pedidos reales dejan de llegar y el problema tarda en descubrirse. Por qué pasa: la atención va a donde hay una señal visible, y el webhook no da ninguna dentro de n8n. Cómo detectarlo: si migraste un workflow con webhook y no actualizaste el sistema externo que lo llama, ya tienes el problema latente. Cómo corregirlo: trata el webhook como parte de la migración, no como un detalle. Anota en tu nota de portabilidad qué sistemas externos llaman a cada webhook y planifica actualizarlos a la URL nueva como parte del despliegue.

Creer que el entorno de prueba es seguro solo por ser "de prueba" (conceptual y peligroso). Qué pasa: alguien monta una instancia "de pruebas", importa ahí un workflow de producción, y lo ejecuta tranquilo pensando que no puede hacer daño. Pero el workflow tenía la URL del CRM real escrita a mano en un nodo, así que su "prueba" le escribió al CRM de producción. Por qué pasa: se asume que la etiqueta "prueba" del entorno cambia el comportamiento del workflow, y no lo hace: el workflow apunta a donde su JSON dice que apunte, sin importar cómo se llame el entorno. Cómo detectarlo: antes de ejecutar un workflow importado en un entorno de prueba, busca en su JSON URLs y credenciales que apunten a sistemas reales. Cómo corregirlo: los valores específicos de entorno tienen que salir de los nodos (Módulo 4). Mientras estén escritos a mano dentro del workflow, "entorno de prueba" es solo un nombre, no una garantía.

Ejercicios

Ejercicio 1 — Caza los campos frágiles. Toma el esqueleto de order-triage de la lección 4 (o tu propio workflow exportado). Haz una lista de cada campo que se rompería o cambiaría al importarlo en otra instancia, y clasifícalo por punto frágil: (1) credencial, (2) ID de nodo, (3) webhook, (4) variable/valor de entorno.

Ver solución

Para el esqueleto de order-triage, la lista es:

• Punto 1 (credenciales): credentials.id = "27" en el nodo del CRM, y credentials.id = "14" en el nodo AI Agent. Dos referencias que quedarían huérfanas.
• Punto 2 (IDs de nodo): los tres id de nodo (11111111-..., 22222222-..., 33333333-...) podrían regenerarse. No rompen el flujo (las conexiones usan nombres), pero ensucian el diff y son un riesgo menor.
• Punto 3 (webhook): el webhookId del nodo Webhook y la URL que produce cambiarían con el dominio de la instancia nueva; hay que re-cablear al sistema externo que llama.
• Punto 4 (valores de entorno): la url del CRM está escrita a mano en parameters (https://crm.example.com/...). Viaja bien, pero apuntaría al mismo CRM sin importar el entorno de destino —peligroso si el destino era de prueba—.

Por qué funciona: si encontraste los dos IDs de credencial y el webhook, ya tienes internalizados los dos puntos que más rompen. La URL escrita a mano es la más fácil de pasar por alto porque no se rompe visiblemente —viaja perfecta— y sin embargo es la que puede hacer que un entorno de prueba toque datos reales. Esa es la trampa del punto 4.

Ejercicio 2 — Explica la falla silenciosa. Un compañero te dice: "importé el workflow, no salió ningún error, así que está bien". Escribe la respuesta que le darías, en tres o cuatro frases, explicando por qué "ningún error" no significa "funciona" en este caso, y qué debería verificar.

Ver solución

Una respuesta posible:

"Que no saliera un error al importar no significa que funcione, porque este tipo de problema falla en silencio. La importación copia las referencias a credenciales, no las credenciales, así que los nodos del CRM y del AI Agent probablemente apuntan a credenciales que en esta instancia no existen —ábrelos y fíjate si el campo de credencial está en rojo—. Además, el webhook tiene una URL nueva, así que aunque el workflow corra bien a mano, el sistema que le manda los pedidos sigue llamando a la dirección vieja. Antes de darlo por bueno, verifica las dos credenciales, la URL del webhook, y haz una prueba de punta a punta, no solo una ejecución manual."

Por qué funciona: la respuesta separa las dos ilusiones —"no hubo error" y "corrió a mano"— de la realidad —"funciona de verdad, de punta a punta"—. Nombrar los puntos concretos (credenciales en rojo, URL del webhook, prueba end-to-end) convierte una advertencia vaga en una lista accionable. Esa es, en miniatura, la nota de riesgos de portabilidad del proyecto.

Ejercicio 3 — Diseña la verificación. Escribe una lista de verificación de cinco pasos que seguirías después de importar cualquier workflow con credenciales y webhook en una instancia nueva, antes de declararlo funcional. Ordénala de lo más probable de romper a lo menos.

Ver solución

Una lista posible:

1. Abrir cada nodo con credenciales y confirmar que apunta a una credencial válida del entorno nuevo (no en rojo, no en blanco). Es lo que más rompe.
2. Recrear o reasignar las credenciales faltantes en el entorno nuevo, verificando que sean las del entorno correcto (prueba en dev, no producción).
3. Anotar la URL nueva de cada webhook y verificar qué sistema externo lo llama, para planificar el re-cableado.
4. Revisar los parameters en busca de valores fijos —URLs, identificadores— que deberían cambiar según el entorno pero no lo hacen automáticamente.
5. Ejecutar una prueba de punta a punta con datos de prueba, no solo una ejecución manual del editor, y confirmar que el resultado es el esperado.

Por qué funciona: el orden importa. Las credenciales van primero porque son lo que más rompe y lo único que n8n te señala. El webhook y los valores fijos van en medio porque son silenciosos. La prueba end-to-end va al final porque es la que confirma que todo lo anterior quedó bien. Esta lista es, esencialmente, el procedimiento que en el Módulo 6 se formaliza como parte del runbook de promoción. Guárdala: la vas a reusar en el proyecto de la lección 8.

Resumen y siguiente paso

En esta lección viste por qué importar un workflow es como mudar solo las etiquetas de las marcaciones rápidas de un teléfono viejo a uno nuevo: las referencias se copian, los valores concretos de la instancia no, y el teléfono no te avisa hasta que aprietas un botón. Recorriste los cuatro puntos frágiles de un re-import: los IDs de credencial (el que más rompe, porque son por instancia y order-triage tiene dos), los IDs de nodo (que no suelen romper el flujo pero ensucian el historial y son una fuente ocasional de fallas), los webhooks (que cambian de URL y rompen a los sistemas externos que los llaman, sin dar ninguna señal dentro de n8n), y las variables y valores de entorno (que o no viajan, o viajan demasiado bien y hacen que un entorno de prueba toque datos reales). Entendiste por qué todo esto falla en silencio —sin un error grande en el momento de importar— y por qué esa distancia entre causa y síntoma es lo que lo hace tan costoso. Y viste el mapa de lo que hay que controlar, que se resume en una idea: separar el workflow de su entorno, la tesis de los Módulos 3 y 4.

Antes de avanzar deberías poder: nombrar los cuatro puntos frágiles y cuál rompe más; explicar por qué "se importó sin error" no significa "funciona"; y describir en una frase por qué separar el workflow de su entorno resuelve el problema de raíz.

Ya tienes el problema completamente diagnosticado: sabes qué es un workflow versionado (lección 1), por qué el mercado lo pide (lección 2), por qué el export/import no basta (lección 3), qué hay dentro del JSON (lección 4) y qué se rompe al moverlo (lección 5). Lo que falta es el marco que ordena todas estas piezas en un solo modelo mental coherente. La lección 6 lo da: workflow como código. Vas a ver por qué el repositorio, y no la instancia de n8n, es la fuente de verdad; cuál es el ciclo de trabajo —editar, exportar, commit, revisar, promover—; y por qué pensar en la instancia como un "runtime" y en el repo como el "source" resuelve de una sola vez el versionado, los entornos y la prueba. Es la lección que convierte cinco problemas en un solo modelo.

Recursos

• Export and import workflows — n8n Docs — la página oficial, con la advertencia explícita sobre nombres e IDs de credencial en el JSON y sobre cabeceras de autenticación en nodos HTTP importados desde cURL.
• Credentials — n8n Docs — cómo n8n gestiona las credenciales por separado del workflow; la base para entender por qué el ID de credencial es por instancia.
• Webhook node — n8n Docs — la referencia del nodo Webhook, incluyendo las URLs de prueba y de producción cuyo cambio al mover el workflow es el punto frágil 3.
• Environment variables — n8n Docs — las variables de entorno de las que un workflow puede depender y que no viajan en el JSON; base del punto frágil 4 y del Módulo 4.
• CLI commands — n8n Docs — la interfaz de línea de comandos para exportar e importar, que da más control que el editor sobre cómo se manejan los IDs; la usas a fondo en el Módulo 3.