Customizing Business Central: Extensions & AL Development [2026]

The Extension Model: Core Principles

Business Central runs in Microsoft's cloud infrastructure, and all organizations are on the same version of the core application. You cannot modify the core code. Instead, you extend it through extensions. An extension is a compiled package containing custom pages, tables, codeunits (business logic), and reports that enhance Business Central without changing the base application.

Extensions are "layered" on top of the core. When Business Central processes a page or runs a codeunit, it executes the core logic, then allows extensions to hook in and add behavior. This is done via events (publish-subscribe), table extensions, page extensions, and report extensions. For example, a page extension adds a new field to an existing page without modifying the core page definition. A table extension adds a column to an existing table without touching the table's definition.

This design is powerful: Microsoft can update the core, and your extensions continue to work because you're not modifying core objects. You simply layer on top. As long as Microsoft maintains the event hooks and API surfaces your extensions depend on, your code remains compatible across major version upgrades.

Per-Tenant vs. AppSource Extensions

Business Central supports two types of extensions, each with distinct deployment and governance models.

Per-Tenant Extensions are private to a single tenant (organization). You develop them in your own VS Code environment, deploy them to your Business Central tenant, and version them independently. Per-tenant extensions are ideal for company-specific customizations—integrations with legacy systems, bespoke reporting, industry-vertical functionality not available in core. They live in your tenant, updated on your schedule, without affecting other organizations.

Deploying a per-tenant extension is straightforward: compile the AL code, create an extension package (.app file), upload it to your Business Central tenant via the Extension Management page, and install it. You can update it, uninstall it, or roll back to a prior version without Microsoft's approval. The tradeoff: you own the support burden and must test compatibility yourself when Business Central updates.

AppSource Extensions are distributed through Microsoft's AppSource marketplace and can be installed by any Business Central customer. They are multi-tenant solutions, meaning one extension package works across all tenants. AppSource extensions require higher code quality, must pass Microsoft's security review, and must comply with Microsoft's coding guidelines. In exchange, they reach a broader market and are sold and supported through AppSource.

Building an AppSource extension makes sense if your customization solves a problem for many organizations (e.g., industry-specific reporting for retail, HR integrations, specialized accounting workflows). Developing and maintaining an AppSource extension requires more effort, but the addressable market can justify it.

AL Language & Development Tools

AL (Application Language) is a purpose-built language for Business Central customization. It is statically typed, similar in structure to C# but with a shallower learning curve, and compiles to intermediate language that runs in the Business Central runtime.

A simple AL example: you want to add a field to the Customer table and validate it on save. You write a table extension in AL:

tableextension 50100 CustomerExt extends Customer
{
  fields
  {
    field(50100; "Custom Field"; Text[100])
    {
      trigger OnValidate()
      begin
        // Your validation logic
      end;
    }
  }
}

The table extension adds the field without modifying the core Customer table. When a user enters data into the field, your validation logic runs automatically. The syntax is clear, the type system prevents many errors, and the compiler gives you immediate feedback.

Development happens in Visual Studio Code with the AL Language extension. VS Code provides IntelliSense (auto-complete), debugging, syntax highlighting, and integration with Business Central APIs. You install the AL Language extension, connect to a Business Central sandbox environment, and start developing. AL projects are structured with a .al.json file describing the project, source files (.al extension), and configuration.

The AL language includes built-in types (Text, Integer, Decimal, Date, etc.), tables (ways to query and update data), codeunits (business logic classes), pages (user interfaces), and reports (formatted output). You have access to the full Business Central API—functions to post journals, update inventory, send emails, integrate with external services. This breadth means you can build sophisticated customizations entirely within the Business Central ecosystem.

Sandbox Environments & Testing

Before deploying any extension to production, you test it in a sandbox environment. A sandbox is an isolated copy of your Business Central tenant—same data, same company structure, but completely separate from production. You can deploy extensions to the sandbox, run tests, corrupt data, and start over without affecting live users.

Business Central allows you to create multiple sandboxes. A typical setup includes a development sandbox (where you deploy and test your own extensions), a testing sandbox (where business users validate behavior), and a UAT sandbox (where final approval happens before production deployment). When you're ready for production, you deploy the same extension package to production.

Sandboxes can be created from production data (giving you a realistic dataset to test with) or from standard demo data. You can refresh a sandbox at any time, pulling the latest production data for testing against current records.

