Every Salesforce org I’ve worked in has automation that nobody can explain. A process builder that fires on a field update from 2019. A validation rule that blocks a scenario nobody’s hit in three years. A trigger with a comment that says “TODO: remove after migration” and a commit date from a sprint that ended a long time ago. Nobody built it to be permanent. It just never got removed.
Why dead automation never dies
Admins and developers rotate through orgs faster than the automation does. The person who wrote that process builder left the team eighteen months ago. Whoever inherited the org after them didn’t touch it because it wasn’t broken, and “not broken” gets mistaken for “needed.” Nobody wants to be the one who deletes something and breaks a quarter-end report they didn’t know existed.
So it stays. And it compounds. Every new flow has to account for what’s already running on that object. Every release review takes longer because nobody’s confident what fires in what order, or in what sequence. Governor limits get tighter not because the business grew, but because three generations of automation are all doing slightly overlapping work on the same records.
I’ve seen this most clearly in case management. A contact-centre team I worked with had five separate pieces of automation touching the Case object: two process builders, a flow, an Apex trigger, and a workflow rule that predated all of them. Three were still firing. Two hadn’t done anything useful in over a year, but they still ran, still consumed execution time, and still showed up as “something to check” every time someone touched a case field.
Finding out what’s actually still doing something
Before you can retire anything, you need evidence, not memory. A few places worth checking:
- Setup Audit Trail tells you when something was last changed. It won’t tell you whether it still matters, but it’s a starting point for dating the automation.
- Field history tracking on the fields an automation updates. If a flow is supposed to set a field and that field hasn’t changed in six months, the flow either isn’t firing or isn’t doing what it was built for.
- Debug logs with flow and process builder entries enabled, run over a representative week. This is the most reliable signal: if something doesn’t show up across a week of normal business activity, it’s either rare or redundant.
- Flow Trigger Explorer, on orgs that have consolidated onto Flow, shows execution order on an object. It won’t catch Apex triggers or Process Builder, so check those separately.
None of these on their own gives you certainty. Combine them. An automation that hasn’t changed in two years, doesn’t touch any field that’s changed recently, and doesn’t show up in a week of debug logs is a strong candidate. One signal alone usually isn’t enough to act on.
Talk to the business before you touch anything technical
The tooling tells you what’s firing. It doesn’t tell you why someone built it. Ask the team that works the object every day whether a specific case status, a specific email alert, or a specific field update actually matters to them. Sometimes the answer is “we stopped using that process two reorgs ago and nobody updated Salesforce.” Sometimes it’s “yes, that one’s load-bearing, leave it alone.” You need both kinds of answers, and only people can give you the second kind.
Disable before you delete
Don’t delete automation on day one, even once you’re fairly confident it’s dead. Deactivate it instead, whether that means unchecking “active” on a process builder, deactivating a flow version, or wrapping an Apex trigger’s logic behind a feature toggle. Leave it deactivated for a full business cycle if you can, long enough to hit month-end, quarter-end, and any seasonal process that only runs a few times a year.
If nothing breaks and nobody notices, you’ve got your proof. Document what you deactivated, when, and why, then schedule the actual deletion for a later release. That gap between “disabled” and “deleted” is what turns this from a guess into a defensible decision. It’s also the step most teams skip, because deleting feels more satisfying than waiting.
Start small, and keep a list
Don’t try to clear a decade of automation debt in one release. Pick the most isolated piece first, something like a validation rule with no dependencies, or a workflow rule that only sends an email nobody reads. Prove the process on something low-risk before you go anywhere near a trigger that fifteen other pieces of logic depend on.
Keep a running kill list as part of the backlog, not a separate cleanup project that gets deprioritised the moment a client asks for something new. Retire one thing most sprints. It won’t show up in a demo, and nobody’s going to thank you for it in a stakeholder meeting. But six months of steady retirement does more for the health of an org than any single new feature, because it’s the difference between every future enhancement fighting through a decade of accumulated logic and every future enhancement landing on a clean surface.
What it actually buys you
The payoff isn’t visible in a single release. It shows up over time: fewer “why did this fire twice” tickets, faster impact analysis when someone proposes a change, and a release review that takes an hour instead of an afternoon because the team can actually hold the automation model in their heads. None of that is glamorous. All of it is what separates an org that gets harder to change every year from one that stays workable no matter how long it’s been in production.