6. Nombres, etiquetas e inventario de workflows

Descripción

Al terminar esta lección vas a saber convertir un montón de workflows en un catálogo operable: uno donde cualquiera —tú a las tres de la mañana, o quien te reemplace cuando te vayas de vacaciones— puede encontrar el workflow correcto, saber qué hace y qué sistemas toca, y decir cuáles son críticos, sin abrir ninguno. Vas a aprender una convención de nombres que dice qué hace un workflow y qué toca, cómo usar etiquetas por criticidad y por sistema —verificando qué ofrece n8n de verdad y en qué planes—, y a llevar un inventario como documento vivo. Y vas a entender por qué "Workflow copia 3 (final)" no es un descuido menor sino un incidente esperando ocurrir.

Esto importa porque hay un tamaño a partir del cual un catálogo deja de caber en la cabeza de una persona, y ese tamaño es más pequeño de lo que uno cree —los dieciocho de Terra Market ya lo superan—. Cuando un catálogo no cabe en una cabeza, tiene que vivir fuera de ella, en nombres y etiquetas que hablen solos, o se vuelve un campo minado: nadie sabe cuál de los tres workflows parecidos es el bueno, cuál se puede tocar, o si ese que nadie reconoce sigue haciendo falta. El desorden del catálogo no se siente como un problema hasta la noche de un incidente, cuando estás buscando a tientas cuál de dieciocho workflows es el que falló, y ahí se siente como el problema más grande del mundo.

Conexión con el módulo: esta lección resuelve un problema que asomó en la anterior sin nombre. En la lección 5 aprendiste a cambiar un workflow sin romperlo, pero eso da por supuesto que sabes cuál estás tocando y qué toca él —y en un catálogo desordenado, eso no está garantizado—. Aquí se cierra ese hueco. Además, la lección toma dos frutos de las lecciones anteriores: la matriz de la lección 3 se vuelve una etiqueta de criticidad, y los cuatro sistemas de Terra Market (storefront, erp, carrier, ops) se vuelven etiquetas de sistema. Y prepara directamente el proyecto de la lección 8, cuyo primer entregable es exactamente este inventario. Una nota de honestidad desde ya: n8n tiene funciones de organización —etiquetas, carpetas, archivar— cuyos nombres y disponibilidad verifiqué contra la documentación oficial, pero algunas dependen del plan y pueden cambiar, así que donde aplique te voy a decir "verifica en tu panel" en vez de afirmar de más.

La farmacia a oscuras

Vamos a empezar por una imagen, porque muestra el costo del desorden mejor que cualquier argumento.

Imagina el botiquín de una casa después de diez años sin ordenar. Hay frascos sin etiqueta, cajas abiertas con pastillas sueltas, tres jarabes distintos para la tos —dos vencidos—, y un frasco con una etiqueta escrita a mano que ya no se lee. De día, con calma, te las arreglas: abres, hueles, lees con lupa, y das con lo que buscas. El problema es que uno no busca en el botiquín de día y con calma. Uno busca a las tres de la mañana, con fiebre, medio dormido, con prisa. Y ahí, un botiquín desordenado no es una molestia: es un peligro, porque el momento en que lo necesitas es exactamente el momento en que menos capacidad tienes de descifrarlo.

Un catálogo de workflows es ese botiquín. El día que lo ordenas es un día tranquilo cualquiera. El día que agradeces haberlo ordenado es la noche del incidente, cuando order-sync falló y necesitas encontrarlo, entender qué toca y decidir qué hacer, con el teléfono sonando y medio dormido. La convención de nombres, las etiquetas y el inventario son las etiquetas del botiquín: no las pones para el día bueno, las pones para la noche mala.

De ahí sale la tesis de la lección:

Un catálogo se organiza para el peor momento, no para el mejor. El criterio de si un nombre o una etiqueta es buena no es si te sirve a ti hoy, con todo el contexto en la cabeza, sino si le sirve a alguien sin contexto, con prisa, en una emergencia.

