6. Names, tags, and workflow inventory

Overview

By the end of this lesson you'll know how to turn a pile of workflows into an operable catalog: one where anyone —you at three in the morning, or whoever replaces you when you go on vacation— can find the right workflow, know what it does and which systems it touches, and say which ones are critical, without opening any of them. You'll learn a naming convention that says what a workflow does and what it touches, how to use tags by criticality and by system —verifying what n8n actually offers and in which plans— and how to keep an inventory as a living document. And you'll understand why "Workflow copy 3 (final)" isn't a minor oversight but an incident waiting to happen.

This matters because there's a size past which a catalog stops fitting in one person's head, and that size is smaller than you'd think —Terra Market's eighteen already exceed it. When a catalog doesn't fit in a head, it has to live outside it, in names and tags that speak for themselves, or it becomes a minefield: nobody knows which of the three similar workflows is the good one, which can be touched, or whether that one nobody recognizes is still needed. The catalog's disorder doesn't feel like a problem until the night of an incident, when you're groping to find which of eighteen workflows is the one that failed, and there it feels like the biggest problem in the world.

Connection with the module: this lesson solves a problem that peeked out in the previous one without a name. In lesson 5 you learned to change a workflow without breaking it, but that takes for granted that you know which one you're touching and what it touches —and in a messy catalog, that isn't guaranteed. Here that gap is closed. Also, the lesson takes two fruits of the previous lessons: the matrix from lesson 3 becomes a criticality tag, and Terra Market's four systems (storefront, erp, carrier, ops) become system tags. And it directly prepares the lesson 8 project, whose first deliverable is exactly this inventory. A note of honesty right away: n8n has organization features —tags, folders, archive— whose names and availability I verified against the official documentation, but some depend on the plan and can change, so where it applies I'll tell you "verify in your panel" instead of over-asserting.

The pharmacy in the dark

Let's start with an image, because it shows the cost of disorder better than any argument.

Picture a household medicine cabinet after ten years without tidying. There are unlabeled bottles, open boxes with loose pills, three different cough syrups —two expired— and a bottle with a handwritten label that can no longer be read. During the day, calmly, you manage: you open, you smell, you read with a magnifying glass, and you find what you're looking for. The problem is that you don't search the medicine cabinet during the day and calmly. You search at three in the morning, with a fever, half asleep, in a hurry. And there, a messy medicine cabinet isn't a nuisance: it's a danger, because the moment you need it is exactly the moment you're least able to decipher it.

A workflow catalog is that medicine cabinet. The day you tidy it is some calm day. The day you're grateful you tidied it is the night of the incident, when order-sync failed and you need to find it, understand what it touches, and decide what to do, with the phone ringing and half asleep. The naming convention, the tags, and the inventory are the medicine cabinet's labels: you don't put them there for the good day, you put them there for the bad night.

From there comes the thesis of the lesson:

A catalog is organized for the worst moment, not the best. The criterion for whether a name or a tag is good isn't whether it serves you today, with all the context in your head, but whether it serves someone without context, in a hurry, in an emergency.

Names that say what they do and what they touch

Let's start with the cheapest and highest-return thing: the workflow's name.

What a good name is. A good workflow name answers two questions without you opening the workflow: what does it do? and what system does it touch?. Notice that Terra Market's catalog already follows this convention, and that's why it reads by itself:

  order-sync          → syncs orders (order) between systems
  inventory-update    → updates (update) the inventory
  shipment-notify     → notifies (notify) about shipments (shipment)
  invoice-issue       → issues (issue) invoices (invoice)
  refund-process      → processes (process) refunds (refund)
  seller-payout       → pays (payout) sellers (seller)

The anatomy is simple: domain noun + action verb, in English, in lowercase, separated by a hyphen. order-sync, not sync-order; the noun first because it's how you group mentally —"everything about orders"— and the verb after because it's what it does. It's the same logic with which you'd name files so they sort themselves: invoice-january, invoice-february, not january-invoice, because you want all the invoices to stay together when sorting alphabetically.

