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:

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:

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:

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]:

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.