We have dozens of automations and nobody knows what they all do. Now what?
You have automation sprawl, and the fix is inventory before cleanup. List every workflow with its trigger, its action, its owner and its last run date. The dead ones you delete. The overlapping ones you merge. The orphaned ones — no owner, still firing — are the dangerous category, and they are usually the reason customers are getting three messages about the same job.
How sprawl happens
Nobody builds forty overlapping workflows on purpose. It accumulates: a marketing person adds a follow-up sequence, an ops manager builds a reminder, a vendor's onboarding wizard creates six more, someone duplicates an existing workflow to change one condition and never deletes the original.
Each addition is reasonable. The aggregate is a system whose behavior no single person can describe, which means nobody can safely change anything.
The symptoms, in order of severity
- Customers receiving duplicate or contradictory messages. The visible tip, and the one that costs you goodwill.
- Workflows referencing fields that no longer exist. They fail every run and nobody sees the errors.
- Nobody willing to turn anything off. The clearest sign that understanding has been lost.
- Two automations fighting. One sets a status, another resets it. Records flip back and forth.
- Onboarding takes weeks. New staff cannot learn a system that is not written down anywhere.
The cleanup that works
Start with observation, not deletion. For two weeks, log every automated customer contact by customer, not by workflow. That single view exposes the duplicates immediately and gives you the political ammunition to turn things off.
Then apply three rules going forward. Every automation has a named owner. Every customer-facing automation passes through one shared suppression layer rather than each having its own rules. Every automation gets a review date, after which it is either reconfirmed or disabled. That last rule is the one that prevents recurrence, and it is why we build automation with a single contact policy rather than per-workflow logic.
Consolidation is not the same as deletion
Resist the urge to rebuild everything in one project. Merge workflows only where they share a trigger and an audience, and keep the merged version behaviorally identical at first so you can tell whether anything broke.
The end state is not fewer automations for its own sake. It is a set of automations someone can explain in a meeting, each with an owner, each with a reason to exist. Getting to that state is normal systems work, and it is usually the highest-return project available to a company that already invested in automation.
One practical shortcut: before deleting anything, disable it and wait two weeks. If nobody notices and nothing downstream breaks, delete it with confidence. If something breaks, you have just discovered a dependency that was not written down anywhere, which is worth more than the cleanup itself.
Topics: automation sprawl · governance · technical debt · audit
Have a version of this question about your own business?
The useful answer usually depends on which systems you run and how they're connected. That's a conversation, not a blog post.