Nombres que dicen qué hacen y qué tocan

Empecemos por lo más barato y lo de mayor rendimiento: el nombre del workflow.

Qué es un buen nombre. Un buen nombre de workflow responde dos preguntas sin que abras el workflow: ¿qué hace? y ¿qué sistema toca?. Fíjate en que el catálogo de Terra Market ya sigue esta convención, y por eso se lee solo:

  order-sync          → sincroniza pedidos (order) entre sistemas
  inventory-update    → actualiza (update) el inventario
  shipment-notify     → notifica (notify) sobre envíos (shipment)
  invoice-issue       → emite (issue) facturas (invoice)
  refund-process      → procesa (process) reembolsos (refund)
  seller-payout       → paga (payout) a vendedores (seller)

La anatomía es simple: sustantivo del dominio + verbo de la acción, en inglés, en minúsculas, separados por guion. order-sync, no sync-order; el sustantivo primero porque es como agrupas mentalmente —"todo lo de pedidos"— y el verbo después porque es lo que hace. Es la misma lógica con la que nombrarías archivos para que se ordenen solos: factura-enero, factura-febrero, no enero-factura, porque quieres que todas las facturas queden juntas al ordenar alfabéticamente.

Por qué en inglés. Igual que los identificadores de código y los nombres de campo, el nombre del workflow va en inglés por la misma razón de siempre: es la convención del mercado tech, y mantiene la coherencia con los campos (order_id, shipping) que el workflow manipula. La prosa que describe el workflow va en español; su nombre, en inglés.

Por qué importa tanto un nombre. Porque el nombre es lo único que ves antes de abrir el workflow, y en una emergencia el "antes de abrir" es donde se toman las decisiones. En la lista de workflows, en una alerta de Slack, en el historial de ejecuciones, en un log —en todos esos lugares aparece el nombre y nada más—. Un nombre que dice qué hace y qué toca convierte cada una de esas apariciones en información útil. Un nombre opaco las convierte en un "tengo que abrirlo para saber", que multiplicado por dieciocho y por la prisa de un incidente es justo la fricción que no puedes permitirte.

"Workflow copia 3 (final)": el incidente esperando ocurrir

Ahora el contraejemplo, porque enseña más que la regla. Todos hemos visto —o creado— nombres como estos:

  Workflow copia 3 (final)
  Untitled workflow 7
  test order thing
  NO BORRAR
  Copia de Copia de order-sync
  order-sync-v2-real-esta-si

Cada uno de esos nombres es un incidente esperando ocurrir, y vale la pena ver por qué, uno por uno, porque el mecanismo del daño es siempre el mismo:

• "Workflow copia 3 (final)" — no dice qué hace ni qué toca, y la palabra "final" es una mentira que todos reconocemos: nunca es el final, siempre hay un "final 2". El día del incidente, esto no te dice nada.
• "NO BORRAR" — es un grito de auxilio de alguien que no sabía qué hacía este workflow pero temía que importara. Un nombre que dice "tengo miedo de esto" en vez de "esto hace X" es la confesión de que el catálogo ya se salió de control.
• "Copia de Copia de order-sync" — el peor de todos, porque es casi el nombre bueno. En una lista, junto al order-sync verdadero, ¿cuál es el que corre en producción? ¿Cuál es la copia que alguien hizo para probar y olvidó? A las tres de la mañana vas a editar uno de los dos, y hay un 50% de que sea el equivocado.

El daño de estos nombres no es estético. Es que hacen imposible distinguir el workflow bueno del malo en el momento de decidir, y esa indistinguibilidad es lo que convierte un incidente pequeño en uno grande: no solo tienes el fallo original, ahora tienes la duda de sobre cuál actuar.

