We Had 282 Automations and Nobody Could Say What Half of Them Did

The number was 282. That was the count of active automations in an org I was asked to stabilize: workflow rules, process builder processes, record-triggered flows, and Apex triggers, spread across a dozen objects, built by a rotating cast over five years. A single lead save fired eleven of them. Nobody on the team could tell me what more than half of them did, whether they were still needed, or what would break if we turned one off. Every request to change lead handling had become a negotiation with a black box, and the standard answer had calcified into “do not touch it, just add a new flow that does what you need.” So the number only ever went up.

That is automation debt, and it is the systems analog of the code debt every engineering team knows. Each automation was a reasonable decision in its moment. The accumulated interest is an org where nobody understands the whole, changes are high-risk, and the safest-feeling move (add another automation) is the one that makes the debt worse. Paying it down is a real project with a real method: audit what exists, prove what is dead, consolidate what overlaps, and put a governor on new additions so the pile does not regrow.

Debt compounds because the safe move makes it worse

The vicious part of automation debt is that the risk-averse choice grows the debt. When nobody understands the existing stack, editing an automation feels dangerous, so the team routes around it by adding a new one. Each addition raises the interaction count and lowers the odds anyone will ever understand the whole, which makes the next person even more likely to add rather than edit. The stack does not grow linearly; it compounds, because the debt itself discourages the paydown. Left alone, an org goes from “a few flows” to “do not touch anything” in about the time it takes for the original authors to leave.

Audit first: you cannot pay down what you cannot see

The paydown starts with a full inventory, because the reason the debt persists is that no one can see the whole. Pull every automation with its object, trigger, active status, last-modified date, and the fields it reads and writes. The Tooling API and Metadata API give you flows, workflow rules, and triggers; a FieldDefinition and dependency query gives you what references what. The output is one table with a row per automation. That table alone changes the conversation, because “we have 282, forty of them have not been modified in three years, and eleven fire on a lead save” is a fact the team can act on, where “the org is messy” is not.

Classify into dead, duplicated, and load-bearing

With the table in hand, sort every automation into three buckets. Dead: it references a field, record type, or picklist value that no longer exists, or its entry criteria can never be true, so it never fires. Duplicated: two or more automations do overlapping work on the same object and save. Load-bearing: it does real, unique work you must preserve. The dead bucket you retire outright after confirming it truly never fires. The duplicated bucket is the consolidation target. The load-bearing bucket you leave alone except to fold it into the consolidated flow for its object. A query like this finds a class of dead automation fast.

-- Flows not modified in over two years are prime suspects for the dead
-- bucket. Cross-reference against debug logs to confirm they never fire
-- before retiring, but this narrows 282 to a reviewable shortlist.
SELECT DeveloperName, TriggerType, Status, LastModifiedDate
FROM FlowDefinitionView
WHERE Status = 'Active'
  AND LastModifiedDate < LAST_N_DAYS:730
ORDER BY LastModifiedDate ASC

The worked example: 282 down to 82 without breaking prod

An accreted stack versus a paid-down one

Here is how I pay down an automation stack

Nobody decided to build 282 automations. The org got there one reasonable “just add a flow” at a time, because the debt made editing feel dangerous and adding feel safe, and that incentive compounds until a lead save fires eleven things and no one dares change any of them. Paying it down is not a rewrite; it is an audit that makes the whole visible, a classification that separates the dead from the load-bearing, and a consolidation that expresses the same behavior in a fraction of the artifacts. We took 282 to 82 with nothing broken, because every cut was proven safe first. The governor at the end is what matters most: without a rule that new work extends the existing flow instead of adding a parallel one, you will rebuild the pile. The discipline that prevents the regrowth is the same declarative-first, one-flow-per-object pattern and the documented firing order that keeps the stack legible in the first place.