What should you do before approving a D365 F&O customisation request?
Before approving a D365 F&O customisation request, define the business result the change is meant to improve. Then check whether standard Dynamics 365 Finance and Operations functionality, configuration, personalisation, workflow, security, reporting or process redesign can solve the issue. Custom development should be the last justified option, not the first reaction to a change ticket.
A request for “one new field” can sound small. It rarely feels like a strategic decision. No board is convened. No one describes it as technical debt. The support ticket simply lands with a familiar line: the team needs somewhere to capture a piece of information.
That is where many D365 F&O estates start to drift.
The myth is that a submitted change request is already a requirement. In practice, it is often a symptom. The user may be missing visibility. A manager may lack a reliable approval point. A team may have carried an old spreadsheet habit into Dynamics 365 Finance and Operations. A process owner may not have defined who needs the data, who owns it, or what decision it supports.
Treating that symptom as a build instruction creates risk. A field needs design, security, testing, documentation, user explanation and future support. It may affect reports, integrations, data migration, forms, roles and downstream processes. One field is manageable. Fifty small, loosely governed changes become a system that is harder to use, harder to upgrade and harder to trust.
Good D365 F&O support does not begin by asking, “Can we build it?” That question comes too late. The stronger first question is, “What business result must improve?”
The answer changes the conversation. If the goal is better visibility, a view, workspace, Power BI report or saved filter may solve the problem. If the goal is tighter control, workflow, role security or standard approvals may be the better route. If the goal is user confidence, the issue may be training, screen design or ownership rather than development.
This is why weak requirements create expensive systems. Rushed fit-gap work turns unclear needs into estimates. Unchallenged estimates turn into build work. Build work becomes regression testing, support effort and upgrade consideration. The business pays more, not because D365 F&O cannot support the process, but because the real need was not diagnosed early enough.
A commercially sensible partner should be willing to slow the request down before speeding delivery up. That is not anti-customisation. Some custom development is valid, especially where it protects competitive process, regulatory need or operational control. The danger is approving customisation before the business has proved the value, ownership and lifetime impact.
The safest D365 F&O change process starts with diagnosis. Capture the trigger, affected role, workaround, process step and intended outcome before any estimate is given. Then decide whether the request is a true requirement or a warning sign from the process beneath it.
The FIELD Test: a better way to read “we need a new field”
A new field in D365 F&O should be approved only when it captures information that has a clear owner, supports a real decision, cannot be handled through standard capability, and is worth the long-term support cost. If the field does not change a decision, control, report or process outcome, it is probably clutter rather than value.
Use the FIELD Test before approving the request:
| FIELD Test step | Question to ask | Why it matters |
| Find the decision | What decision will this information improve? | Stops teams collecting data no one uses. |
| Identify the role | Who needs to see, enter or approve it? | Prevents vague ownership and poor adoption. |
| Examine the standard option | Can views, workflow, approvals, security, reporting or configuration solve it? | Reduces unnecessary custom development. |
| Locate ownership | Who owns the data quality after go-live? | Avoids fields becoming incomplete or unreliable. |
| Decide the support impact | What will this cost to test, train, secure and maintain? | Makes lifetime cost visible before build approval. |
Take a common example. A purchasing team asks for a new supplier field because managers want to know which orders are “high risk”. On the surface, that sounds reasonable. But the real issue may not be missing data capture. It may be missing supplier classification, weak approval thresholds, unclear exception handling or poor visibility of late deliveries.
In that case, adding a field may create a new manual step without improving control. A better answer might be a supplier risk category, a filtered workspace, a Power BI view, a workflow rule or a standard approval route. The right design depends on the decision the business is trying to improve.
The risk is not just extra development. Poorly challenged fields can duplicate existing data, weaken data ownership, clutter forms, confuse users and create reporting noise. They can also become hidden dependencies for integrations, documents, Power Platform apps or month-end reporting. What looked like a small support item becomes part of the operating model.
Here is a practical way to challenge the request before it becomes scope:
| Weak input | Hidden issue | Safer question | Business risk if built too quickly |
| “We need a field for status.” | No agreed process stage. | Who changes the status, and what happens next? | Inconsistent data and false visibility. |
| “Finance needs this on the screen.” | Reporting need, not transaction need. | Is this better handled in a report or workspace? | User friction and duplicated entry. |
| “The old system had it.” | Legacy habit. | Does the future process still need it? | Paying to preserve outdated work. |
| “Managers want more control.” | Approval or security issue. | Can workflow or role security solve it? | Custom code where configuration would do. |
This is where D365 F&O support becomes more than ticket handling. The value is in separating useful change from avoidable complexity before the business pays for it.
Why old ERP habits create unnecessary D365 F&O build work
Legacy process habits are one of the most common causes of unnecessary D365 F&O customisation. Teams often ask Dynamics 365 Finance and Operations to behave like the system it replaced, even when the old process was slow, manual or poorly controlled. That turns an ERP improvement opportunity into paid preservation of friction.
The warning phrase is usually familiar: “This is how we’ve always done it.”
A warehouse team may want an extra screen because the old system forced them through a workaround. Finance may ask for a custom approval field because an offline spreadsheet once filled a control gap. Operations may request a local exception because one site has built its own version of a process over several years.
Some exceptions are valid. Many are inherited.
Before any custom extension is scoped, the legacy step should be mapped against the intended end-to-end process. In D365 F&O, a small change in procurement can affect stock visibility, supplier performance, invoice matching, budget control and reporting. A local field added for one team can create confusion for everyone downstream.
The better question is not, “Can we make D365 F&O match the old process?” It is, “Should the old process survive?”
That question matters because customisation often gives weak process design a longer life. If the old approval route caused delay, rebuilding it in Dynamics 365 Finance and Operations does not create control. It makes delay more expensive. If a spreadsheet existed because reporting was poor, recreating its fields may miss the point. The real answer may be better reporting logic, cleaner master data, clearer ownership or standard workflow.
A practical example: a sales operations team asks for a custom field on customer records because the legacy system had a “priority account” marker. After review, no one can define who updates it, what makes an account priority, or what action changes when the marker appears. In that case, the field is not a requirement. It is a label without governance. A better design might use customer groups, credit rules, account ownership, service levels or reporting filters already available in the Microsoft stack.
This is where future-state validation earns its keep. Process owners, end users and IT should agree what the business wants the process to become before custom development is approved. The discussion should cover handoffs, approvals, data ownership, reporting needs, exceptions and the consequence of changing behaviour rather than changing code.
For CIOs and IT leaders, the commercial risk is clear. Unnecessary custom build increases testing effort, support tickets, user training, documentation, regression risk and upgrade review. It can also make adoption harder because users face more fields, more choices and more local rules.
D365 F&O support should help the business avoid paying to automate yesterday’s problems. The goal is not a system that looks familiar. The goal is a system that gives leaders better control, cleaner data and more reliable decisions.
The safer approval path: standard first, custom only when justified
The right D365 F&O customisation decision path starts with the outcome, not the feature. A change should move through outcome definition, standard capability review, configuration or process alternatives, and only then a justified custom build. That sequence protects cost, control, adoption and long-term supportability.
Use this approval checklist before development starts:
| Approval test | What must be clear |
| Business value | What cost, control, visibility, speed or risk issue will improve? |
| Ownership | Who owns the process, the data and the decision after go-live? |
| Standard fit | Which standard D365 F&O options have been reviewed and rejected? |
| Configuration route | Can security, workflow, forms, views, approvals or reporting solve it? |
| Supportability | What will this change add to testing, training, documentation and support? |
| Upgrade impact | Will the extension make future updates harder or riskier? |
| Do-nothing risk | What happens if the business changes behaviour instead of the system? |
This does not mean saying no to customisation. It means making customisation earn approval.
A justified D365 F&O extension normally has a defined outcome, agreed owner, clear process fit, measurable value and known lifetime cost. It should improve something the business can recognise: fewer manual checks, better approval control, cleaner reporting, reduced rework, stronger compliance or faster decision-making.
FAQs
When is D365 F&O customisation justified?
Customisation is justified when the requirement cannot be met through standard functionality, configuration, workflow, reporting or process redesign, and the business value outweighs the cost of building, testing, supporting and upgrading it.
What does standard-first mean in Dynamics 365 Finance and Operations?
Standard-first means checking native D365 F&O capability before custom development. It favours supported configuration, cleaner process design and easier upgrades where these options meet the business need.
Who should approve a D365 F&O customisation?
Approval should involve the process owner, IT owner and the business sponsor affected by the change. The decision should cover value, ownership, data impact, support effort and upgrade risk.
How can businesses reduce customisation risk?
Businesses reduce customisation risk by challenging the requirement early, documenting the decision, testing against future-state processes and rejecting changes that only preserve old habits.
GO ERP helps organisations review D365 F&O change requests, support backlogs and customisation decisions before small tickets become avoidable technical debt. A focused customisation review or support scoping session can show which requests should be built, which should be configured, and which should be solved through better process design.
