Your Salesforce Org Has a Junk Drawer Problem

Every Salesforce org has one. Fields nobody uses. Profiles that are almost identical. Flows doing the same job twice. You know it's there. You're just never going to find it because finding it means cross-referencing metadata, running data exports, and chasing references through flows, Apex, and page layouts — one field at a time.

I'm a solo admin. I have integration projects running. I don't have a developer. I have been putting this off for years.

Part of why it piles up is that most of us inherited our orgs. Not from one person — from many. Each admin who came before had their own way of doing things. Not wrong, just different. Different naming conventions, different profile strategies, different ideas about what a layout should show. Over time those layers compound. The org becomes a record of every decision anyone ever made, with no easy way to see which ones still matter.

Then I spent a few days working through it with Claude, and the numbers got embarrassing fast. Each object took about an hour to document and another hour to delete — I did the deletions manually, one by one, as a final check on my own work. Profiles took a few hours. Layouts took a few hours. The analysis that would have stopped me from ever starting took an afternoon.

22 Case fields deleted. 15 Account fields. And conversations now in progress on 64 Opportunity fields, 15 Lead fields, 16 Contact fields, and 12 Product fields. A meaningful chunk of those fields weren't even on a layout. Nobody knew they were there. They'd been sitting in the org, invisible to every user, accumulating nothing.

35 custom profiles down to 13. Layouts consolidated. None of it required writing a single line of code.

Here's what the work actually looked like.

I'd connect Claude Desktop to my Salesforce org — using an MCP connection that lets Claude query the org directly — and ask it to pull every custom field on an object and check which ones had data in them. It would come back with a tiered list: zero population, near-zero, moderate, fully used. It would flag anything already labeled "OLD" or "To Be Deleted."

But for the deep cross-referencing — flows, Apex classes, validation rules, page layouts, profiles, report types — I'd switch to VS Code with my org metadata retrieved locally. This is where Claude in VS Code earns its keep. Claude Desktop connected via MCP can see a lot, but your local metadata is the complete picture. If you want to be genuinely confident a field isn't referenced anywhere, you need both.

Once VS Code finished checking every field against every piece of automation and configuration, I had a one-line verdict per field: ready to delete, hold, or needs a conversation. That's the thing I never would have done manually. Finding an empty field is one thing. Knowing it's also not in any flow, not on any layout, not visible to any user — that's what actually gives you the confidence to act. I would have needed massive data exports and then gone digging through Setup one field at a time. That wasn't going to happen.

Once the analysis was done, I'd have Claude draft the IT ticket, including the right stakeholders. Contact and Lead fields went to Marketing. Product fields went to PLM. Case fields went to the Support Team. Account fields went to Sales Ops. When they gave the thumbs up, I moved to deletions. That part I do more slowly — for each field I'll do a final where-used check and ask Claude how to handle anything that needs unwinding first. The ticket either gets closed or becomes the place where the next set of questions lives.

The Opportunity fields, the Leads, the Contacts, the Products — those aren't deleted yet. That's not a failure. Those are 107 fields now in front of the people who own them, with real data behind the ask. That conversation didn't exist before.

Profiles were even more satisfying.

I had 35 custom profiles. I asked Claude to compare all of them and tell me which ones could be combined, which users could be moved to a simpler profile and given a permission set instead, and where the meaningful differences actually were. A lot of them weren't meaningfully different at all. Once I could see them side by side, the answer was obvious. Down to 13. Users didn't lose anything. The org got simpler.

Same thing with page layouts. Claude compared them across objects, I made a few minor adjustments to consolidate, and deleted the redundant ones. Maintenance going forward is just easier.

The flows find was the most satisfying. Claude spotted two flows doing overlapping work. One step added to the first flow, second flow deactivated and deleted.

None of this is developer work. I didn't write SOQL. I didn't touch Apex. I described what I wanted in plain English and Claude did the technical legwork — the queries, the searches, the cross-referencing — and handed me a prioritized list with a recommendation on each item.

What changed wasn't my skill set. What changed was that I stopped working alone.

I'm a solo admin, but I stopped feeling like one. Claude became the coworker I could turn to and say: I think this field is safe to delete — can you check my work? And it would check my work. Every time.

The people who think AI tools are for developers are thinking about the wrong use case. The most valuable thing Claude did in my Salesforce org wasn't writing code. It was giving me the confidence to clean up ten years of accumulated decisions I'd been too nervous to touch alone.