How to keep track of every automation your business runs

Ask a business with a dozen automations what they all do, and the honest answer is usually a list of four, a vague memory of two more, and a suspicion that something is still running in an account nobody has opened this year.

That is not carelessness. The tools are built to record how a workflow changed and say nothing about why it exists.

Microsoft describes the endpoint of this in its own governance documentation, and it applies at twelve automations as much as at twelve hundred:

"IT doesn't know what all these apps are intended for or how to support individual apps when the helpdesk is called... those details can't be stored in email conversations."

The platforms give you history, not a register

Between them the major tools ship version history, run history, folders and tags - though not all of them, and not on every plan. All of it is about the workflow's internals. None of it answers the questions that matter when something goes wrong at eight in the morning: what was this for, who decided it, and what stops working if I switch it off.

Worse, on the cheaper plans you may not be able to see the full list at all. Zapier's own help documentation states that only super admins or owners of Team and Enterprise accounts can view every asset in the account. In practice that means Zaps built in a team member's private space are invisible to the owner until somebody goes looking.

There is not always an export, either. An account with a hundred-odd Zaps has no button that produces the list of their names, and no standard way to document what the more complex ones do.

This is the argument for keeping a register outside the tools. It is not paperwork layered on top of software that already knows the answer. It is the only complete list that can exist, because no single platform can see the others and some of them cannot fully see themselves.

What goes wrong without one

The failures are mundane, which is why they persist.

A Zap stops firing and nobody notices for two months, because nothing in the business is set up to notice. Finding out who switched it off, and when, means asking the vendor's support to look inside.

Automations outlive the people who built them, and the billing outlives both. The shape that turns up on every platform's forum is the employee who set up the subscription on a personal card, left, lost access to the account, and is still being charged years later for a company's automations they can no longer even see.

The credentials go the same way. An n8n user asked what happens to workflows authenticated as a departing employee and got the short answer: "if you do Ouath2, and its signed in as you, no, itll die when ur company acc gets deactivated." Every automation signed in as that person stops on their last day, and nobody knows which ones those are until they stop.

And the volume alone defeats memory. Past a few dozen flows, nobody holds in their head what each one does.

The extreme version of this has been folklore in software for decades: the job running on some bank's mainframe that nobody can find the source for, nobody knows the purpose of, and nobody dares switch off in case something breaks. The small-business version of it needs no mainframe and no decades.

Five fields, not sixty-four

There is a large industry of automation governance, and most of its templates are useless at this size. UiPath publishes a register with sixty-four columns, and separately a nine-phase lifecycle. That is a real answer to a real problem, for a company with a thousand employees and an automation department.

The interesting thing is what the registers that are actually enforced by software ask for, because it is tiny. The service catalogues that large engineering organisations run make three or four things mandatory beyond a name: what kind of thing it is, whether it is live, and who owns it. Everything else is optional, and most of it stays empty.

For a business of one to twenty-five people, five fields carry almost all the value:

1. Name that says what it does. Not "Zap 14" or "HTTP Request 3". Good names are documentation. A prefix for the area and a marker for whether it is live or a test costs nothing and survives everything.
2. Purpose, in one plain sentence. What business thing happens because this exists. Microsoft treats a missing description as a formal non-compliant state, which is a heavy-handed way of making the same point.
3. One named owner. A person, not a team. If two people own it, nobody does.
4. Where it runs and what it signs in as. Which account, which credentials, whose login. This is the field that turns a resignation from an outage into a task, and it connects to everything in automation credentials and access.
5. What breaks if it stops, and what to do about it. Microsoft's version of this field asks for a mitigation plan describing what business users do during an outage. It is the only field on this list that requires thinking, and the only one that pays for the register on the day you need it.

Two more, for the handful that turn out to be load-bearing: how you would tell it is still working, and when you last checked. The first is not published as a standard field anywhere, which is a gap rather than a reason to skip it - an automation you cannot verify is one you are trusting on faith, which is the subject of automations that fail silently.

Google's site reliability practice is worth borrowing for the objection that this is over-engineering. Their finding is that writing the procedure down ahead of time produces "roughly a 3x improvement in MTTR as compared to the strategy of 'winging it'". And permission to start badly is the right permission: a minimal note is better than no note, and the dependencies between things can wait until the list of things exists.

Ownership is a process, not a column

Every source that has survived real operations pairs the owner field with something that maintains it. Microsoft's own template asks you to describe not just who has access, but "how joiners/movers/leavers processes are managed", and it detects orphans: an automation whose owner no longer exists in the directory gets flagged for review.

For a small business the same idea fits in two habits. When somebody leaves, their row in the register is a checklist rather than an archaeology project. And once a quarter, the automations nobody has touched get a decision - still needed, or switched off deliberately.

Switching off deliberately deserves the emphasis. Before anything is turned off, somebody has to know who currently depends on it and what the impact is. For a small automation stack the question is not "is anyone using this" but "what will silently stop happening", and the register is where that answer was written down while somebody still remembered it.

What this is worth, honestly

Software teams have a name for concentrated undocumented knowledge, the bus factor: how many people would have to be hit by a bus before nobody could maintain the thing. Most people who have worked on software have felt that number sitting at one, and far fewer have ever seen it written down and discussed. That gap, between how many people feel the exposure and how many have seen it named, is the useful part, and it is the same gap in a business where one person built all the automations and everyone else assumes somebody understands them.

The counter-argument deserves air too. Registers rot. A list nobody updates is worse than no list, because it produces confident wrong answers, and the enterprise version of this, the configuration database with hundreds of fields, has a long record of collapsing under its own weight.

The defence against that is keeping it small enough to maintain in the moment somebody builds something. Five fields can be filled in while the automation is still fresh. Sixty-four cannot, which is why the sixty-four-column version is always immaculate for three months and abandoned by month six.

Where to start

Open whatever you have and list what exists, one line each, before trying to make it good. A spreadsheet is a perfectly respectable register at this size.

Then fill in the owner column, because it is the fastest and it usually surfaces the first surprise: two or three automations whose owner is a person who left, or an account nobody can log into.

Then, only for the ones that would actually hurt, write the last field - what breaks if this stops. Most stacks have three or four of those, and the rest are convenience.

The same list is what a competent handover should hand you, per automation, when somebody builds one for you - see what you should get when an automation is handed over. The register is that document kept for the whole portfolio, and kept current rather than filed once.

If you would rather have someone go through what is running and produce the list with you, that is what the process audit is for: $299, three business days, and a written account of what is worth keeping, fixing or switching off.

Sources

What the platforms provide and what they do not: Zapier on who can view assets in an account.

Field lists worth copying from: Microsoft's Power Platform governance fields, Microsoft's statement of the underlying problem, and, as the contrast case, UiPath's sixty-four-column pipeline and its nine-phase lifecycle. Microsoft notes that its Center of Excellence starter kit is no longer actively maintained, so it is cited here as a documented pattern rather than current tooling.

On writing procedures down before you need them: Google's SRE book on playbooks and MTTR.

What happens without a register: credentials that die with the employee account.