Business Central Customisation vs Configuration

Every BC implementation reaches the same conversation: "standard BC doesn't do this the way we do it. Can we customise it?" The answer is almost always yes. The more important question is whether you should.

Configuration and customisation are not interchangeable terms, and the distinction matters enormously for long-term cost. Configuration uses BC's built-in tools and settings, requires no code, carries no upgrade risk, and can be changed by a trained user. Customisation means writing AL code, which is upgrade-safe by design but still creates ongoing maintenance obligations. Understanding the difference, and having a framework for deciding which is appropriate, is what separates a well-governed BC implementation from one that accumulates technical debt.

Configuration: What It Is and What It Covers

Configuration is everything you can do inside Business Central without writing code. It uses the application's built-in options to shape how the system behaves.

Examples of configuration in BC: defining chart of accounts structure and posting groups, setting up approval workflows and permission roles, creating dimensions for analysis (department, project, cost centre), customising report layouts using Word or Excel templates, defining pricing rules and discount structures, setting up bank reconciliation matching rules, configuring notification thresholds and reminders.

None of these require a developer. None of them create upgrade risk. When Microsoft releases a new version of BC, configuration settings carry forward automatically. A business that has solved its requirements through configuration has zero upgrade overhead.

Configuration should always be the first question. Before any customisation conversation, the question to ask is: "Is there a built-in setting in BC that achieves this?" The answer is yes more often than buyers expect, particularly for processes that feel business-specific but are actually standard operating patterns in similar businesses.

Customisation in BC: How the Extension Model Works

When configuration cannot meet the requirement, Business Central customisation means writing AL code. AL (Application Language) is the programming language used to build extensions on top of the BC platform. All customisation in modern BC takes the form of an extension: a self-contained package of code that sits on top of the standard system without modifying Microsoft's core application (Microsoft Learn, Developing Extensions).

How extensions work: rather than modifying BC's core objects directly, AL extensions subscribe to events that BC publishes at key moments in its processes: before posting a transaction, after inserting a record, when releasing a sales order. The extension code responds to these events without touching Microsoft's source. This architecture is what makes BC extensions upgrade-safe: Microsoft's code and the extension code remain separate, and BC's twice-yearly updates do not require re-implementing customisations.

There are two types of extensions relevant to most businesses:

AppSource extensions are published on Microsoft's marketplace and installed from there. They are developed by third-party independent software vendors (ISVs) and certified by Microsoft. AppSource hosts a substantial catalogue of pre-built extensions covering payroll, e-commerce connectors, industry-specific functionality, advanced reporting, and more. The publisher is responsible for keeping the extension compatible with BC updates. Due diligence is required: not all AppSource publishers maintain their apps reliably, and some extensions have been abandoned or infrequently updated (Microsoft Learn, Lifecycle of Apps and Extensions FAQ).

Per-Tenant Extensions (PTEs) are bespoke AL code built by a developer and deployed specifically to one customer's BC environment. This is what most people mean when they say "we need a customisation." PTEs are upgrade-safe in that they do not touch core code, but the partner who built them is responsible for testing and updating them with each BC release. Every PTE creates an ongoing maintenance obligation: twice per year, when BC updates, the extension needs to be tested and potentially updated. That cost is real and should be in the annual support budget from the start.

Why BC is Different From Dynamics NAV

For businesses that migrated from Dynamics NAV, the customisation question carries a specific anxiety: the memory of upgrade projects that cost six figures and took months, caused by C/AL customisations that were baked into the base application code.

That model is gone. Business Central ended C/AL customisation entirely with version 15 in 2019. Since then, BC has been fully extension-based. Microsoft's own base application is delivered as an AL extension. Developers cannot modify core BC objects. The result is that BC can update twice a year, and extensions either pass the compatibility check and upgrade automatically, or the partner is alerted to fix the extension before the update goes live (Microsoft Learn, Developing Extensions).

What this means in practice: the upgrade nightmare is structurally over for businesses that stay within the extension model. A business that had a heavily customised NAV environment and is now migrating to BC will not carry that upgrade burden into the new system, provided the migration is done correctly and the bespoke NAV customisations are assessed properly rather than blindly recreated in AL.

What has not changed: the risk of over-customisation. The extension model reduces the upgrade risk of customisation, but it does not eliminate the cost of maintaining it, the complexity it adds to the system, or the risk of recreating processes that standard BC already handles better. A BC environment with thirty PTEs is more expensive to maintain, more difficult to troubleshoot, and more likely to have edge-case compatibility issues than one with five.

The Decision Framework: Configure, AppSource, or Bespoke?

The correct default order for any requirement that standard BC does not meet natively:

