Ask an IT leader who owns the company's automation and you will usually get the name of a platform. Ask who would fix the nightly job that moves records between finance and the CRM if it stopped tonight, and the answer gets slower.
That gap is a key person dependency, and in most organisations it sits entirely outside the register where dependencies are supposed to live. The register tracks the ERP, the data warehouse and the two or three systems procurement signed a contract for. It rarely tracks the forty small workflows that were built by whoever was closest to the problem.
The Automation Nobody Put on the Org Chart
Where These Workflows Come From
They are almost never a project. Somebody in operations gets tired of copying rows between two systems, learns enough of an automation tool to stop doing it by hand, and builds something that works. Then a colleague asks for the same thing. Within a year there are dozens of them.
In our own businesses the people who built the most valuable internal automation were not the engineers we hired for it. They were operations staff who already understood the process and picked up the tool afterwards. That is a genuinely good outcome and I would repeat it. It also means the knowledge lives with individuals rather than with a function.
Why They Never Get Registered
Nothing about these builds triggers the process that would record them. There is no purchase order, no security review and no go-live date. They cost nothing, so finance never sees them. They are not applications, so the CMDB never sees them.
By the time one matters enough to be noticed, it has usually been quietly load-bearing for two years.
What Key Person Dependency Actually Looks Like Here
The Credentials Sit in One Person's Name
The workflow authenticates as a human being. It uses an API key generated from one employee's account, a mailbox they own, or an OAuth grant tied to their login.
Deactivate that account on their last day, which is exactly what a good offboarding process does, and the automation stops. Not loudly. It stops the way these things always stop, which is silently, several hours before anybody connects the outage to the leaver.
Nobody Is Watching the Failure Path
This is the more expensive half, and it is the one I got wrong myself.
We ran a pipeline that depended on an outside service. That service stopped responding one day and returned an error instead of data. The workflow kept running on schedule and kept reporting that it had run. Nothing was watching the specific path where the outside call failed, so the runs looked healthy. By the time anyone noticed, several days of work had been discarded and could not be recovered.
The lesson was not about that vendor. It was that an automation which fails quietly is worse than no automation, because a manual process fails visibly. A person notices they have not done the task. A script does not.
Finding the Dependencies Before They Find You
Inventory by Effect, Not by Tool
Do not start by asking which automation platforms are in use. That question finds the tools you already know about and misses the spreadsheet macro, the scheduled script on someone's machine, and the mailbox rule doing quiet routing.
Ask a different question of each team. What happens automatically in your week that nobody performs? Then ask who would notice first if it stopped. If the honest answer to that second question is a name rather than an alert, you have found one.
Test the Handover Instead of Assuming It
Documentation is the usual answer, and on its own it is not sufficient. Written instructions decay, and they capture the steps while losing the judgement about why the process is built that way.
The test that actually works is cheap. Have someone other than the builder run the recovery once, from the documentation alone, while the builder watches without helping. Whatever that person gets stuck on is the real dependency. It is almost never the part the builder expected to be difficult.
What to Fix First
You do not need to bring every workflow under governance, and attempting it will stall. Three things carry most of the risk.
Move the credentials off individual accounts and onto service accounts the organisation controls. This is unglamorous and it removes the failure mode that offboarding creates.
Require every automated process to answer two questions before it is allowed to matter. How do we find out when this breaks, and what happens to the work while it is broken? A workflow that cannot answer the second question is holding data hostage during every outage.
Then register the ones whose failure would reach a customer. Not all of them, just those. That list is usually far shorter than people expect, and it converts an invisible personal dependency into a tracked organisational one.
The automation itself is not the problem. It is doing real work, often better than the process it replaced. The problem is that it arrived without any of the mechanisms that make other infrastructure survivable, and it is now holding up operations that nobody has written down.