Business Central Extensions: When to Use Extensions vs. Customizations

If you've spent any time researching how to tailor Microsoft Dynamics 365 Business Central to your business, you've probably run into both terms: extensions and customizations. They're often used interchangeably in conversations with ERP experts, but they're not the same thing, and choosing the wrong approach can make future upgrades painful, your implementation fragile, and your support costs higher than they need to be.

This guide breaks down exactly what each term means in Business Central today, when one is the right choice over the other, and how to think about your development decisions in a way that protects your investment long-term.

Business Central Extensions in Business Central Vs Dynamics NAV

Before Business Central, Microsoft's ERP platform was called Dynamics NAV, and developers customized it by modifying the base application code directly using a language called C/AL. You could change anything, which was powerful, but came with a catch. Every time Microsoft released an update, those changes had to be manually reconciled against the new codebase. Upgrades that should have taken days took months. Some companies stayed on outdated versions for years simply because upgrading was too expensive.

When Business Central launched in 2018, Microsoft replaced that model entirely. The new approach, AL-coded extensions, keeps all custom code completely separate from the base application. Microsoft's updates run automatically without touching your customizations. This wasn't minor, and it fundamentally changed the ERP environment.

Understanding this history is why the extensions vs. customizations question is worth taking seriously. The decisions you make now determine how much pain you carry forward every time Business Central updates, which happens automatically, multiple times a year.

What is a Business Central extension?

An extension is an add-on built in AL (Application Language) that layers new functionality on top of Business Central without touching the original source code. Think of it like a screen protector on a phone: it changes the experience, but the underlying device is untouched.

In practice, extensions can do nearly anything you'd want a full customization to do:

• Table extensions add new fields to existing tables (for example, adding a custom compliance field to the Customer table)

• Page extensions modify how existing pages look and behave, adding fields, actions, or rearranging layouts

• Codeunit extensions add or modify business logic, such as custom validation rules on a sales order

• Report extensions add data sources, new columns, or modify layouts on existing reports

• Event subscribers let your code hook into key moments in Business Central's built-in processes — before a document is posted, after a record is inserted — without touching the base logic at all

All of this is compiled into an .app package file that Business Central installs alongside the core product. When Microsoft updates Business Central, your extension stays intact. If a future update conflicts with an extension, Microsoft flags it in advance and gives development teams time to address it before the upgrade runs.

Extensions come in two main forms:

Per-Tenant Extensions (PTEs) 

Built for a single organization's specific needs and aren't published publicly. If your business has a unique pricing model, a specialized workflow, or a one-off integration with an external system, a PTE is the right vehicle. This is the type of extension A BC Consulting Group builds for clients, AL-coded, version-controlled in GitHub repositories, and designed to upgrade cleanly over time.

AppSource Extensions (ISV apps) 

Built by independent software vendors and published to Microsoft's marketplace. Products like Insight Works, Binary Stream, Avalara, and Sana distribute their functionality this way. If an AppSource solution solves your problem, using it is almost always faster and more cost-effective than building something from scratch.

What Do You Mean by "Business Central Customization?"

Here's where terminology gets slippery. Technically speaking, in the modern Business Central world, all custom development happens through the extension framework. There's no longer a supported way to directly edit the base application code. So in a strict sense, "customization" and "extension" mean the same thing today.

In practice, though, when clients and consultants talk about "customizations," they usually mean one of two things:

Configuration

Not code, such as adjusting settings, workflows, approval hierarchies, number series, posting groups, and permissions within Business Central's built-in tools. This requires no development work at all. A significant portion of what businesses think they need custom-built is actually achievable through configuration alone, if you know where to look.

Per-tenant extensions that are highly business-specific

Code built just for you, solving a problem that no out-of-the-box feature or AppSource solution addresses. These are genuine customizations in the sense that they're unique to your organization.

So before you get started, ask do you actually need to build anything at all, and if so, what's the right scope?

When to Build, and When to Not

Before commissioning any AL development, run through this sequence:

1. Does Business Central already do it?

Business Central is often underestimated. It covers finance, purchasing, sales, inventory, manufacturing, service management, project management, and reporting in a single platform. Many businesses that come to us convinced they need custom development haven't fully explored what's already there. Spend time with a knowledgeable consultant doing a proper fit-gap analysis before assuming a gap needs code.

2. Is there an AppSource solution?

If the base product doesn't cover your need, the AppSource marketplace is the next stop. There are thousands of apps covering industry-specific needs, compliance requirements, specialized warehousing, and dozens of other scenarios. Using a published AppSource extension means someone else is maintaining the code, handling compatibility with Business Central updates, and supporting the product a significant advantage over building from scratch.

3. Can you change the process instead of the system?

