The setup
No single decision caused this. That's the point. Over eleven years and four CRM admins, every "can we just add a field for that" request got a yes, because saying yes was faster than explaining why not, and because the tool made it genuinely easy — a few clicks, no visible cost. A regional VP wanted to track a regional promotion. Someone in compliance wanted a checkbox for a reporting requirement that changed two years later. A sales manager wanted three fields to replicate a spreadsheet column he liked. None of it was ever removed, because removing a field feels riskier than adding one — what if someone, somewhere, is still using it in a report you don't know about?
The collapse
By the time the current admin inherited the org, the primary account object carried 412 custom fields across 14 page layouts, several of which hadn't been opened by a human in years. Loading a record meant the page had to fetch, render, and lay out all of it — average load time crept to around 12 seconds on a typical account record, and worse on accounts with a long history. Sales reps, who are not known for patience, started keeping their own spreadsheets for the two or three fields they actually needed day to day, updating the CRM in batches (or not at all) because opening a record was its own small ordeal.
Nobody could say with confidence which fields were load-bearing. A "field usage" audit turned into an archaeology project: cross-referencing field history, checking every report and dashboard for references, interviewing department heads about processes that predated their own tenure, and still finding fields nobody could explain — but that someone insisted "we probably still need." The org had, in effect, accumulated technical debt with compound interest and no statement ever showing the balance.
The autopsy
Root causes on record
- No approval gate on new fields. Anyone with admin access could add one; nobody had to justify removing one.
- No ownership or expiration attached to fields at creation. A field added for a 2019 promotion had no flag saying it could be retired in 2020.
- No periodic field-usage audit. Usage and reference data existed in the platform the whole time; nobody looked at it until performance forced the issue.
- Admin turnover erased institutional memory. Four admins in eleven years means four different mental models of the org, and no durable documentation connecting fields to the business reason they existed.
- Performance was treated as a platform problem, not a data-model problem. The instinct was to ask for more compute or a faster tier, not to ask why one object needed 412 fields.
Recommendation pending
Editor's note: this slot will point to a field/metadata audit tool that can show real usage across reports, layouts, and automations before you try to deprecate anything.
What the post-mortem actually changed
The current admin got budget approval for a two-quarter field audit, working object by object, cross-referencing usage against reports, flows, and integrations before archiving anything. Every surviving field now has a named business owner and a documented reason. New field requests go through a lightweight review — not to block people, but to make sure at least one person besides the requester knows the field exists. Load time is down considerably. Nobody's proud of how long it took to get here.