This article provides a practical framework for discussion. The right answer depends on the specific Dynamics 365 configuration, requirements and constraints of your organisation.
Start with the business outcome
A requested screen, field or workflow is often a proposed solution rather than the actual requirement.
Validate current standard capability
D365 changes over time. Confirm supported functionality, configuration and adjacent platform capabilities before deciding a gap exists.
Consider process change
If a standard process meets the business objective with acceptable compromise, it may be lower-risk than maintaining custom code.
Use the wider platform deliberately
Power Platform, reporting, workflow or integration may solve some needs without changing core application logic.
Quantify lifecycle cost
Customisation affects testing, upgrades, support, documentation and future change.
Customise when it is materially justified
A genuine differentiating or regulatory requirement that cannot be met acceptably through supported capability may justify development.
Use a focused review to separate root causes from symptoms and define the right next action.