Architecture

Business Central AL development: when to extend, who to hire, and how to govern it

A practical buyer guide to AL development for Dynamics 365 Business Central, including extension scope, AppSource versus per-tenant choices, testing, security, and partner evidence.

AL is the development language used to build and extend Microsoft Dynamics 365 Business Central. For buyers, the important question is not whether AL can change the system. It is whether the change is worth owning after go-live.

Business Central has a strong extension model, a large partner ecosystem, AppSource apps, and useful configuration options. That gives buyers choices, but it also creates a common risk: approving custom AL work before the business has proved that standard capability, configuration, reporting, integration, or a supported app will not solve the problem cleanly.

A good AL decision should protect the future ERP estate. It should solve a stable business gap, stay inside supported extension patterns, include tests and documentation, and leave the customer with a support model that survives Microsoft updates and partner changes.

What AL is used for in Business Central

• Microsoft describes AL as the foundation for developing extensions in Business Central.
• Microsoft's developer documentation explains that extensions add functionality by defining new objects or modifying behaviour around the solution, with AL code saved in files using the `.al` extension.
• AL development is normally done in Visual Studio Code with the AL Language extension for Microsoft Dynamics 365 Business Central.
• In practical terms, AL can affect tables, pages, reports, codeunits, permissions, events, and business logic, so it should be treated as a governed product change rather than an informal tweak.

Where AL development can genuinely help

• Stable process gaps: the business has a repeated, valuable need that standard Business Central cannot cover through configuration, workflow, reporting, or a proven app.
• Controlled industry fit: the requirement reflects a durable operating rule, not a temporary preference from one workshop or one legacy process owner.
• Integration boundaries: AL may be appropriate where Business Central needs structured data or behaviour that cannot be handled safely by a standard connector or low-code workflow alone.
• Reporting and document output: some reporting, document, and data-capture needs can justify extension work when standard layouts or analytics do not meet the control requirement.
• Usability improvements: targeted AL changes can reduce manual steps, validation errors, or exception handling if the team can prove the benefit and support burden.

What should stay standard

• Do not write AL simply to recreate old NAV, spreadsheet, or manual habits in a new cloud ERP.
• Do not customise screens or posting behaviour before users have tested standard Business Central with real transactions and realistic exception cases.
• Do not use AL to avoid business decisions about process standardisation, master data ownership, approvals, or reporting governance.
• Do not approve a custom extension when an AppSource app, partner-supported vertical product, Power Platform workflow, report change, or integration service provides a cleaner ownership path.

AppSource app or per-tenant extension

• Microsoft documents Marketplace apps and per-tenant extensions as different ways to extend Business Central online.
• An AppSource app can be attractive when the need is common, the vendor has an ongoing product roadmap, and the business wants support to sit with a product owner rather than with one custom development team.
• A per-tenant extension can fit when the need is specific to the customer and no supported market app or configuration approach solves it cleanly.
• Buyers should ask who owns updates, support, source access, documentation, and exit assistance under each path. A lower initial build estimate can become expensive if the extension is hard to maintain or replace.

How to assess an AL developer or partner

• Ask for current Business Central online experience, not only older NAV or C/AL history.
• Ask how they decide between standard configuration, AppSource, Power Platform, integration, reporting, and custom AL before recommending code.
• Ask them to explain object ranges, app dependencies, permissions, source control, release packaging, sandbox testing, and rollback in buyer-friendly language.
• Ask for examples of extensions that stayed maintainable across Business Central updates.
• Ask how they document custom logic so finance, operations, internal administrators, and future partners can understand what was changed and why.
• Ask who will monitor incidents, fix defects, handle Microsoft update testing, and maintain the source repository after go-live.

Testing and release discipline buyers should require

• Use a sandbox environment and real process scenarios before any production release.
• Require tests for the main business flow, security permissions, integration side effects, posting behaviour, reporting output, and upgrade regression.
• Keep extension releases in the same change calendar as other ERP changes so users know what changed and support teams know what to watch.
• Maintain a release note, test evidence, rollback position, and named support owner for every extension update.
• Use performance and workload testing where an extension affects high-volume posting, warehouse transactions, integrations, or month-end routines.

Security and support implications

• AL work can introduce new objects, data access, permissions, and automated behaviour, so security design belongs in the first scope discussion.
• Microsoft documents permission-set extension objects and the AL object model, but the buyer still needs business approval for who can see or change sensitive records.
• Source code, packages, credentials, deployment steps, and support records should be available to the customer under the contract, not locked inside one consultant's laptop or one partner's private process.
• When the partner relationship changes, the business should still be able to identify installed apps, understand dependencies, export documentation, and hand support to another qualified provider.

Governance checklist before approving AL work

• Business value: what measurable problem does the extension solve?
• Standard-fit test: which configuration, reporting, workflow, AppSource, Power Platform, and integration options were considered first?
• Ownership: who owns the process, the technical design, the code, the repository, and production support?
• Scope boundary: which objects, permissions, integrations, reports, or documents are affected?
• Upgrade impact: what must be retested during Business Central updates and app changes?
• Security: which users, roles, duties, data, and audit controls are touched?
• Exit readiness: what documentation, source access, packages, and transition assistance would another partner need?

How ERP Search can help

• We can help buyers separate genuine AL development needs from configuration, reporting, integration, AppSource, or process-design work.
• We can help shape a short development brief that names the business outcome, standard-fit evidence, support expectations, security review, and partner evidence required.
• We can help compare Business Central partners or developers on maintainability, governance, and delivery fit rather than day rate alone.

Sources used

• Microsoft Learn: Developing extensions in AL for Business Central.
• Microsoft Learn: Get started with AL and AL development environment reference overview.
• Microsoft Learn: Object ranges for Business Central development.
• Microsoft Learn: Customising Business Central online using apps.
• Microsoft Learn release-plan page: Manage per-tenant extensions in admin center.
• Microsoft Learn: Permission set extension object for Business Central.
• Microsoft Learn: Test the advanced sample extension and Performance Toolkit extension.

FAQ

• Is AL the same as X++? No. AL is used for Business Central extensions, while X++ is used in Dynamics 365 finance and operations apps.
• Should every Business Central gap become AL development? No. Buyers should test standard functionality, configuration, reporting, Power Platform, AppSource, partner vertical apps, and integration paths first.
• Are per-tenant extensions bad? No. They can be the right answer for customer-specific needs, but they need clear ownership, documentation, testing, and support.
• What is the main commercial risk? The main risk is long-term ownership: update testing, source control, permissions, support, and dependency on one developer or partner.