HubSpot Automation Sprawl: How to Find and Kill Workflows Nobody Remembers Building

‍TL;DR: Automation sprawl happens gradually: a workflow built for a specific campaign outlives that campaign, a test workflow never gets cleaned up, a workflow built by someone who's since left the company keeps running with nobody able to explain its purpose. Finding these requires checking three specific signals, enrollment history, last-edited date, and creator, cross-referenced against current business relevance. Killing the wrong workflow is a real risk, so every candidate for deactivation needs a two-week observation period before permanent deletion, not an immediate delete.

‍

A HubSpot portal that's been active for more than a year or two typically runs dozens of workflows, and a meaningful share of them were built for a purpose that no longer exists, by someone who may no longer be at the company, for a reason nobody currently on the team can explain. This is automation sprawl, and it accumulates the same way clutter accumulates in any system nobody's actively maintaining: gradually, invisibly, and without any single moment where it becomes an obvious problem.

Why sprawl is hard to notice until it's already extensive

Each individual workflow addition feels reasonable at the time it's built: a new campaign needs a new automated sequence, a specific edge case needs a small workaround, someone wants to test an idea quickly. None of these additions look like a problem in isolation. The sprawl becomes visible only in aggregate, once a portal has accumulated enough of these individually-reasonable additions that nobody can hold the full picture in their head anymore, and workflows start silently overlapping, conflicting, or running against contacts they were never actually intended to reach.

The three signals that flag a workflow worth investigating

Why enrollment history alone isn't enough to justify deletion

A workflow with zero recent enrollment could mean two very different things: it's a seasonal or event-triggered workflow correctly waiting for a condition that hasn't occurred recently, or its enrollment criteria have quietly broken and it's simply not catching anyone anymore despite being intended to run continuously. Distinguishing between these requires checking what the enrollment trigger actually is, not just whether enrollment happened recently. A workflow triggered by a specific annual event, for instance, might correctly show no enrollment for eleven months of the year, which looks identical in the data to a workflow that's silently stopped functioning.

Why last-edited date matters even for a workflow that's still enrolling contacts

A workflow can still be actively enrolling contacts while running on logic that hasn't been reconsidered in years, which is its own kind of risk even without the more obvious warning sign of zero enrollment. purple path's breakdown of what breaks during a HubSpot tier migration covers one specific way an old, unexamined workflow can quietly stop working correctly even while technically still running; a workflow untouched for years deserves a fresh look simply because the business context it was built for may have shifted considerably since anyone last checked its logic against current reality.

Why knowing the creator matters more than it might seem

A workflow built by someone still at the company can usually be explained quickly with a short conversation. A workflow built by someone who's left, with no accompanying documentation, is a genuine risk: if it ever needs modification, whoever inherits it is working blind, reverse-engineering intent from logic alone rather than understanding the original reasoning. Flagging these specifically, and prioritizing documentation or careful review for exactly this subset, is a more efficient use of limited cleanup time than treating every workflow with equal scrutiny regardless of who built it or why.

Why deletion should never be the first action, even for a clearly dead workflow

Even a workflow that looks obviously dead by every measure, no recent enrollment, ancient last-edited date, built by someone long gone, shouldn't be deleted immediately. The safer sequence is deactivating it first and observing for a defined period, commonly two weeks, before permanent deletion. This observation window catches the rare but real case where a workflow's absence causes a problem nobody anticipated, some downstream process quietly depending on a side effect of the workflow running, even if its primary enrollment function looked dormant.

Why this connects directly to the broader field audit and cleanup framework

Workflow sprawl and field sprawl are closely related problems, since workflows frequently reference the same fields covered in a broader hygiene audit. purple path's field audit framework specifically flags fields that are dead but still referenced by an active workflow as the highest-priority category to fix; running a workflow sprawl cleanup alongside a field audit, rather than as two completely separate projects, catches cases where a dead field and a dead workflow are actually the same underlying problem viewed from two different angles.

A practical method for tackling sprawl without it becoming its own multi-week project

Rather than attempting to review every workflow in the portal at once, sort the full list by last-edited date, oldest first, and work through the oldest twenty percent as a first pass. This subset is disproportionately likely to contain the sprawl worth addressing, since a workflow actively maintained and recently edited is much less likely to be a forgotten relic than one nobody has touched in years. Working through this prioritized subset first, rather than the full list indiscriminately, makes the project considerably more tractable without sacrificing much of its value.

Why this should become a recurring practice rather than a one-time cleanup

Automation sprawl reaccumulates the same way CRM field clutter does: new workflows get built for new campaigns and initiatives continuously, and without a recurring check, the portal drifts back toward the same sprawl within a year or two of any one-time cleanup. Building a lightweight version of this three-signal check into the same recurring hygiene practice covered in purple path's 45-minute HubSpot health check keeps sprawl from reaccumulating to the point where it needs another large, disruptive cleanup project down the line.

Why a shared, visible workflow log prevents sprawl from recurring after cleanup

Beyond the initial cleanup, the most durable fix is a simple, shared log listing every active workflow, its purpose, its creator, and the date it was last reviewed. This doesn't need to be an elaborate system; a basic spreadsheet updated whenever a workflow is created or modified is enough to give the next person doing a sprawl review a clear starting point, rather than having to reconstruct purpose and context from scratch the way the original cleanup required. Teams that skip this step tend to find themselves back in the same sprawling position within a year or two, simply because nothing changed about how new workflows get documented going forward.

Why sprawl tends to accelerate right before and after a major campaign push

A specific pattern worth watching for: workflow sprawl often accelerates in bursts tied to major campaigns or product launches, when marketing teams build several new workflows quickly under time pressure and don't circle back to clean up or properly document them once the campaign concludes. Scheduling a lightweight sprawl check specifically in the weeks following any major campaign or launch, rather than waiting for the next regularly scheduled quarterly review, catches this particular accumulation pattern while the context is still fresh and easy to evaluate.

Frequently Asked Questions

How long should the observation period be before permanently deleting a deactivated workflow?

Two weeks is a reasonable default for most workflows, though a workflow tied to a longer sales or campaign cycle may warrant a longer observation window to be confident nothing downstream was quietly depending on it.

What's the fastest way to check who built a specific workflow if HubSpot doesn't show it clearly?

Most HubSpot portals do track a creator field for workflows, visible in the workflow's details or settings; if this information genuinely isn't available, checking the workflow's creation date against team member start and end dates can sometimes narrow down likely candidates.

Should test workflows be treated differently from workflows built for a real campaign?

Yes, test workflows are especially prone to sprawl since they're often built quickly with the explicit intention of being deleted after testing, and that follow-up deletion step frequently gets forgotten once the test is complete and attention moves elsewhere.

Is it worth building a naming convention to prevent future sprawl?

Yes, a simple naming convention, including the creation date and a brief purpose tag in every new workflow's name, makes future sprawl considerably easier to audit, since it removes the guesswork involved in figuring out what an unfamiliar workflow was originally built to do.

How often should a full workflow sprawl review be conducted?

An initial thorough pass is worth doing once as a baseline, and after that, folding a lighter version of the same check into a recurring quarterly or biannual hygiene routine prevents sprawl from building back up to the point where another large cleanup project becomes necessary.

‍

Running this three-signal check against your own workflow list is a focused way to find out how much automation sprawl has quietly accumulated. Talk to purple path about auditing your current workflow list and finding what's actually still needed.