The test for any customisation
Who acts on this? Name the person and what they do differently because of it. Fields, automations and reports that fail this test are pure cost — they slow every interaction and degrade the data that does matter.
Over-customisation is not caused by bad decisions. It is caused by a hundred reasonable ones, none of which were ever revisited.
The warning signs
| Sign | What it indicates |
|---|---|
| Nobody knows what happens when a record saves | Automation has passed comprehension |
| Users have spreadsheets alongside the CRM | The system does not fit the work |
| Simple changes take weeks | Everything is entangled |
| Fields nobody can explain | Requirements nobody revisited |
| Upgrades are feared | Fragility |
| Only one person understands it | Key-person risk |
| Training takes days | Complexity passed on to users |
| Bulk imports are avoided | Automation is not bulk-safe |
Users keeping spreadsheets is the clearest signal available. It means the system, as customised, does not support the work — so people rebuilt it somewhere they control. Adding more customisation in response usually makes it worse; asking them what the spreadsheet does is the productive move.
How it accumulates
- A field is added because someone asked. Reasonable in isolation.
- It becomes mandatory so it gets populated.
- Automation is added to derive it when users leave it blank.
- Exceptions are added for cases where the automation is wrong.
- The person who wanted it leaves. Nobody uses it.
- It stays, because removing it feels risky.
- Repeat forty times over four years.
Nothing in that sequence is a mistake. The mistake is that step six never triggers a review, so the cost compounds while the benefit disappears.
Auditing what you have
| Ask of each | Keep if | Remove if |
|---|---|---|
| Custom field | Someone acts on it | Populated rarely, used never |
| Mandatory field | A decision depends on it | Users enter anything valid |
| Automation | Purpose is stated and current | Nobody knows why it exists |
| Report | Someone opened it this quarter | Built once, never revisited |
| Custom object | Actively used | Superseded, still present |
| Validation rule | Prevents a real error | Users work around it |
Field usage data settles the argument. Report on how many records have each custom field populated in the last year. Fields at low single-digit percentages are not in use, whatever anyone says in the meeting. This turns a debate about opinions into a decision about evidence.
Simplifying safely
- Measure usage for every custom field, report and automation.
- Ask "who acts on this?" for anything that survives the usage cut.
- Remove from page layouts first — reversible in seconds, and it surfaces objections quickly.
- Deactivate automation rather than deleting it.
- Wait a full business cycle — a quarter catches most dependencies.
- Then delete, having exported the data first.
- Record what was removed and when, so the next person understands.
Preventing the next accumulation
- Every new field needs a named person who acts on it. No name, no field.
- Review annually against usage data, as a scheduled activity.
- Someone has authority to say no to requests. Consensus never declines anything.
- Prefer configuration to code where both work.
- Document why, not just what — six months later the reason is what matters.
- Set a removal expectation when adding something for a time-limited need.
What simplification typically returns
- Faster record entry, which improves data quality on the fields that matter.
- Changes that take days rather than weeks.
- Training that takes hours rather than days.
- Upgrades that stop being frightening.
- An org more than one person understands.
None of that appears on a project plan as a benefit, which is why simplification rarely gets funded and almost always pays back.
Suspect your org has accumulated past the point of usefulness? Tell us what users complain about. See org health audits, why implementations fail, and platform automation.