AL extension architecture

An AL extension is the package that delivers custom code, tables, pages, reports, and configuration to Business Central. Understanding the architecture is the first step to writing extensions that survive upgrades cleanly.

The package. An extension compiles to a single .app file — a signed, versioned package containing compiled AL objects, manifest, permission sets, translations, and runtime resources. The .app is what gets uploaded to a Business Central tenant or published to AppSource.

app.json. Every extension is rooted in an app.json manifest that declares the publisher, name, version, ID (GUID), the platform/application versions it targets, the runtime version, dependencies on other apps, and the object ID ranges the extension is allowed to use. App registration with Microsoft assigns the object range; collisions are not allowed.

Object types. Extensions can contain tables (new business entities), table extensions (extra fields and triggers on Microsoft's standard tables), pages (UI), page extensions (extra fields and actions on standard pages), codeunits (procedures), reports, queries, XMLports, permission sets, enums, and interfaces. The most common pattern in customer extensions is table extensions + page extensions + a few codeunits with event subscribers — adding fields and behaviour to the standard product without replacing it.

Events. Behaviour customisation happens through events: Microsoft and other extensions publish business and integration events; your codeunit subscribes to them and runs your code before, on, or after the original logic. This is what makes extensions upgrade-safe: when Microsoft changes the base code, your subscribers still bind to the same events.

Dependencies. An extension can depend on others by declaring them in app.json. The platform installs them in dependency order, and dependent extensions can extend each other's tables and pages.

The runtime. Business Central's AL runtime is a managed VM compiled from AL. Each request runs in its own session with transactional database access. The runtime enforces permission checks, multi-tenancy isolation, and event publication.

Sandboxes for development. AL developers use Visual Studio Code with Microsoft's AL Language extension, pointing at a Business Central sandbox environment as the runtime target. Publish, debug, deploy, and read symbols all work from VS Code against the sandbox.

Three deployment paths. The same .app can ship to AppSource (Microsoft-validated, sold to many customers), to a customer tenant as a per-tenant extension (uploaded directly, single-tenant), or — for on-premise BC — installed locally.