La cura tiene dos partes. Para los que hacen algo: renómbralos con la convención —qué hacen, qué tocan—. Para los que ya no hacen nada o son copias de prueba olvidadas: no viven en el limbo de un nombre, se archivan, que es lo que veremos al final de la lección. Un catálogo operable no tiene "copias finales": tiene workflows con nombre y workflows archivados, y nada en medio.

Etiquetas: la segunda dimensión

El nombre dice qué hace un workflow. Las etiquetas dicen cómo se relaciona con lo que te importa: qué tan crítico es y qué sistemas toca. Es una segunda dimensión de organización que el nombre no puede cargar sin volverse ilegible.

Qué son las etiquetas en n8n. Verifiqué esto contra la documentación oficial, porque los detalles importan. En n8n, las etiquetas (tags) son marcas que le pones a un workflow desde el editor con la opción + Add tag, y puedes ponerle varias a un mismo workflow. En la lista de workflows puedes filtrar por etiqueta para ver solo los que te interesan. Hay un detalle documentado que conviene tener presente: las etiquetas son globales para toda la instancia —si editas o borras una etiqueta, el cambio afecta a todos los usuarios—, y normalmente solo el dueño de la instancia puede borrar etiquetas. La documentación no fija un límite de cuántas etiquetas puedes tener; aun así, conviene la disciplina de pocas y con significado, por lo que veremos.

Qué etiquetas poner. Dos familias, y salen directamente de lo que ya construiste:

Etiquetas de criticidad, de la matriz de la lección 3:

  crit:critical     los de la esquina roja y los críticos de infraestructura
  crit:important    la categoría más poblada
  crit:convenience  la esquina tranquila

Etiquetas de sistema, de los cuatro sistemas de Terra Market:

  sys:storefront    toca la tienda
  sys:erp           toca el ERP
  sys:carrier       toca al transportista
  sys:ops           toca la base interna

Fíjate en el prefijo (crit:, sys:). No es adorno: es lo que hace que las etiquetas se agrupen y se lean como dos familias distintas en vez de como una sopa de marcas. Con esto, order-sync lleva crit:critical, sys:storefront, sys:erp y sys:ops —dice de un vistazo que es crítico y que toca tres sistemas—. Y el poder real aparece en el filtro: "muéstrame todos los crit:critical" te da, en un clic, la lista de lo que hay que cuidar primero; "muéstrame todos los sys:carrier" te da, el día que el transportista se cae, la lista exacta de qué workflows se van a ver afectados. Esa segunda consulta es oro operativo: cuando un sistema externo falla, saber al instante qué workflows dependen de él es la diferencia entre una respuesta dirigida y un pánico general.

La disciplina de pocas etiquetas. La tentación es etiquetar todo con todo: por equipo, por frecuencia, por quién lo hizo, por proyecto. No lo hagas. Como las etiquetas son globales y las compartes con todo el equipo, una taxonomía que crece sin control se vuelve tan inútil como no tener ninguna —nadie recuerda si la etiqueta es urgente, urgent, high o p1, y acabas con las cuatro—. Dos familias claras y con prefijo —criticidad y sistema— cubren el 90% del valor. Agrega una tercera solo si resuelve una pregunta concreta que te haces seguido, y acuérdate: cada etiqueta nueva es un acuerdo de todo el equipo, no una nota tuya.

Una nota sobre carpetas, con honestidad de planes. n8n también ofrece carpetas (folders) para organizar workflows en una jerarquía, y son útiles cuando el catálogo crece mucho. Pero aquí tengo que ser cuidadoso con lo que afirmo: según la documentación, las carpetas requieren un plan de pago o una edición Community registrada (registrar tu instancia con un correo para recibir una licencia gratuita que las habilita). No están disponibles en cualquier instancia sin más. Y hay un detalle que importa para el resto del ecosistema, aunque no lo desarrollemos aquí: algunas herramientas que procesan workflows por carpeta tienen sus propias reglas. Mi recomendación práctica: empieza por nombres y etiquetas, que funcionan en cualquier instancia, y adopta carpetas solo si tu plan las tiene y tu catálogo ya es tan grande que las etiquetas no alcanzan. Verifica en tu panel si las tienes disponibles antes de diseñar tu organización alrededor de ellas.

