One-system thinking can create the wrong Business Central scope
Not every business requirement belongs in Business Central. The right scope keeps finance, stock, purchasing, sales orders and core operational control in the ERP where the fit is strong. Other needs may be better handled through configuration, an extension, Power Platform, reporting tools, an integrated specialist application or a change in process.
The pressure to put everything into one system is understandable. Leaders want fewer applications, cleaner data and simpler accountability. Yet fewer systems do not automatically mean a simpler operating model.
A Business Central programme can quickly expand from a clear operational brief into a collection of departmental wish lists. Payroll wants a specialist workflow. Sales wants a customer portal. Operations wants advanced planning. Finance wants complex management reporting. Each request sounds reasonable in isolation, so the default response becomes: “Can we build it in Business Central?”
That is the wrong first question.
Business Central should act as the control layer for the processes and records it is well suited to manage. For many growing organisations, that includes financial transactions, purchasing, sales orders, inventory, stock movements and connected operational data. It does not follow that every user interaction, analytical need or specialist process should sit inside the core ERP.
Forcing unsuitable functions into Business Central can create costs that are easy to miss during scoping:
- more design, development and testing;
- greater support and documentation effort;
- added friction during updates;
- harder regression testing;
- weaker user adoption where the experience does not match the work;
- long-term dependence on bespoke knowledge.
Microsoft’s own Dynamics 365 guidance recommends beginning with business processes, comparing them with standard capability and adapting only where the gap is justified. It warns that recreating legacy processes can lead to unnecessary customisation, additional training and a heavier maintenance burden.
Consider a company asking Business Central to manage payroll exceptions, sales commissions, customer self-service and advanced operational analysis. Building all four may appear to support a one-system strategy. In practice, it may place four different process types into a platform chosen primarily for financial and operational control.
A better architecture might keep the source transactions and master data in Business Central, use Power BI for analysis, Power Platform for a suitable approval or departmental workflow, and an integrated specialist product where the functional depth warrants it.
The objective is not to keep Business Central standard at any cost. It is to keep the core coherent. A small, well-governed extension can be entirely justified when it solves a valuable process gap. The risk begins when “one system” becomes a design rule that overrides process fit, supportability and user needs.
Before deciding where a requirement belongs, leaders need to establish whether they are dealing with a genuine business requirement at all. A requested feature is often only the first clue.
A feature request is not yet a business requirement
A feature list can start a useful conversation, but it cannot safely define Business Central implementation scope.
Requests such as “add another approval screen”, “build a stock dashboard” or “integrate every system” describe a preferred answer. They rarely explain who has the problem, what triggers it, how often it occurs, which exceptions matter or what business result should improve.
Approving the feature before understanding the process can inflate scope without resolving the underlying issue.
What should a Business Central requirement contain?
A usable requirement should explain:
- the current process and its failure point;
- the people responsible for each decision;
- the intended future workflow;
- exceptions, approvals and escalation rules;
- the data required and where it comes from;
- reporting, security and audit needs;
- how success will be tested;
- what users must do differently.
This level of discovery protects more than the project budget. It reduces rework, clarifies ownership and gives stakeholders a shared basis for deciding whether Business Central is the right home for the capability.
Microsoft’s fit-to-standard guidance follows the same process-led logic. It recommends evaluating end-to-end business processes before performing fit-gap analysis or deciding where extensions are justified. The aim is to avoid recreating old system behaviour without first asking whether the process should be retained.
Weak input creates predictable business risk
| Weak input | What is still unknown | Likely business risk |
| “We need a dashboard” | Which decision it supports and whether the source data is reliable | More reporting built on inconsistent data |
| “Copy the old approval process” | Whether the rules still reflect current controls | Unnecessary configuration or customisation |
| “Integrate everything” | Which system owns each record and when data should move | Duplicate data, fragile dependencies and unclear support ownership |
| “Users need another field” | Who uses it and what action it changes | A busier interface with little operational value |
| “Build a custom workflow” | Whether standard setup or process change could solve the problem | Higher cost, longer testing and added maintenance |
Consider a request for a custom purchasing approval function. The feature sounds straightforward until discovery reveals the real questions: Are approval limits based on value, department or project? Who handles absence cover? What happens when a purchase order changes after approval? Is mobile approval required? What audit evidence must be retained?
Once those decisions are clear, the answer may be standard Business Central workflow, Power Automate, a focused extension or a redesigned approval policy. The original request did not contain enough information to choose between them.
Good requirements gathering does not slow delivery. It prevents teams from building the wrong answer quickly.
The next decision is where the capability should live and which delivery route creates the best balance of value, cost, risk and maintainability.
Use the 3P Scope Test before approving any build
Once the business requirement is clear, leaders need a repeatable way to decide whether it belongs in Business Central and how it should be delivered.
The 3P Scope Test — Problem, Place, Path provides that discipline.
1. Problem: what must improve?
Start with the operating problem, not the requested feature.
A sound requirement should identify:
- who is affected;
- where the process fails;
- how often the issue occurs;
- what cost, delay, control gap or decision problem it creates;
- what measurable improvement is expected.
“Build a customer credit dashboard” is a proposed solution. “Credit decisions take two days because exposure data is spread across three sources” is a business problem.
That distinction matters. The first statement pushes the project towards a build. The second leaves room to consider data quality, reporting, process ownership and standard capability before adding scope.
2. Place: where should the capability live?
The next question is whether Business Central is the right system location.
| Delivery route | Best suited to | Decision warning |
| Standard Business Central | Common finance, purchasing, sales and inventory processes | Do not reject standard capability simply because it differs from the legacy process |
| Configuration | Controlled variations in fields, permissions, workflows and setup | Avoid using configuration to preserve unnecessary complexity |
| AL extension | A justified ERP-specific gap with clear business value | Test upgrade impact, support ownership and long-term maintenance |
| Power Platform | Suitable approvals, forms and departmental workflows around the ERP | Define data ownership and governance before building |
| Power BI | Analysis, management reporting and cross-source insight | Reporting will not correct weak source data |
| AppSource or specialist system | Deep industry or functional capability | Assess vendor dependency, integration quality and exit options |
| Process change | Legacy habits, duplicate controls or unclear ownership | Confirm that the organisation can adopt the new way of working |
| Phased backlog | Useful but non-critical requirements | Prevent optional scope from delaying core value |
The right answer may use Business Central as the system of record while another tool manages the interaction, analysis or specialist process.
3. Path: what is the safest practical route?
The chosen option should then be tested against business value, cost, delivery time, operational risk, maintainability, update safety, user adoption and support responsibility.
A technically complete answer is not always the strongest commercial decision. A smaller change that resolves the real problem may protect budget and delivery confidence more effectively than an elaborate custom solution.
Microsoft’s fit-gap guidance supports this sequence: assess standard processes first, then evaluate justified extensions, partner solutions or other technologies against value and feasibility.
The 3P Scope Test turns stakeholder requests into governed decisions. It gives discovery teams, solution architects and steering groups one shared language for separating genuine requirements from expensive assumptions.
Turn the 3P Scope Test into a governance rule
The 3P Scope Test creates most value when it becomes part of project governance, not a one-off discovery exercise. Use it whenever a requirement could change cost, architecture, delivery time, support ownership or user adoption.
That includes:
- discovery and process workshops;
- fit-to-standard and fit-gap reviews;
- integration and AppSource decisions;
- change-control meetings;
- steering-group approvals;
- pre-build design reviews.
Each material requirement should reach an approval meeting with enough evidence to support a decision. At minimum, record the business problem, process owner, affected users, expected value, proposed system location, alternatives considered, dependencies, acceptance criteria and recommended delivery route.
This creates traceability. It also makes it harder for late requests to enter the build simply because they come from a senior stakeholder or appear easy to develop.
Match the approval effort to the delivery risk
Not every requirement needs the same level of scrutiny.
A standard configuration change may only need functional approval and clear test criteria. A custom extension should require stronger evidence covering business value, technical design, update impact and long-term ownership. An integration or adjacent product should add data governance, security, vendor dependency and support responsibilities to the review.
The principle is simple: the greater the whole-life risk, the stronger the case required for approval.
This approach reflects GO ERP’s wider view of Business Central delivery. Good scoping is not about forcing every organisation into an untouched standard system. It is about protecting the core while making justified changes where they produce clear operational value. Strong discovery, process analysis and solution design reduce expensive rework later and give leaders greater confidence in cost, timing and fit.
Frequently asked questions
Should Business Central contain every business process?
No. It should manage the finance and operational processes where it provides a strong, supportable fit. Specialist functions may belong in an integrated application, Power Platform, a reporting layer or a redesigned process.
When should a requirement become a custom extension?
Use an extension when a valuable ERP-specific need cannot be met sensibly through standard capability, configuration or process change, and the maintenance burden is understood.
What is the difference between fit-to-standard and fit-gap analysis?
Fit-to-standard compares business processes with standard system capability. Fit-gap follows afterwards and examines the justified gaps that may need configuration, extension, integration or another solution.
When is Power Platform or an integration a better option?
Choose an adjacent route when the requirement needs a different user experience, specialist depth, cross-system workflow or analytical capability that does not belong in the ERP core.
Business Central scope should not be approved by feature count. It should be approved by evidence.
A GO ERP scope and fit review applies the 3P Scope Test to high-risk requirements before budget or build effort is committed. The outcome is a clearer view of what should remain standard, what deserves extension and what belongs elsewhere.