Why in English. Just like code identifiers and field names, the workflow's name is in English for the same reason as always: it's the tech market's convention, and it keeps consistency with the fields (order_id, shipping) that the workflow manipulates. The prose that describes the workflow is in English; its name, also in English.

Why a name matters so much. Because the name is the only thing you see before opening the workflow, and in an emergency the "before opening" is where the decisions get made. In the workflow list, in a Slack alert, in the execution history, in a log —in all those places the name appears and nothing more. A name that says what it does and what it touches turns each of those appearances into useful information. An opaque name turns them into an "I have to open it to know," which multiplied by eighteen and by the rush of an incident is exactly the friction you can't afford.

"Workflow copy 3 (final)": the incident waiting to happen

Now the counterexample, because it teaches more than the rule. We've all seen —or created— names like these:

  Workflow copy 3 (final)
  Untitled workflow 7
  test order thing
  DO NOT DELETE
  Copy of Copy of order-sync
  order-sync-v2-real-this-one

Each of those names is an incident waiting to happen, and it's worth seeing why, one by one, because the mechanism of the damage is always the same:

• "Workflow copy 3 (final)" — it says neither what it does nor what it touches, and the word "final" is a lie we all recognize: it's never the final, there's always a "final 2." On the day of the incident, this tells you nothing.
• "DO NOT DELETE" — it's a cry for help from someone who didn't know what this workflow did but feared it mattered. A name that says "I'm afraid of this" instead of "this does X" is the confession that the catalog already got out of control.
• "Copy of Copy of order-sync" — the worst of all, because it's almost the good name. In a list, next to the real order-sync, which is the one running in production? Which is the copy someone made to test and forgot? At three in the morning you're going to edit one of the two, and there's a 50% chance it's the wrong one.

The damage of these names isn't aesthetic. It's that they make it impossible to distinguish the good workflow from the bad one at the moment of deciding, and that indistinguishability is what turns a small incident into a big one: you don't just have the original failure, now you have the doubt about which one to act on.

The cure has two parts. For the ones that do something: rename them with the convention —what they do, what they touch. For the ones that no longer do anything or are forgotten test copies: they don't live in the limbo of a name, they get archived, which is what we'll see at the end of the lesson. An operable catalog has no "final copies": it has workflows with names and archived workflows, and nothing in between.

Tags: the second dimension

The name says what a workflow does. Tags say how it relates to what you care about: how critical it is and which systems it touches. It's a second dimension of organization that the name can't carry without becoming illegible.

What tags are in n8n. I verified this against the official documentation, because the details matter. In n8n, tags are marks you put on a workflow from the editor with the + Add tag option, and you can put several on the same workflow. In the workflow list you can filter by tag to see only the ones you're interested in. There's a documented detail worth keeping in mind: tags are global to the whole instance —if you edit or delete a tag, the change affects all users— and usually only the instance owner can delete tags. The documentation doesn't set a limit on how many tags you can have; still, the discipline of few and meaningful is best, for what we'll see.

Which tags to put. Two families, and they come directly from what you already built:

Criticality tags, from the matrix in lesson 3:

  crit:critical     the red-corner ones and the infrastructure criticals
  crit:important    the most populated category
  crit:convenience  the calm corner

System tags, from Terra Market's four systems:

  sys:storefront    touches the store
  sys:erp           touches the ERP
  sys:carrier       touches the carrier
  sys:ops           touches the internal database

Notice the prefix (crit:, sys:). It's not decoration: it's what makes the tags group and read as two distinct families instead of a soup of marks. With this, order-sync carries crit:critical, sys:storefront, sys:erp, and sys:ops —it says at a glance that it's critical and that it touches three systems. And the real power appears in the filter: "show me all the crit:critical" gives you, in one click, the list of what to care for first; "show me all the sys:carrier" gives you, on the day the carrier goes down, the exact list of which workflows will be affected. That second query is operational gold: when an external system fails, knowing instantly which workflows depend on it is the difference between a targeted response and a general panic.

