Why most CRM projects over-customise, and the three questions that prevent it

The pattern

Ask anyone who has inherited a Dynamics 365 environment what they found, and the story is usually the same. A few hundred custom fields, half of them empty. Plugins that run on every save of an account. A JavaScript library nobody dares to touch because it hides and shows fields based on rules that were never written down. Forms so crowded that users scroll past most of them.

Nobody set out to build it that way. Each customisation made sense on the day it was requested. A sales manager wanted a field, a workshop agreed on a process step, a deadline made a quick script the easiest option. The trouble is that these decisions are made one at a time, and the cost only shows up when you add them all together.

Over-customisation is rarely a technical failure. It's a decision-making failure, and that's good news, because decisions are easier to change than code.

Why it happens

In our experience, four forces push almost every CRM project in the same direction.

• Requirements describe today, not the goal. Workshops ask people how they work now. The answers turn into requirements, and the new system quietly becomes a copy of the old one, including its workarounds.
• Fit-gap is done feature by feature. When the standard opportunity form doesn't match the current spreadsheet column for column, that's logged as a gap. Nobody asks whether the outcome behind the column is already covered another way.
• Custom work has no visible price tag. A new field costs ten minutes. A plugin costs a day. Neither estimate includes testing it against every future update, documenting it, or explaining it to the next administrator.
• Saying yes feels like good service. For a project team under pressure, agreeing to a request is faster than challenging it. Each yes looks helpful. The total is what hurts.

Every customisation is a small promise to maintain something forever. Most projects make hundreds of those promises without noticing.

What it really costs

Dynamics 365 is a service that changes underneath you. Microsoft ships two major release waves a year, plus a steady stream of smaller updates. A standard configuration mostly moves forward on its own. A heavily customised one has to be checked, tested and sometimes repaired every time.

The costs tend to show up in four places:

• Regression testing grows with every plugin, script and custom workflow, until each release wave becomes a small project of its own.
• New features arrive late or not at all. Copilot, forecasting, sequences and many AI capabilities assume standard tables and processes. If your opportunities live in a custom table, those features simply don't reach your users.
• Adoption suffers. Crowded forms and unexplained rules make the system feel slow and fragile. People go back to email and spreadsheets, which is exactly what the CRM was meant to replace.
• You depend on the people who built it. Custom logic lives in someone's head until it's documented, and it rarely is. Changing partners or staff gets expensive.

The three questions

We don't believe in a blanket "no customisation" rule. Some custom work is exactly what makes a system valuable. What helps is a short, consistent test that every request goes through before anyone opens the designer. These are the three questions we use.

Putting it into practice

The questions only work if they're part of the process rather than an occasional debate. A few habits make that happen.

Keep a customisation register

A simple list of every custom element: what it does, the outcome it supports, its owner and the date it was last reviewed. It takes minutes per item and becomes invaluable during upgrades, audits and handovers.

Use a ladder, not a switch

Treat solutions as a ladder and stop at the lowest rung that works:

1. Change the process to fit the standard feature.
2. Configure: views, forms, business rules, security roles.
3. Use low-code: Power Automate flows or Power Fx, with clear ownership.
4. Write code: plugins, PCF controls or Azure Functions, when the value clearly justifies the long-term cost.

Review twice a year

Line the review up with Microsoft's release waves. Look at the register, check which custom items a new standard feature now covers, and retire what's no longer used. Removing customisations is just as much progress as adding them.

In short

Over-customisation happens one reasonable request at a time. You won't stop it by saying no more often. You stop it by asking better questions earlier, making the long-term cost visible and giving every custom element an owner.

The reward is a CRM that keeps improving with each Microsoft release instead of fighting it, and that your team can still understand years from now.