October 26, 2026
Every automation you build leaves something behind. A test version you forgot to switch off. A connection to an app your team stopped using two quarters ago. A workflow that has been failing quietly since the day the API changed its field names. None of it feels urgent, because broken automations rarely announce themselves. They just get slower, noisier, and slightly less trustworthy, until someone on your team says "I'll just do it manually, it's faster" — and that is the moment the whole system starts to rot.
The good news is that cleanup is mostly unglamorous detective work, and it goes fast once you have a routine. Here is the checklist worth running through, ideally before your next big build.
Start with an inventory, not a fix
The temptation is to open the first error you see and start patching. Resist it for an hour. You cannot clean up what you have not counted, and most automation platforms will happily give you a full list of every workflow, scenario, or bot in the account.
Export that list into a spreadsheet and add columns for owner, trigger, apps touched, last successful run, last edited, current status, and a short note on what business process it supports. The two most revealing columns are almost always "last successful run" and "owner." Anything running successfully but with no clear owner is a future incident. Anything owned by a person who has changed roles is already one.
If your platform does not offer a one-click export, screenshot the workflow list and transcribe it. It sounds tedious; it takes twenty minutes and it will be the most useful document you make this month.
Find the failed runs
Most tools keep a task history with a filter for errors, and most teams never look at it. Set the window to thirty or ninety days and work through the failures in batches rather than one at a time.
Classify before you retry
Retrying everything feels productive and teaches you nothing. Sort errors into buckets instead: expired credentials, changed field names, rate limits, timeouts, and "the data was empty when the workflow assumed it wouldn't be." That last bucket is usually the largest, and it is a design problem, not a bug. A workflow that breaks whenever a customer leaves the phone field blank is not failing — it is doing exactly what you told it to.
When you find a failure that looks like a one-off, pull the actual payload from that run and check what the data looked like. Nine times out of ten the answer is a shape you didn't anticipate: a list where you expected a single item, a date in a different format, a null where you expected text.
Hunt down duplicate actions
Duplicates are the silent tax on automation. The symptoms are familiar: three Slack messages for one order, two near-identical rows in the CRM, a customer who receives the same onboarding email twice. The cause is almost always one of three things — a copied workflow someone edited instead of replacing, a second automation listening to the same trigger, or a test version left running alongside the live one.
To find them, sort your inventory by destination app and action type. Any trigger that feeds the same destination twice deserves a look. Then search your workflow names for words like "test," "copy," "v2," "new," and the initials of whoever built it. This single search surfaces an embarrassing amount of duplication.
When you consolidate, pick one owner for each trigger. If two workflows genuinely need to react to the same event, make that deliberate and document it, rather than discovering it through a customer complaint.
Audit stale integrations and credentials
Connections outlive the reasons they were created. Walk through every integration in the account and ask three questions: who authorized this, what does it still access, and would anyone notice if it disappeared tomorrow?
- Departed staff: connections authorized under a personal account break the day that person's access is revoked, often weeks after they have left.
- Deprecated apps: if a tool was replaced in the stack, its automations are running on borrowed time and stale data.
- Over-permissioned tokens: an automation that only writes to a spreadsheet rarely needs delete rights across the whole drive.
- Old API versions: most platforms retire versions on a published schedule. Check yours before the provider does it for you.
- Shared logins: anything authenticated as a generic company account should have a documented owner and a rotation plan.
Revoke what you cannot justify, and re-authorize anything tied to a personal account under a service account you control. While you are there, note the expiry date on every token you keep.
Deal with abandoned workflows
Somewhere in the account there is a workflow paused for "testing" since March, a half-built draft that someone started before a meeting, and a scenario that stopped running when its trigger source was decommissioned. None of these are doing harm, which is exactly why they survive.
Give every workflow a verdict: keep, archive, or delete. If it has not run successfully in ninety days and nobody can name the process it supports, it is a candidate. Archive before you delete — export the configuration or move it to a clearly labelled folder — so that a future request ("can we get that reminder thing back?") costs minutes instead of a rebuild.
Adopt a naming convention while you are in there. Something as plain as [team] - [process] - [status] makes the next audit dramatically shorter, and it lets a stranger tell the difference between a live process and someone's afternoon experiment.
An automation nobody trusts is worse than no automation: the work still has to be checked by hand.
Build a repeatable cleanup ritual
Cleanups that happen once fail. Put the work on a calendar and keep it small enough that you will actually do it.
- Weekly: skim the error log for new failure patterns and fix anything touching revenue, billing, or customer communication first.
- Monthly: review the inventory for workflows that have not run, duplicates that appeared, and paused items that should be resolved.
- Quarterly: review connections and permissions, rotate credentials tied to staff changes, and check for deprecated API versions.
- After every build: name it properly, record the owner, and add a note describing the trigger and what "working" looks like.
Keep the audit spreadsheet somewhere the whole team can see it. The point is not documentation for its own sake — it is that a broken automation should be spotted by whoever notices first, not only by the person who built it.
What to do in the next thirty minutes
Do not try to do all of this today. Open your automation tool, filter the run history for errors from the last thirty days, and fix the three that affect customers or money. Then list every workflow with no named owner and send that list to your team asking for one sentence on each.
That is enough for a first pass. You will end the half hour with three fewer failures, a shortlist of orphans, and a much clearer picture of how much is actually running under your name. Repeat next month, and the list gets shorter every time.
Photo: Bulat843 🌙 / Pexels