Step 1: Configure. Can this be achieved through BC's built-in settings? Chart of accounts structure, workflows, approval hierarchies, dimensions, posting groups, report layouts, notification rules. If yes, configure it. No code, no upgrade risk, no maintenance cost.

Step 2: AppSource. Is there a certified AppSource extension that meets this requirement? Before writing any bespoke code, search AppSource and ask your partner whether a pre-built solution exists. Check the publisher's update history, user reviews, and support documentation. A well-maintained AppSource extension is almost always preferable to a bespoke PTE for the same requirement.

Step 3: Bespoke PTE. If neither configuration nor AppSource meets the requirement, bespoke AL development is justified. Before commissioning it, the business case should answer three questions: what is the measurable business value of this customisation? What is the annual maintenance cost? Who is responsible for testing and updating it with each BC release?

In Zoosh Digital's experience, working through this framework with a client's initial customisation request list consistently reduces the bespoke development scope significantly. Requests that arrive as "we need a customisation" frequently turn out to be achievable through configuration or an AppSource extension. The ones that remain as genuine PTEs are typically integrations with systems that have no pre-built connector, regulatory reporting requirements specific to the business, or genuinely proprietary business logic that represents competitive differentiation.

When Customisation Is Genuinely Justified

Not every customisation request is unnecessary. Bespoke AL development is genuinely warranted in the following situations.

Regulatory or compliance obligations that standard BC does not natively cover and no AppSource extension addresses. Examples: an Irish Revenue-specific reporting format that no available extension produces, or a sector-specific compliance requirement in a regulated industry.

Genuine competitive IP: a proprietary calculation, a unique customer-facing workflow, or a process that materially differentiates the business in its market. If the process is genuinely proprietary, it is worth building and maintaining.

Integration requirements that cannot be met by the native connectors or Power Automate. When a business system requires a custom API layer that no AppSource connector covers, bespoke development is the appropriate path.

Industry-specific process depth where no AppSource extension exists and the requirement is fundamental to operations. A manufacturing business with a unique production planning model, or a professional services firm with a non-standard billing methodology, may have requirements that fall into this category.

What is not a good justification: "this is how we do it in our current system." The migration to BC is the right moment to ask whether the current process is actually good, or whether it is a workaround for a limitation in the old system that BC already handles better natively. Many customisation requests in BC implementations are recreations of broken processes. The implementation is the opportunity to fix the process, not to preserve it in code.

What Over-Customisation Actually Costs

The cost of over-customisation is not only financial. It affects every dimension of the BC deployment.

Implementation cost: bespoke development takes time. If customisation scope is not governed, it expands throughout the project. In Zoosh Digital's experience, ungoverned customisation requests can represent 20 to 30% of total project budget for businesses that approve every request without a business case process.

Annual maintenance: every PTE requires testing with each BC update. The maintenance cost of a single extension may be small. The aggregate cost of twenty extensions across two annual updates is a real line item in the annual support budget.

System complexity: a heavily extended BC environment is harder to troubleshoot, harder to document, and harder to hand over to a new partner if the relationship with the original developer changes. Complexity accumulates quietly and becomes visible when something breaks.

Upgrade compatibility: while extensions are structurally upgrade-safe, a large PTE catalogue creates more surface area for compatibility issues with each Microsoft update. Partners who maintain a large number of PTEs for a client are managing a continuous testing and remediation obligation.

User adoption: the more BC is extended away from the standard interface, the less the user community benefits from Microsoft's documentation, online resources, and training materials. Heavily customised systems create their own learning curve.

The Questions to Ask Your Partner

Before approving any customisation in a BC scoping conversation, these questions should have answers.

Is there a configuration option that achieves this? If the partner cannot answer this definitively, they have not done the discovery properly.

Is there an AppSource extension? Ask the partner to show you, not just tell you. A five-minute AppSource search is worth doing before committing to bespoke development.

What is the measurable business value of this customisation? If the answer is "it matches our current process," ask whether the current process is the right one. The answer to this question determines whether the customisation is genuinely warranted or whether it is comfort rather than necessity.

Who maintains this extension, and how? A credible answer describes a testing process, a versioning approach, and a support agreement that covers both BC update cycles per year. A vague answer is a red flag.

What does this customisation cost to maintain annually? This should be a specific answer, not a vague reference to future support arrangements.

Zoosh Digital builds bespoke AL extensions where they are genuinely warranted, and actively steers clients away from customising processes that standard BC handles better. The ability to do both, and to make the honest call on which is which, is part of the value of an experienced partner.

FAQ

What is the difference between configuration and customisation in Business Central?