Ejemplo trabajado: etiquetar el catálogo de Terra Market

Vamos a etiquetar los dieciocho, para ver cómo la organización emerge del trabajo que ya hiciste. Las columnas de criticidad y sistema salen tal cual de la matriz de la lección 3 y del paisaje de la lección 1:

  Workflow                 crit:            sys:
  ─────────────────────────────────────────────────────────────
  order-sync               critical         storefront, erp, ops
  invoice-issue            critical         erp
  refund-process           critical         erp
  seller-payout            critical         erp
  error-handler            critical         ops
  dead-letter-watch        critical         ops
  shipment-notify          important        carrier
  seller-commission-calc   important        erp, ops
  support-ticket-triage    important        ops
  seller-onboarding        important        erp, storefront
  daily-ops-report         important        ops
  inventory-update         important        erp, storefront
  catalog-sync             important        erp, storefront
  price-sync               important        erp, storefront
  review-sentiment-tag     convenience      ops
  abandoned-cart-reminder  convenience      storefront
  review-request           convenience      storefront
  weekly-sales-digest      convenience      erp

Qué esperar. Con el catálogo así etiquetado aparecen consultas que antes eran imposibles y ahora son un filtro:

• "Todos los crit:critical" → seis workflows. Es tu lista de prioridad para los módulos 2 al 7, en un clic.
• "Todos los sys:erp" → nueve workflows tocan el ERP. Ese número es un hallazgo en sí mismo: el ERP es el sistema del que más depende tu operación, así que su credencial (módulo 5) y su rendimiento (módulo 6) importan más de lo que parecía. El día que el ERP tenga problemas, sabes que la mitad del catálogo se ve afectada.
• "crit:critical y sys:carrier" → ninguno. Interesante: nada crítico depende directamente del transportista, que es justo el sistema más inestable. Eso es tranquilizador y es información que no tenías hasta que cruzaste las dos familias.

Fíjate en que no inventamos las etiquetas: las cosechamos. La criticidad ya estaba en la matriz; los sistemas ya estaban en el paisaje. Etiquetar fue solo escribir en el workflow lo que ya habías decidido, para que el conocimiento viva en la herramienta y no en tu cabeza. Ese traslado —de tu cabeza a la herramienta— es el propósito entero de la lección.

El inventario como documento vivo

Nombres y etiquetas viven dentro de n8n. El inventario vive fuera, y las dos cosas son necesarias por una razón: hay información sobre cada workflow que n8n no guarda y que tú necesitas, y hay un valor en tener el catálogo entero en un solo documento que se puede leer, discutir y heredar sin entrar a la instancia.

Qué es el inventario. Una tabla, en el lugar donde tu equipo guarda su documentación operativa, con una fila por workflow y las columnas que importan para operar. Combina lo que ya tienes con lo que solo vive fuera de n8n:

INVENTARIO DE WORKFLOWS — Terra Market — producción
Actualizado: <fecha>   ·   Responsable del inventario: <nombre>

| Workflow      | Qué hace (1 línea)              | Crit.     | Sistemas         | Dueño             | Promesa                        | Notas |
|---------------|--------------------------------|-----------|------------------|-------------------|--------------------------------|-------|
| order-sync    | pedido nuevo → lo crea en erp   | critical  | storefront,erp,ops| dir. operaciones  | 99% en erp en < 5 min          | pico 21:00 |
| inventory-update| stock erp → storefront c/15min| important | erp,storefront   | dir. comercial    | stock < 30 min viejo, 99%      | mira el patrón, no la corrida |
| shipment-notify | evento carrier → correo cliente| important| carrier          | dir. atención     | 98% en < 10 min, sin duplicados| enemigo: duplicación |
| ...           | ...                            | ...       | ...              | ...               | ...                            | ... |

