Business Central AL extensions: per-tenant vs AppSource path

Mid-market distributors adopting Business Central often ask the same question at the end of a customization project: should the work be shipped as a per-tenant extension, or productized as an AppSource app to sell to similar distributors? The technical work is almost identical. The ALM, support model, and business case are completely different.

What an AL extension is

Business Central customizations are AL code packaged as an extension. AL is a TypeScript-ish language specific to BC - it's not X++. An extension can add pages, tables, report layouts, API endpoints, and business logic through events and handlers.

Every customization in modern BC (SaaS) must be an extension. Direct modifications to the base code aren't possible. This is the opposite of old NAV where partners shipped customer-forked code.

Per-tenant publishing

Per-tenant means building the .app file, uploading it to a specific customer's BC environment via the Admin Center or PowerShell, running only there.

Pros:

Zero Microsoft review cycle - ship updates the same day
Direct access to customer data during support
Customer-specific pricing, UI, business logic without generic abstractions

Cons:

You maintain it per-customer forever
No automatic updates - each customer environment needs manual publish
No marketplace visibility
Revenue is billable consulting, not a product

Per-tenant fits custom consulting: the customer wants their rules, they're paying for the development, and the codebase is theirs.

AppSource publishing

AppSource is Microsoft's marketplace. You build the same .app, submit to Microsoft, pass validation, and it becomes installable from the catalog by any BC customer.

Pros:

One codebase, many customers
Automatic distribution via Microsoft's CDN
Recurring revenue via subscription licensing
Marketplace SEO and visibility

Cons:

Microsoft review cycle: 2-8 weeks per submission
Strict validation: naming prefixes, object ranges, test coverage, per-tenant settings
Can't touch customer data in support without a session
Feature work is slower - configuration for every variant slows iteration

AppSource fits product thinking: the rule is generalizable, the market is multiple customers, the economics work as a subscription.

The technical setup that's identical

Whether per-tenant or AppSource, the AL project structure is:

app.json              # Manifest: publisher, name, version, dependencies, idRanges
.vscode/launch.json   # Connection to test sandbox
src/
  Tables/             # Table objects
  Pages/              # Page objects
  Codeunits/          # Business logic
  Reports/            # Report definitions
  APIs/               # Custom API endpoints
  Enums/              # Enumerations
test/
  Codeunits/          # Unit tests

The app.json manifest is the control file. Publisher, name, version, and ID ranges all live there. For AppSource, these have to match your registered AppSource developer profile and assigned ID range (typically 50000-99999 for ISVs).

Dependency management

An extension can depend on Microsoft's Base Application, System Application, or other extensions. Declare dependencies in app.json:

"dependencies": [
  {
    "id": "437dbf0e-84ff-417a-965d-ed2bb9650972",
    "publisher": "Microsoft",
    "name": "Base Application",
    "version": "24.0.0.0"
  }
]

Version pinning is critical. Pin to the lowest version with the features you need. Overly aggressive pinning locks customers on old BC versions. Too loose and your extension calls APIs that don't exist in older builds.

For AppSource, compatibility declarations ("application": "24.0.0.0") are validated: Microsoft checks you've tested against the declared range.

Events and handlers

AL doesn't have a direct Chain of Command like X++. Instead, events are first-class. Microsoft publishes events at key points in base code; you subscribe:

codeunit 50100 "MyCustomerExt"
{
    [EventSubscriber(ObjectType::Table, Database::Customer, 'OnAfterInsertEvent', '', false, false)]
    local procedure OnAfterCustomerInsert(var Rec: Record Customer)
    begin
        if Rec."Customer Group Code" = 'PREMIUM' then
            // Custom behavior
    end;
}

The subscriber pattern is cleaner than X++ CoC in one way: the subscriber doesn't need to know the method signature. Downside: if Microsoft doesn't publish an event where you need one, you're stuck or you request one via the AL feedback portal.

Testing that ships

Every AL extension ships its own test runner. Tests are codeunits with [Test]:

codeunit 50101 "MyCustomerExtTests"
{
    [Test]
    procedure PremiumCustomerGetsDiscount()
    var
        Customer: Record Customer;
        Discount: Decimal;
    begin
        Customer."Customer Group Code" := 'PREMIUM';
        Customer.Insert();
        Discount := CustomerExt.CalculateDiscount(Customer);
        Assert.AreEqual(10.0, Discount, 'Premium customer should get 10% discount');
    end;
}

For AppSource, Microsoft requires ≥80% test coverage on public procedures. For per-tenant, the bar is discretionary - but experienced teams hold the same standard because the alternative is a midnight support call.

Deployment via pipelines

Azure DevOps handles both paths:

Build: al-go or custom PowerShell calling alc.exe
Package: sign the .app with the AppSource cert (required for AppSource, optional per-tenant)
Deploy per-tenant: publish via PowerShell to the customer's environment through BC Admin Center API
Deploy AppSource: upload to Partner Center, Microsoft validates, customers receive auto-update

The pattern that works for the distributor-productization scenario at the top: ship per-tenant first, then productize after the third or fourth distributor asks for the same feature. The per-tenant revenue funds the AppSource polish.

Choosing the path up-front

Questions that steer per-tenant vs AppSource:

Is the business rule specific to this customer? → per-tenant
Is it industry-generalizable? → AppSource
Does the customer want to own the code? → per-tenant
Is there a repeat-sale market of 10+ customers? → AppSource
Are update cycles driven by customer or product roadmap? → per-tenant vs AppSource respectively

Get this wrong and you either over-engineer a one-off (per-tenant work trapped in generic abstractions) or under-engineer a product (AppSource app that needs customer-specific patches).

What every BC extension ships with

Regardless of path, a BC extension ready for production has: prefixed object names matching AL best practices, ≥80% test coverage, CI pipeline with automated publishing, event-based extensibility (so customers can extend your extension), and a README with configuration steps.

The per-tenant version is a fork-able consulting deliverable. The AppSource version is a product. Both live on the same technical foundation.

推荐订阅源

DEV Community