Upgrade-Safe Development Patterns

An upgrade-safe extension is one that survives a Business Central major version update without breaking. Microsoft publishes major updates (typically twice yearly), and all tenants are automatically upgraded on a rolling schedule. Your extensions must not break during these upgrades.

Key patterns for upgrade-safe code:

Use Events, Not Modifications. Instead of modifying core codeunits, subscribe to events they publish. If Microsoft refactors a codeunit's internal logic, the event interface usually stays the same, and your subscriber continues to work. For example, a "before posting" event on the Sales Header table lets you run custom validation before any sales order is posted, without modifying the core posting logic.

Extend Tables, Not Modify. Use table extensions to add fields. Core fields might change; your extension fields are isolated. If you rename a field in an extension and Business Central later changes that field in core, both can coexist.

Use APIs & Documented Interfaces. Microsoft publishes stable APIs (sets of fields, functions, events) that are committed to remain compatible across versions. Use these APIs in your code. Avoid undocumented internals, which can change without warning.

Avoid Hard-Coded IDs & Assumptions. Hard-coding table or field IDs creates brittle dependencies. Instead, use the Table::Get() function to query objects by name, or parameterize IDs through configuration.

Test on Sandboxes Before Upgrading. Business Central publishes pre-release builds of major versions in "early access" sandboxes. Deploy your extensions there weeks before the mandatory upgrade to catch issues early. Most compatibility issues can be identified and fixed before production is affected.

Migrating from Dynamics NAV to Business Central Customizations

Organizations upgrading from Dynamics NAV (on-premise) to Business Central (cloud) often have legacy customizations. Direct porting is rarely feasible because NAV and Business Central have different architectures: NAV customizations modify core C/AL code; Business Central customizations layer via extensions. Additionally, some NAV features (batch jobs, classic client reports) don't exist in Business Central.

A typical migration approach:

1. Analyze NAV customizations to understand what they do (business problem they solve).

2. Determine if Business Central core already provides the functionality. If yes, use core instead of re-building the customization.

3. For truly business-critical customizations that Business Central doesn't provide, plan to re-write them as AL extensions.

4. For complex NAV customizations (thousands of lines of C/AL), evaluate whether they're still needed or could be solved with modern Business Central features (e.g., workflow rules, Power Automate, Power Apps) instead.

5. Plan to test heavily in a Business Central sandbox using production NAV data migrated to the sandbox.

This assessment typically takes several weeks and is essential for a successful migration. A partner experienced in both NAV and Business Central can accelerate the process and help prioritize which customizations to preserve.

Performance & Scalability Considerations

AL code runs in the Business Central cloud environment, which is multi-tenant and auto-scaling. As you write extensions, keep performance in mind:

Avoid nested loops and N+1 query patterns. If you're iterating through 1,000 sales orders and, for each, querying sales lines, you'll issue 1,001 database queries. Instead, load all sales lines in one query and loop through memory.

Use filtering and aggregation in AL queries (Where, GroupBy, Sum) to push computation to the database rather than loading all records into memory and filtering in code.

Monitor query performance. Business Central includes a query performance profiler you can use in sandbox environments to identify slow queries and optimize them.

Be careful with scheduled codeunits that run frequently. If a scheduled codeunit runs every minute across a multi-tenant system, it can consume significant resources. Schedule infrequently, batch operations, and optimize logic.

Support & Versioning Strategy

Per-tenant extensions are your responsibility to support and maintain. Create a versioning strategy: semver is common (major.minor.patch). Document your extension, create unit tests, and maintain a changelog. When Business Central updates, test your extension on the new version and release a compatible version promptly.

For AppSource extensions, you must support multiple Business Central versions. Microsoft typically maintains three versions in support at any time. Your extension should be tested against all three, and you should publish updates as new versions are released.

Key Takeaways

Business Central customization through extensions is fundamentally different from on-premise ERP modification. Extensions are decoupled from core, survive upgrades, and leverage cloud scalability. AL is a modern language designed for rapid customization. Sandbox environments allow safe testing before production deployment. Following upgrade-safe patterns—using events, table extensions, documented APIs—ensures your customizations remain compatible as Business Central evolves. For organizations migrating from NAV or planning new Business Central implementations, investing time to understand the extension model and AL development practices pays dividends in maintainability and long-term cost savings.