Fíjate en qué columnas están aquí y no en n8n: el dueño (una persona, de la lección 2 —n8n no tiene un campo "quién responde por esto ante el negocio"), la promesa medible (de la lección 2), y las notas operativas (el pico de las 21:00, el enemigo de la duplicación —el conocimiento que solo está en tu cabeza y tiene que salir de ahí—). El inventario es donde ese conocimiento tácito se vuelve explícito.

Por qué "vivo". Un inventario que se hace una vez y se archiva miente en cuestión de semanas: se publica un workflow nuevo y no está, se cambia un dueño y sigue el viejo, se retira un workflow y sigue apareciendo. Un inventario que miente es peor que no tener inventario, porque da falsa confianza —alguien lo consulta en una emergencia, actúa según lo que dice, y lo que dice ya no es cierto—. "Vivo" significa tres cosas concretas: tiene fecha de última actualización (para que quien lo lea sepa qué tan viejo es), tiene un responsable de mantenerlo (una persona, misma lógica que los dueños), y se actualiza como parte de publicar o retirar un workflow, no como una tarea aparte que nunca llega.

La analogía. Un inventario es como el mapa de evacuación pegado detrás de la puerta de un hotel. Nadie lo mira mientras todo está bien. Pero tiene que estar actualizado —si remodelaron y movieron la salida, el mapa viejo no solo no ayuda, manda a la gente a una pared—. Un mapa de evacuación desactualizado es más peligroso que ninguno, porque la gente confía en él justo cuando no puede verificarlo. El inventario es igual: su valor entero depende de que sea cierto el día que alguien lo necesita, y ese día nunca se anuncia.

Dónde vive. No en tu máquina. En el lugar donde el equipo guarda su documentación operativa —el mismo donde vivirán los runbooks del módulo 8—. Un inventario que solo existe en la laptop del operador desaparece cuando el operador cambia de trabajo, y con él desaparece el único mapa del catálogo. Que viva donde el equipo lo vea no es prolijidad: es lo que hace que sobreviva a tu ausencia, que es el tema del módulo 8 y el sentido último de todo este trabajo.

Archivar, no borrar

Cierro con una decisión pequeña que evita desastres: qué hacer con un workflow que ya no hace falta.

La tentación es borrarlo. No lo hagas de entrada. n8n tiene, según la documentación oficial, una función de archivar (Archive) que reemplazó a la vieja acción de "eliminar" como opción por defecto, precisamente para evitar borrados accidentales. Así funciona:

• Archivar esconde el workflow de la lista por defecto, pero no lo destruye. Deja de aparecer, deja de estorbar, pero sigue ahí.
• Los workflows archivados se ven activando la opción Show archived workflows (mostrar archivados) en el filtro de la lista.
• Desde ahí puedes desarchivar (Unarchive) para recuperarlo, o —si estás seguro— eliminarlo permanentemente.

La regla operativa es simple: archiva primero, borra después —o nunca—. Cuando dudes si un workflow sigue haciendo falta —el que nadie reconoció en el ejercicio de la lección 1, la copia de prueba olvidada, el que se creó para un proceso que cambió—, no lo borres: archívalo. Si en tres meses nadie lo echó de menos, entonces bórralo con tranquilidad. Archivar es reversible; borrar es irreversible, y ya sabes de la lección 3 cuánto cuidado extra merece todo lo irreversible.

Esto resuelve, de paso, el problema de los "NO BORRAR" y las "copias finales": esos workflows no necesitan un nombre asustado que los proteja, necesitan archivarse. Un workflow que da miedo borrar es un candidato perfecto a archivar —desaparece de la vista sin perderse—, y si resulta que sí hacía falta, lo desarchivas y ahora sí le pones un nombre decente.

Errores comunes