The discipline of few tags. The temptation is to tag everything with everything: by team, by frequency, by who made it, by project. Don't. Since tags are global and you share them with the whole team, a taxonomy that grows uncontrolled becomes as useless as having none —nobody remembers whether the tag is urgente, urgent, high, or p1, and you end up with all four. Two clear families with prefixes —criticality and system— cover 90% of the value. Add a third only if it solves a concrete question you ask often, and remember: each new tag is an agreement of the whole team, not a note of yours.

A note on folders, with honesty about plans. n8n also offers folders to organize workflows in a hierarchy, and they're useful when the catalog grows a lot. But here I have to be careful with what I assert: according to the documentation, folders require a paid plan or a registered Community edition (registering your instance with an email to receive a free license that enables them). They're not available in just any instance. And there's a detail that matters for the rest of the ecosystem, even though we won't develop it here: some tools that process workflows by folder have their own rules. My practical recommendation: start with names and tags, which work in any instance, and adopt folders only if your plan has them and your catalog is already so big that tags aren't enough. Verify in your panel whether you have them available before designing your organization around them.

Worked example: tagging Terra Market's catalog

Let's tag the eighteen, to see how the organization emerges from the work you already did. The criticality and system columns come straight from the matrix in lesson 3 and the landscape in lesson 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

What to expect. With the catalog tagged like this, queries appear that used to be impossible and now are a filter:

• "All the crit:critical" → six workflows. It's your priority list for modules 2 through 7, in one click.
• "All the sys:erp" → nine workflows touch the ERP. That number is a finding in itself: the ERP is the system your operation depends on most, so its credential (module 5) and its performance (module 6) matter more than it seemed. The day the ERP has problems, you know half the catalog is affected.
• "crit:critical and sys:carrier" → none. Interesting: nothing critical depends directly on the carrier, which is precisely the most unstable system. That's reassuring and it's information you didn't have until you crossed the two families.

Notice that we didn't invent the tags: we harvested them. The criticality was already in the matrix; the systems were already in the landscape. Tagging was just writing into the workflow what you'd already decided, so the knowledge lives in the tool and not in your head. That transfer —from your head to the tool— is the entire purpose of the lesson.

The inventory as a living document

Names and tags live inside n8n. The inventory lives outside, and both things are necessary for a reason: there's information about each workflow that n8n doesn't store and that you need, and there's a value in having the whole catalog in a single document that can be read, discussed, and inherited without entering the instance.

What the inventory is. A table, in the place where your team keeps its operational documentation, with one row per workflow and the columns that matter for operating. It combines what you already have with what only lives outside n8n:

WORKFLOW INVENTORY — Terra Market — production
Updated: <date>   ·   Inventory owner: <name>

| Workflow      | What it does (1 line)          | Crit.     | Systems          | Owner             | Promise                        | Notes |
|---------------|--------------------------------|-----------|------------------|-------------------|--------------------------------|-------|
| order-sync    | new order → creates it in erp   | critical  | storefront,erp,ops| ops director      | 99% in erp in < 5 min          | peak 21:00 |
| inventory-update| stock erp → storefront ea/15min| important | erp,storefront   | sales director    | stock < 30 min stale, 99%      | watch the pattern, not the run |
| shipment-notify | carrier event → customer email| important| carrier          | support director  | 98% in < 10 min, no duplicates | enemy: duplication |
| ...           | ...                            | ...       | ...              | ...               | ...                            | ... |