This is the hardest conversation to have, and the most valuable one. Many customization requests are really process change avoidance in disguise. "We need the system to work the way we've always worked" is a common brief that, when examined, often reveals a process that wasn't particularly efficient to begin with. The best implementations use the ERP as an opportunity to adopt better practices not to recreate legacy habits in a modern system.

4. If you're going to build, build it right

When a genuine gap exists that configuration and AppSource can't close, AL development is the answer. At this point, the question becomes one of quality and approach. Extensions should be:

• Built against the event-publisher model so they hook into Business Central's business logic without modifying it directly

• Stored in version-controlled repositories (we use GitHub) so changes are tracked, reviewable, and recoverable

• Tested in a sandbox environment before deployment, with automated testing incorporated where possible to protect against upgrade conflicts

• Scoped conservatively the smaller the footprint of custom code, the easier it is to maintain

Which Approach Is Best

Adding fields to capture business-specific data → Table extension + page extension. This is exactly what the extension model was designed for. Straightforward, upgrade-safe, and quick to build.

Custom approval workflows → Start with Business Central's built-in workflow engine and approval hierarchies. Most approval scenarios are configurable without any code. Only escalate to a codeunit extension if the logic is genuinely complex.

Integrating Business Central with a third-party system → Evaluate AppSource connectors first (many CRM, e-commerce, and payroll platforms have published integrations). If no connector exists, a custom integration built as a PTE using Business Central's API framework is the right path. Avoid middleware layers unless the integration is genuinely complex.

Industry-specific compliance or regulatory requirements → Often best addressed by a combination of AppSource (for established compliance tools) and PTEs for anything truly unique to your region or industry. Healthcare clients, for example, often need lease accounting logic and location-specific configurations that standard BC and a targeted extension set can handle together.

Rebuilding a report from your legacy system → Resist the urge to recreate everything. Start with Business Central's built-in financial reporting, Power BI integration, and existing report library. A report extension can add specific fields or calculations where the standard output falls short. Building an entirely new report from scratch should be the last resort, not the default.

Replicating every workflow from your old system → Don't. This is the most common and costly mistake in Business Central implementations. Legacy processes grew around the limitations of legacy software. Business Central's out-of-the-box processes are designed around modern best practices. A good implementation partner will help you distinguish between processes worth keeping and habits worth leaving behind.

Why Extension Architecture Matters

Business Central updates automatically, Microsoft releases two major waves per year plus regular monthly updates. In the old NAV world, each of these would have been a significant event requiring developer time to reconcile changes. In the extension model, updates are largely invisible if your development was done correctly.

"Largely invisible" is doing some work in that sentence. Extensions that subscribe to events properly, respect Microsoft's published APIs, and avoid reaching into base application internals upgrade with minimal friction. Extensions that use workarounds, reach into undocumented areas of the base code, or were built quickly without upgrade safety in mind create problems at every update cycle.

This is why the quality of your development partner matters as much as the quality of the code itself. AL development done well is an asset. AL development done carelessly is a liability that compounds interest every six months when the next update lands.

What to ask an ERP Partner Before You Engage

Whether you're evaluating A BC Consulting Group or anyone else for Business Central development work, these questions will tell you a lot:

Do you store all extensions in version-controlled repositories? Any professional team should be working in Git. If code isn't version-controlled, you have no history, no rollback, and no visibility into what changed and when.

How do you handle upgrades and compatibility testing? Ask specifically about their process for validating extensions before Business Central update waves. Automated testing pipelines are the gold standard.

Will you have access to the extension source code? You should own your extensions. Be cautious of partners who won't give you access to the code they've built for you.

Do you build using the event-publisher model, or do you modify base objects directly? The right answer is the event-publisher model. Modifying base objects directly is a red flag in the modern BC development world.

Do you evaluate standard functionality before recommending custom development? A good partner pushes back on customization requests that aren't necessary. If a partner enthusiastically agrees to build everything you ask for without questioning whether it's needed, that's worth scrutinizing.

Micrsoft Dynamics Extensions: The Bottom Line

In Dynamics 365 Business Central, the extension framework has genuinely solved the old NAV dilemma of flexibility versus upgradability. You can have both, but only if the development work is done with care and discipline.

The decision hierarchy is simple: configure first, use AppSource second, build only what you must, and build it properly when you do. Every layer of custom AL development you add is a layer of ongoing responsibility. The goal isn't a system that does everything you can imagine, it's a system that does what your business actually needs, cleanly and maintainably, years into the future.

At A BC Consulting Group, our development team works exclusively in AL, stores all extensions in GitHub, and builds for partners and customers alike. We evaluate standard functionality before recommending any custom build, and we design extensions that survive updates.

If you're planning a Business Central implementation, evaluating whether your current extensions are upgrade-safe, or exploring what's possible with AL development, contact our team to start the conversation.