Nombrar para ti-de-hoy en vez de para cualquiera-en-una-emergencia (conceptual). Qué pasa: pones nombres que tienen todo el sentido con el contexto que tienes ahora en la cabeza —temp, nuevo, el de Juan— porque hoy sabes perfectamente a qué se refieren. Seis meses después, o para otra persona, esos nombres no dicen nada. Por qué pasa: uno nombra desde su contexto presente, que es abundante, y olvida que el nombre va a leerse desde contextos futuros donde ese contexto no existe. Cómo detectarlo: lee tus nombres imaginando que los ve alguien que acaba de llegar al equipo, a las tres de la mañana. Si alguno requiere que tú estés ahí para explicarlo, es esto. Cómo corregirlo: aplica la prueba de la tesis —un nombre bueno le sirve a alguien sin contexto y con prisa—. order-sync pasa la prueba; el de Juan no, sobre todo cuando Juan ya no trabaja ahí.

Etiquetar todo con todo (práctico). Qué pasa: se descubre el poder de las etiquetas y se etiqueta cada workflow por criticidad, sistema, equipo, frecuencia, proyecto, autor y estado de ánimo. La taxonomía crece, aparecen sinónimos (erp, ERP, sys:erp), y el filtro deja de ser confiable porque nadie recuerda qué etiqueta usar. Por qué pasa: agregar una etiqueta es fácil y se siente productivo, y como son globales, el desorden lo hereda todo el equipo sin que nadie lo decidiera. Cómo detectarlo: si tienes más de un puñado de etiquetas distintas, o dos que significan casi lo mismo, es esto. Cómo corregirlo: dos familias con prefijo —crit: y sys:— y disciplina para no agregar una tercera sin una pregunta concreta que la justifique. Menos etiquetas bien definidas valen más que muchas ambiguas, sobre todo cuando son globales.

Un inventario que miente (práctico, y el más traicionero). Qué pasa: se hace un inventario excelente, se guarda, y no se vuelve a tocar. Los workflows nuevos no entran, los dueños cambian, los retirados siguen listados. Alguien lo consulta en una emergencia meses después y actúa según información falsa. Por qué pasa: hacer el inventario es un proyecto con final visible; mantenerlo es una tarea sin final que compite con todo lo demás y siempre pierde. Cómo detectarlo: mira la fecha de última actualización de tu inventario. Si es de hace meses, ya miente en algo. Cómo corregirlo: ata el mantenimiento a un evento que ya ocurre —"actualizar el inventario es parte de publicar o retirar un workflow", no una tarea aparte—, ponle fecha visible y un responsable. Y acepta la regla dura: un inventario desactualizado da falsa confianza, así que si no vas a mantenerlo, más vale que quien lo lea sepa que está viejo. La fecha visible es lo mínimo honesto.

Ejercicios

Ejercicio 1 — Renombra el basurero. Aquí hay cinco nombres reales del tipo que aparece en instancias heredadas. Para cada uno, di qué información le falta y propón un nombre con la convención (sustantivo-verbo, en inglés), inventando un propósito plausible si hace falta. Luego di cuál de los cinco no renombrarías sino que archivarías, y por qué.

  1. Workflow copia 3 (final)
  2. slack test
  3. Copia de order-sync
  4. daily thing
  5. NO BORRAR - importante!!

Ejercicio 2 — Diseña tu taxonomía de etiquetas. Para tu catálogo (o el de Terra Market), define las etiquetas que usarías. Escribe la lista completa de etiquetas con su prefijo, y para cada familia justifica en una frase qué pregunta operativa responde el poder filtrar por ella. Luego decide si agregarías una tercera familia además de criticidad y sistema, y defiende tu decisión.

  crit:critical / crit:important / crit:convenience
      → responde: "¿qué tengo que cuidar/arreglar primero?"
  sys:storefront / sys:erp / sys:carrier / sys:ops
      → responde: "si este sistema externo falla, ¿qué workflows se afectan?"

