What is an automation hub, and what does it fix?

An automation hub is a central place recording what automations exist, what each does, who owns it, what it connects to, and whether it is still running. Some are products; many are a well-maintained table.

The problem it addresses is one of accumulation. Automations are cheap to create and nobody removes them, so an estate that was eleven useful things becomes two hundred, of which perhaps ninety do anything and perhaps forty do the same thing as something else.

What we'll cover

• The accumulation problem
• Duplication, which is the expensive part
• What the catalogue should record
• Finding what already exists
• Decommissioning
• Reuse, which sounds better than it works
• Intake without a queue
• Monitoring an estate rather than an automation
• Where CodeWords fits
• What to get right first
• Frequently asked questions

The accumulation problem

Creating an automation is cheap, which is the point and the cause.

Nothing prompts removal. An automation for a process that ended keeps running, consuming quota, holding credentials, and occasionally doing something nobody wants.

Ownership evaporates. The builder moves team, and the automation continues with nobody responsible for it.

Nobody can answer basic questions. How many automations touch the billing system, which ones would break if we changed this field, what is currently writing to that spreadsheet.

The cost is not the licence. It is the credentials nobody rotates, the rate limit budget consumed by things nobody uses, and the changes that cannot be made because nobody knows what depends on them.

Estates reach this state quietly, in about two years, without anybody making a bad decision.

Duplication, which is the expensive part

The finding that most surprises people running their first census.

The same problem gets solved repeatedly by different teams who did not know the first one existed.

Near-duplicates are worse than exact ones. Four automations doing almost the same thing, differing in one condition each, mean four things to maintain and four subtly different behaviours.

Duplicate writers are the dangerous case. Two automations updating the same field produce a value that depends on ordering, and the resulting bug is intermittent and nearly impossible to diagnose without knowing both exist.

Duplicate readers are merely wasteful, consuming rate limit budget on identical data.

Finding duplication requires the catalogue, which is the main practical argument for keeping one — you cannot notice that two things overlap if you cannot see both.

What the catalogue should record

Seven fields, and more than that tends to go unmaintained.

What it does, in a sentence a non-builder can understand.

Who owns it, a named person, not a team mailbox.

What it connects to, on both sides, which is what makes impact assessment possible.

What triggers it — a schedule, an event, a webhook, a person.

When it last ran, which is how you find the dead ones.

What breaks if it stops, briefly, which is the field that determines how much attention it deserves.

Its criticality, classified by consequence rather than by complexity.

The connection field is the one that earns its keep. "What would this change break" is the question nobody can answer, and it is answerable from that column alone.

Finding what already exists

The census, which always finds more than expected.

Ask each team, which finds the ones people remember.

Read the platforms. Whatever runs your automations can list them, and that list is more complete than anybody's memory.

Look at the credentials. Service accounts and API keys point at integrations nobody registered, and a credential with no known consumer is a finding in itself.

Check the scheduled jobs, in every system that has them, since automations hide in places nobody thinks of as automation platforms.

Look at inbound webhooks configured in third-party systems, which is where the forgotten ones live.

Expect the first census to take a week and to surface things that have been running for years with no owner, quite possibly including one nobody can explain.

Decommissioning

The capability a hub exists to enable, and the one nobody exercises.

Identify candidates by last run and by last change. Something that has not run in six months is probably done.

Check what would notice. The connection field answers this, which is why it is worth maintaining.

Disable before deleting, for a month, and see whether anybody complains. This is the safe, boring, effective method.

Announce it. A short note naming what is being turned off, with a date, catches the one person who depended on it.

Keep a record of what was removed and when, because something will break in two months and this is the first thing to check.

Make it routine. A quarterly pass takes an hour and prevents the estate reaching the state where nobody dares touch anything.

Reuse, which sounds better than it works

Worth being honest, since reuse is the usual justification for a hub and the weakest part of the case.

Genuine reuse is rare. Two automations that look similar usually differ in ways that matter, and generalising them produces something more complex than either.

Shared connections are the exception, and they are a real win: one authorised connection per system, used by many automations, means one credential to rotate and one place to see consumption.

Templates beat libraries. A starting point somebody copies and adapts works; a shared component that several automations depend on becomes a coupling nobody wanted.

