Post Series · Part 2
The field audit: deleting 178 fields without an incident
Part two — the staged deletion: describe, hide, freeze, delete, and the one rollback we needed at step three.
On this page
Part one ended with 178 fields that passed every test. This part deletes them — slowly, in stages, because “passed every test” and “safe to delete” are different claims, and the gap between them is where incidents live.
The staging
- DescribeExport every candidate field’s metadata to the repo. This is the rollback.
- HideRemove from layouts and field-level security. Two weeks’ wait — anything that breaks now breaks loudly and reversibly.
- FreezeRename with a ZZZ_DEPRECATED_ prefix. Two more weeks. Formulas and integrations that reference it by API name keep working; humans notice the label.
- DeleteIn batches of twenty, one object at a time, with the recycle bin’s fifteen-day window as the final net.
The one that came back
Day nine of the hide stage: a regional team’s quarterly forecast broke. The field had zero values in twelve months — because they populated it during one week per quarter, and the audit window had landed between weeks. Test one had lied, politely.
The fix took ten minutes because hiding is reversible. Had we deleted on day one, it would have been a restore-from-describe, a data reload, and a meeting with names in it. The staged process is slower by design: every stage before the last one is a question, and only the last one is an answer.
The result
177 fields gone, one reinstated, zero incidents that survived a fortnight. The org’s setup pages load noticeably faster, which nobody predicted and everybody mentions.
