Knowing Which Switches to Flip

My dad told me this joke back in the 70s or 80s.

A company has a problem nobody can solve. Production is down, the engineers are stumped, and every hour costs money. They call IBM. A support guy shows up, walks into the computer room, flips a few switches, and says "there, it's fixed." He's gone in ten minutes.

A few weeks later the invoice arrives. $100,000.

The company loses it. Ten minutes. Flipping a few switches. A hundred grand?!?

The IBM guy apologizes. Says they're absolutely right, he'll correct it. A new invoice arrives a few days later with two line items.

I cleaned the dead fields out of my org earlier this year (see: Your Salesforce Org Has a Junk Drawer Problem). Next I set my sights on the custom automation.

I got the idea from a user group while making idle chit chat with someone who mentioned their org has zero custom code — nothing but settings and flows. That statement got me thinking about what that would be like to maintain.

So the question was simple: what custom code in my org is doing something Salesforce now does out of the box, or something Flow could do without code? I've wanted that answered every time I had to debug a piece of Apex code, but the issue is answering that means reading thousands of lines of Apex, some of it over a decade old, all of it working fine. It was never going to make it to the top of the priority list.

So AI and I did it one object at a time. Opportunities first — show me every piece of automation on this object that Salesforce now does natively. Then Accounts. Then Cases… etc…. A week and a half of that, with a verdict and a risk rating on each one.

The verdicts were good. Not all of them were right.

• One of the triggers on the list was written in 2017. It stamped a milestone when a case moved off New and closed the open milestones when the case closed. Salesforce does that with a record-triggered flow now.
• Something tied to Lead Scoring came back as safe to delete. I pushed back and asked whether it was used in the lead trigger flow. It rechecked and reversed itself — the field was live, written by that flow every day, and it had confused it with a different scoring system that had been retired years ago.
• Three inactive triggers came back on that same list. Zero dependents, near-zero risk. I pushed back the same way. It checked their status in production, checked the dependency graph, checked the test suite, and held — the original answer stood. I deleted all three that afternoon. Dry run clean, deploy clean, and six weeks on nothing has come back.

In total: 5 Apex triggers, 2 classes, 50 workflow rules, 35 workflow field updates, 34 email alerts and 13 Process Builders, replaced by 13 new flows.

Four managed packages came out too. Nobody had used them in years. That's another 56 classes gone that I didn't have to think about at all.

Those are three out of a few dozen calls like it. Every one came back the same way — confident, thorough, well-reasoned. Not all of them right.

There's no tell. A correct answer and an incorrect one look identical coming across the screen.

The IBM guy billed one line for two different things. In 1975 nobody had a reason to separate them.

If I wrote the invoice for these ten days it wouldn't have two lines. It'd have three.

The middle line used to be most of the money. That was the needle in the haystack — the reading, the tracing, the years of never getting to it. AI does that now, and it does it well enough that I finally started.

It didn't touch the last line.