Notice which columns are here and not in n8n: the owner (a person, from lesson 2 —n8n has no "who answers for this to the business" field), the measurable promise (from lesson 2), and the operational notes (the 21:00 peak, the duplication enemy —the knowledge that's only in your head and has to come out of there). The inventory is where that tacit knowledge becomes explicit.

Why "living." An inventory made once and filed away lies within weeks: a new workflow is published and it's not there, an owner changes and the old one stays, a workflow is retired and it keeps appearing. An inventory that lies is worse than having no inventory, because it gives false confidence —someone consults it in an emergency, acts on what it says, and what it says is no longer true. "Living" means three concrete things: it has a last-updated date (so whoever reads it knows how old it is), it has someone responsible for maintaining it (a person, same logic as the owners), and it gets updated as part of publishing or retiring a workflow, not as a separate task that never comes.

The analogy. An inventory is like the evacuation map taped behind the door of a hotel room. Nobody looks at it while everything is fine. But it has to be up to date —if they remodeled and moved the exit, the old map doesn't just fail to help, it sends people into a wall. An outdated evacuation map is more dangerous than none, because people trust it precisely when they can't verify it. The inventory is the same: its entire value depends on it being true on the day someone needs it, and that day is never announced.

Where it lives. Not on your machine. In the place where the team keeps its operational documentation —the same one where the module 8 runbooks will live. An inventory that only exists on the operator's laptop disappears when the operator changes jobs, and with it disappears the only map of the catalog. That it lives where the team sees it isn't tidiness: it's what makes it survive your absence, which is the subject of module 8 and the ultimate point of all this work.

Archive, don't delete

I'll close with a small decision that prevents disasters: what to do with a workflow that's no longer needed.

The temptation is to delete it. Don't do it right away. n8n has, according to the official documentation, an Archive feature that replaced the old "delete" action as the default option, precisely to prevent accidental deletions. Here's how it works:

• Archiving hides the workflow from the list by default, but doesn't destroy it. It stops appearing, stops getting in the way, but it's still there.
• Archived workflows are seen by activating the Show archived workflows option in the list filter.
• From there you can Unarchive to recover it, or —if you're sure— delete it permanently.

The operational rule is simple: archive first, delete later —or never. When you're unsure whether a workflow is still needed —the one nobody recognized in the lesson 1 exercise, the forgotten test copy, the one created for a process that changed— don't delete it: archive it. If in three months nobody missed it, then delete it with peace of mind. Archiving is reversible; deleting is irreversible, and you already know from lesson 3 how much extra care everything irreversible deserves.

This solves, along the way, the problem of the "DO NOT DELETE" and the "final copies": those workflows don't need a scared name to protect them, they need to be archived. A workflow you're afraid to delete is a perfect candidate for archiving —it disappears from view without being lost— and if it turns out it was needed, you unarchive it and now you give it a decent name.

Common mistakes

Naming for today-you instead of for anyone-in-an-emergency (conceptual). What happens: you put names that make total sense with the context you have in your head right now —temp, new, Juan's one— because today you know perfectly what they refer to. Six months later, or for another person, those names say nothing. Why it happens: you name from your present context, which is abundant, and forget that the name will be read from future contexts where that context doesn't exist. How to catch it: read your names imagining that someone who just joined the team sees them, at three in the morning. If any requires you to be there to explain it, this is it. How to fix it: apply the thesis test —a good name serves someone without context and in a hurry. order-sync passes the test; Juan's one doesn't, especially once Juan no longer works there.

Tagging everything with everything (practical). What happens: you discover the power of tags and tag each workflow by criticality, system, team, frequency, project, author, and mood. The taxonomy grows, synonyms appear (erp, ERP, sys:erp), and the filter stops being reliable because nobody remembers which tag to use. Why it happens: adding a tag is easy and feels productive, and since they're global, the whole team inherits the disorder without anyone deciding it. How to catch it: if you have more than a handful of distinct tags, or two that mean almost the same thing, this is it. How to fix it: two families with prefixes —crit: and sys:— and discipline not to add a third without a concrete question that justifies it. Fewer well-defined tags are worth more than many ambiguous ones, especially when they're global.

An inventory that lies (practical, and the most treacherous). What happens: an excellent inventory gets made, saved, and never touched again. New workflows don't get in, owners change, retired ones stay listed. Someone consults it in an emergency months later and acts on false information. Why it happens: making the inventory is a project with a visible end; maintaining it is an endless task that competes with everything else and always loses. How to catch it: look at the last-updated date of your inventory. If it's from months ago, it already lies about something. How to fix it: tie the maintenance to an event that already happens —"updating the inventory is part of publishing or retiring a workflow," not a separate task— give it a visible date and a person responsible. And accept the hard rule: an outdated inventory gives false confidence, so if you're not going to maintain it, better that whoever reads it knows it's old. The visible date is the honest minimum.

Exercises

Exercise 1 — Rename the junk pile. Here are five real names of the type that appears in inherited instances. For each one, say what information it's missing and propose a name with the convention (noun-verb, in English), inventing a plausible purpose if needed. Then say which of the five you would not rename but archive, and why.

  1. Workflow copy 3 (final)
  2. slack test
  3. Copy of order-sync
  4. daily thing
  5. DO NOT DELETE - important!!

Exercise 2 — Design your tag taxonomy. For your catalog (or Terra Market's), define the tags you would use. Write the complete list of tags with their prefix, and for each family justify in one sentence what operational question being able to filter by it answers. Then decide whether you would add a third family besides criticality and system, and defend your decision.

  crit:critical / crit:important / crit:convenience
      → answers: "what do I have to care for/fix first?"
  sys:storefront / sys:erp / sys:carrier / sys:ops
      → answers: "if this external system fails, which workflows are affected?"

Exercise 3 — Build your inventory. Take your catalog (or Terra Market's) and build the inventory with the columns from the lesson: what it does, criticality, systems, owner, promise, notes. Complete it as best you can. Then answer three questions: how many rows have the "owner" column empty or with your name?, how many have an operational note that was only in your head?, and where are you going to store this document so it survives your absence?

Summary and next step

In this lesson you made the catalog operable. With the image of the pharmacy in the dark the thesis landed: a catalog is organized for the worst moment, not the best, and a tag or a name is good if it serves someone without context, in a hurry, in an emergency. You learned the naming convention —domain noun + action verb, in English— that says what a workflow does and what it touches without opening it, and you saw why "Workflow copy 3 (final)" and "Copy of order-sync" are incidents waiting to happen: they make the good workflow indistinguishable from the bad one precisely when you have to decide. You set up two families of tags with prefixes —crit: from the matrix and sys: from the four systems— verified against the documentation (global to the instance, filterable, deletable only by the owner), and you saw the power of crossing them: nine workflows touch the ERP, nothing critical depends on the carrier. With honesty about plans, you left folders as an option to verify (they require a paid plan or a registered Community edition). You built the inventory as a living document —with the columns n8n doesn't store: owner, promise, tacit notes— and you understood that its entire value depends on it being true on the day someone needs it, like the hotel's evacuation map. And you learned to archive instead of delete: reversible first, irreversible later or never.

Before moving on you should be able to: name a workflow with the convention and justify why an opaque name is an operational risk; design two families of tags tied to concrete questions; and explain what makes an inventory "living" and why an outdated one is worse than none.

Lesson 7 goes up a level and looks outward: the shared responsibility map. Now that you know what workflows you have, what they do, and what systems they touch, the question is where your responsibility ends and the provider's or the external system's begins. What n8n Cloud guarantees and what it doesn't; what's yours in self-hosted; and the uncomfortable case every operator faces sooner or later: the erp went down, it wasn't your fault, and the customer calls you anyway. You'll learn to document that boundary before you need it, verifying what the providers say officially and without making up guarantees no one signed.

Resources

• Tag workflows — n8n Docs — how to create, apply, filter, rename, and delete tags; and the key detail that they're global to the instance and only the owner can delete them. The verified reference for this lesson.
• Manage workflows — n8n Docs — the workflow-management index, with settings, version history, export and import, and sharing. The starting point for organizing a catalog.
• Workflow history — n8n Docs — where, besides the history, the archive and unarchive action lives in recent versions. Verify in your instance where exactly the Archive option appears, because the interface evolves.
• Organize your workspace with Folders — n8n Community — the official announcement of folders, useful for verifying availability and plan requirements before adopting them. Remember: they require a paid plan or a registered Community edition.
• n8n Docs — the general reference. The availability of folders and other organization features by plan is worth verifying in your panel, because it changes; this lesson teaches the criterion, not a fixed snapshot of the interface.