Patterns beat both. Knowing the house way to handle retries, errors, and notifications spreads without creating dependencies.

Do not build a reuse programme. Build the catalogue, and reuse happens where it genuinely fits because people can now see what exists.

Intake without a queue

Approval before building recreates the bottleneck that made people build their own automations.

Register on creation instead, ideally automatically from the platform, so the catalogue is a by-product rather than a task.

Check for an existing one at the point of request, which is where the catalogue saves the most effort.

Review by consequence. Something touching money or customers warrants a look; something tidying one person's inbox does not.

Make registering valuable — support, monitoring, a shared connection — so people want to be in it.

Publish the catalogue. A hub only a governance team can read is an audit tool; one everybody can search is how duplication stops being created.

Monitoring an estate rather than an automation

Once there are more than a handful, the operational question changes shape.

Silent failure is the dominant risk. An automation that stopped running produces nothing, and nothing is indistinguishable from a quiet week.

Alert on absence. Each automation should be expected to run within a window, and not running is the condition worth reporting.

Report at the estate level, weekly: what ran, what did not, what failed, and what has not run in a month. Per-automation alerting produces noise; an estate summary produces attention.

Route failures to the owner, which is the field the catalogue exists to hold.

Watch aggregate consumption against each third party's rate limit, since limits are usually per organisation and no single automation is responsible for exceeding one.

Track the credential expiry dates centrally, because an expiring token breaks an automation on a date somebody could have known about in advance.

Where CodeWords fits

CodeWords connects to more than 3,000 integrations with connections made once and reused across automations, which keeps the consumption against each system visible in one place rather than spread across separately created credentials.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder, including the exceptions.
3. Connect each system once and reuse the connection.

The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

What to get right first

The census and the connection field. Knowing what exists and what each thing touches is the foundation for everything else — duplication, decommissioning, impact assessment — and none of it is possible without both. The rest of the catalogue can be added later; those two cannot be reconstructed from memory.

Two habits make the difference. Register automatically from the platform where you can, since a registration step people perform manually produces a catalogue of the compliant minority. And run the decommissioning pass quarterly, because an estate nobody prunes eventually reaches the state where every change is risky and nobody can say why.

Frequently asked questions

Is an automation hub a product?

It can be, and it is more often a well-maintained table. The value is in the catalogue being current and searchable rather than in the software, and an expensive tool nobody updates is worse than a spreadsheet somebody does.

What is the most valuable field to record?

What each automation connects to, on both sides. It is what makes "what would this change break" answerable, which is the question nobody can currently answer and the one that blocks changes.

How do I find automations nobody registered?

Read the platforms, check every system's scheduled jobs, look at inbound webhooks configured in third parties, and audit service accounts — a credential with no known consumer is itself a finding.

Why does duplication matter?

Near-duplicates mean several things to maintain with subtly different behaviour, and two automations writing the same field produce a value that depends on ordering — an intermittent bug that is nearly impossible to diagnose without knowing both exist.

How should automations be retired?

Identify candidates by last run, check what would notice, disable rather than delete for a month, announce it with a date, and keep a record. The record is what you check when something breaks two months later.

Is reuse a good reason to build a hub?

The weakest one. Genuine reuse is rare because similar automations differ in ways that matter. Shared connections are the real win — one credential per system to rotate, and consumption visible in one place.

Should there be an approval process?

Not before building, which recreates the bottleneck people were escaping. Register on creation, check for duplicates at the point of request, and review by consequence rather than uniformly.

How do I monitor a large automation estate?

Alert on absence rather than on failure — an automation that stopped produces nothing, which looks like a quiet week. Report at estate level weekly and route individual failures to the recorded owner.

What breaks automations on a predictable schedule?

Expiring credentials. Tracking expiry dates centrally turns a surprise outage into a calendar item, and it is one of the few failure modes you can genuinely prevent rather than detect.

How long does a first census take?

About a week, and it reliably finds things that have been running for years with no owner — usually including at least one nobody can explain. That is the normal outcome rather than a sign of a badly run organisation.

What does a neglected estate actually cost?

Not licences. Credentials nobody rotates, rate limit budget consumed by things nobody uses, and changes that cannot be made because nobody knows what depends on them — the last being the one that eventually stops other work.

Related reading

• Integration platforms
• Citizen development
• Automation triggers