Every mature marketing stack has one: the workflow nobody dares touch. It was built years ago by someone who's gone. It fires constantly. It touches fields other automation depends on. And at some point, someone asked "can we turn this off?" and the room went quiet — so it stays on, forever, a load-bearing mystery in the middle of production.
That workflow is never alone. Where there's one, there's a population: triggers watching fields that stopped being populated in 2023, three routing campaigns with overlapping logic built by three different admins, a "temporary" fix from an old migration still running nightly, notification flows emailing people who left the company. Individually, each is harmless. Collectively, they're sprawl — and sprawl has a bill, even though it never shows up as a line item.
Here's what it actually costs, in four currencies.
Currency one: incidents
Sprawl doesn't sit still — it interacts. Two workflows updating the same field in different directions. A trigger firing on a change another trigger just made, creating loops the platform quietly rate-limits. A routing rule catching records a newer rule was supposed to own, so a fraction of hand-raisers go to a queue nobody watches.
These aren't hypotheticals; they're the standard anatomy of the "why did 400 people get that email" incident. And the defining feature of sprawl-driven incidents is that they're undebuggable at speed — when nobody knows what's running, every incident starts with an excavation. The cost isn't just the outage; it's the three days of forensics per outage, multiplied by however many mystery workflows can now collide.
Currency two: onboarding drag
Ask anyone who's inherited a sprawled instance what their first quarter was like. The honest answer is: archaeology. Not building, not improving — digging through automation trying to construct the mental model the last admin took with them.
This is the cost that compounds with turnover. A documented instance transfers in weeks; a sprawled one takes a new operator six months to trust, and until they trust it, they work around it — building new automation beside the old because modifying the unknown feels riskier than duplicating it. Which is, of course, how the sprawl grew last time. Every admin generation adds a layer; nobody feels safe removing one. It's a ratchet.
Currency three: platform cost and performance
Sprawl consumes real resources. Every active trigger is evaluated against every qualifying event — platforms throttle exactly this, which is why sprawled instances see campaigns queue and syncs lag at peak hours. API calls burn against limits on both the MAP and CRM side, and duplicated logic doubles the burn for zero additional outcome. In CRM-side automation, sprawl means more flows evaluated per record save, and anyone who's watched a Salesforce org slow down under flow accumulation knows how that story ends.
None of this appears on an invoice as "sprawl." It appears as upgrade conversations — more API capacity, higher tiers, performance add-ons — solving with budget what an inventory would solve for free.
Currency four: change paralysis
The quietest cost and the biggest one. In a sprawled instance, every new project begins with the question "what will this break?" — and since nobody can answer it, everything moves slower. Launching a new scoring model means first reverse-engineering the old one and its fourteen dependencies. A lifecycle redesign gets scoped, then shelved, because the current state can't even be described. Teams start routing around the platform entirely — spreadsheets, manual steps, side tools — because the automation layer that was supposed to accelerate them has become terrain.
When ops veterans say "we can't have nice things until we clean up," this is what they mean: sprawl converts every future project into a renovation of an undocumented building.
Why purging is the wrong first move
The instinct, once sprawl is acknowledged, is a cleanup sprint: turn off everything suspicious and see what breaks. Resist it. "See what breaks" is an incident-generation strategy — the mystery workflow that looks dead may be the thing feeding lifecycle timestamps to your board reporting, and you'll find out three weeks after deactivating it, when the numbers go strange and the trail has gone cold.
Deletion isn't the first move. Documentation is. You earn the right to retire automation by understanding it — and understanding it turns out to be most of the work.
The registry method
The fix is an inventory pass that answers three questions for every active automation in the stack — MAP and CRM both:
What does it do? Trigger conditions, actions, and in one sentence, its purpose — which is not the same thing. "Updates Lifecycle Stage when MQL threshold crossed" is what it does; "implements the 2024 MQL definition" is why it exists, and the why is what tells you whether it's still valid.
What does it touch? Fields read and written, programs invoked, systems called. This is the dependency map, and it's what converts "can we turn this off?" from a silence into a lookup.
Does anything still depend on it? Activity logs answer part of this — a trigger that hasn't fired in a year is a strong candidate — but pair the data with the map: some automation fires rarely and matters enormously (year-end jobs, compliance flows).
The output is a registry: one row per automation, owner assigned, purpose stated, dependencies listed. With it, retirement becomes routine — deactivate (don't delete), monitor for a cycle, then remove, a handful at a time, quick wins first: the duplicated logic, the triggers on dead fields, the notifications to departed employees. Without it, every cleanup is a gamble.
And one structural habit keeps the ratchet from re-engaging: no new automation ships without a registry row. The instance stays legible one row at a time — that's the entire governance system, and it costs about ninety seconds per workflow.
The test
Pick the three most active automations in your instance and ask the team: what do these do, what do they touch, who owns them? If those three — the busiest ones — can't be answered from documentation, the long tail is certainly worse, and the four costs above are already accruing. The good news: this is one of the most fixable problems in ops. Sprawl was accumulated one workflow at a time, and it unwinds the same way.
Untangling automation — the registry, the dependency mapping, the safe retirement of the mystery workflows — is the core of our business automation work. A stack audit will tell you how deep the sprawl goes: one call, one week, and the findings are yours either way.