Ejercicio 3 — Levanta tu inventario. Toma tu catálogo (o el de Terra Market) y construye el inventario con las columnas de la lección: qué hace, criticidad, sistemas, dueño, promesa, notas. Complétalo lo mejor que puedas. Luego responde tres preguntas: ¿cuántas filas tienen la columna "dueño" vacía o con tu nombre?, ¿cuántas tienen una nota operativa que solo estaba en tu cabeza?, y ¿dónde vas a guardar este documento para que sobreviva a tu ausencia?

Resumen y siguiente paso

En esta lección hiciste operable el catálogo. Con la imagen de la farmacia a oscuras quedó la tesis: un catálogo se organiza para el peor momento, no para el mejor, y una etiqueta o un nombre es bueno si le sirve a alguien sin contexto, con prisa, en una emergencia. Aprendiste la convención de nombres —sustantivo del dominio + verbo de la acción, en inglés— que dice qué hace un workflow y qué toca sin abrirlo, y viste por qué "Workflow copia 3 (final)" y "Copia de order-sync" son incidentes esperando ocurrir: hacen indistinguible el workflow bueno del malo justo cuando hay que decidir. Montaste dos familias de etiquetas con prefijo —crit: de la matriz y sys: de los cuatro sistemas—, verificadas contra la documentación (globales a la instancia, filtrables, borrables solo por el dueño), y viste el poder de cruzarlas: nueve workflows tocan el ERP, ninguno crítico depende del transportista. Con honestidad de planes, dejaste las carpetas como opción a verificar (requieren plan de pago o Community registrada). Levantaste el inventario como documento vivo —con las columnas que n8n no guarda: dueño, promesa, notas tácitas— y entendiste que su valor entero depende de que sea cierto el día que alguien lo necesita, como el mapa de evacuación del hotel. Y aprendiste a archivar en vez de borrar: reversible primero, irreversible después o nunca.

Antes de avanzar deberías poder: nombrar un workflow con la convención y justificar por qué un nombre opaco es un riesgo operativo; diseñar dos familias de etiquetas atadas a preguntas concretas; y explicar qué hace "vivo" a un inventario y por qué uno desactualizado es peor que ninguno.

La lección 7 sube un nivel y mira hacia afuera: el mapa de responsabilidad compartida. Ahora que sabes qué workflows tienes, qué hacen y qué sistemas tocan, la pregunta es dónde termina tu responsabilidad y empieza la del proveedor o la del sistema externo. Qué garantiza n8n Cloud y qué no; qué es tuyo en self-hosted; y el caso incómodo que todo operador enfrenta tarde o temprano: el erp se cayó, no fue culpa tuya, y el cliente igual te llama a ti. Vas a aprender a documentar esa frontera antes de necesitarla, verificando lo que los proveedores dicen oficialmente y sin inventar garantías que nadie firmó.

Recursos

• Tag workflows — n8n Docs — cómo crear, aplicar, filtrar, renombrar y borrar etiquetas; y el detalle clave de que son globales a la instancia y solo el dueño puede borrarlas. La referencia verificada de esta lección.
• Manage workflows — n8n Docs — el índice de administración de workflows, con los ajustes, el historial de versiones, exportar e importar, y compartir. El punto de partida para organizar un catálogo.
• Workflow history — n8n Docs — donde vive, además del historial, la acción de archivar y desarchivar workflows en versiones recientes. Verifica en tu instancia dónde aparece exactamente la opción Archive, porque la interfaz evoluciona.
• Organize your workspace with Folders — n8n Community — el anuncio oficial de las carpetas, útil para verificar disponibilidad y requisitos de plan antes de adoptarlas. Recuerda: requieren plan de pago o Community registrada.
• n8n Docs — la referencia general. La disponibilidad de carpetas y otras funciones de organización por plan conviene verificarla en tu panel, porque cambia; esta lección enseña el criterio, no una foto fija de la interfaz.