Configuration uses BC's built-in settings and options without code: chart of accounts structure, workflows, approval rules, dimensions, posting groups, report layouts. Configuration carries no upgrade risk and requires no developer. Customisation means writing AL code to extend BC's behaviour beyond what configuration can achieve. In BC, customisation always takes the form of an extension: a package of code that sits on top of the standard system without modifying Microsoft's core application. Extensions are upgrade-safe by design, but they create ongoing maintenance obligations that configuration does not.

Is Business Central customisation safer than Dynamics NAV customisation?

Yes, structurally. In Dynamics NAV, customisation meant modifying the base application code using C/AL. Every Microsoft update required manually re-applying those modifications, which is why NAV upgrades were expensive and slow. Business Central ended C/AL customisation with version 15 in 2019. In BC, all customisation is done through AL extensions that sit on top of the core system. Microsoft can update BC twice a year without the client needing to re-implement customisations. The extension model does not eliminate the cost of maintaining bespoke code, but it eliminates the structural upgrade risk that defined NAV.

What is a Per-Tenant Extension (PTE)?

A Per-Tenant Extension (PTE) is bespoke AL code built by a developer and deployed specifically to one Business Central environment. This is the standard form of bespoke customisation in BC. PTEs are upgrade-safe: they do not modify Microsoft's core code. However, the partner who built the PTE is responsible for testing and updating it with each BC release (twice per year). Every PTE creates an ongoing maintenance obligation. That cost should be budgeted from the start and included in the annual support agreement.

When should I use an AppSource extension rather than a bespoke PTE?

AppSource should always be checked before commissioning bespoke development. AppSource hosts a large catalogue of certified extensions covering payroll, e-commerce integration, industry-specific functionality, advanced reporting, and more. A well-maintained AppSource extension is almost always preferable to a bespoke PTE for the same requirement: the publisher maintains compatibility with BC updates, and the development cost is shared across many customers rather than borne by one. When AppSource does not have an extension that meets the requirement, or when the available extensions are poorly maintained, a bespoke PTE is appropriate.

What is the ongoing cost of BC customisation?

Bespoke Per-Tenant Extensions require testing and potentially updating with each BC release, which happens twice per year. The ongoing maintenance cost depends on the number and complexity of PTEs, but it is a real annual cost that should be in the support budget from the start. A single, well-scoped PTE maintained by an experienced partner is manageable. A large catalogue of PTEs, some of which were built opportunistically rather than out of genuine need, creates compounding maintenance cost and system complexity. The way to control this cost is to govern customisation requests upfront: configure first, AppSource second, bespoke only when there is a clear, measurable business case.

How do BC extensions handle Microsoft's twice-yearly updates?

BC extensions are designed to be upgrade-compatible. When Microsoft releases a new version, extensions either pass the automated compatibility check and upgrade automatically, or the partner responsible for the extension is alerted to fix it before the update goes live. This is the fundamental structural improvement over Dynamics NAV, where every update required manually re-applying C/AL customisations. For AppSource extensions, the publisher is responsible for compatibility. For PTEs, the partner who built the extension is responsible. This is why the question "who maintains this extension and how?" is an important one to ask before commissioning any bespoke development.

Closing Thought

The extension model is genuinely better than what came before. BC can update twice a year. Customisations do not create the upgrade debt that NAV did. That is a real structural improvement.

What has not changed is the temptation to customise processes that should be changed, not preserved. Every bespoke extension is a commitment: to maintain it, to test it with each update, to document it, and to explain it to the next partner or team member who has to work with the system. That commitment is worth making when the business case is clear. It is not worth making because configuration feels like compromise or because the current process is familiar.

The right question is not "can we customise this?" It is "should we?"

Zoosh Digital's approach is to work through every customisation request with a business case framework before writing any AL code. If you are in a scoping conversation and want an honest assessment of which requests genuinely need bespoke development and which can be met through configuration or AppSource, contact Zoosh Digital.

Referenced Sources

• Microsoft Learn. Developing Extensions in Business Central. learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-dev-overview.
• Microsoft Learn. Lifecycle of Apps and Extensions FAQ. learn.microsoft.com/en-us/dynamics365/business-central/dev-itpro/developer/devenv-update-app-life-cycle-faq.
• Microsoft Learn. Business Central Extensions by Other Providers. learn.microsoft.com/en-us/dynamics365/business-central/ui-extensions-other.
• Microsoft Learn. Dynamics 365 Business Central 2025 Release Wave 1 Overview. learn.microsoft.com.
• Microsoft. Dynamics 365 Business Central pricing and licensing. microsoft.com/en-ie/dynamics-365/products/business-central.