Per-tenant extensions vs AppSource
When to ship a Business Central extension as a per-tenant (PTE) vs publishing to AppSource — distribution, validation, and lifecycle differences.
Business Central extensions ship via two paths: a per-tenant extension (PTE) delivered directly to one customer's tenant, or a published app on AppSource delivered to the broader market. The same AL source can produce either; what differs is the lifecycle, validation, and economics around it.
Per-tenant extensions. A PTE is uploaded to one specific BC environment from the admin centre. The owner can be the customer's internal team or a partner working for that customer. PTEs are great for organisation-specific customisations — bespoke fields, custom integrations, unique workflows — that aren't reusable across multiple customers. They don't go through Microsoft's marketplace validation, so they ship as fast as you build them. They're invisible to other tenants.
Trade-offs of PTE. Speed, freedom from marketplace rules, and full ownership. But: you carry every upgrade burden yourself. Each Business Central release wave can break a PTE; the partner has to recompile it against the new platform and republish. Microsoft does not pre-test PTEs before the update window.
AppSource apps. An AppSource app is submitted to Microsoft for validation (technical, security, performance, and content review), then published in the marketplace, where any BC customer can install it. AppSource is the only way to sell a packaged Business Central extension to multiple customers.
The economics. Microsoft makes AppSource apps transactable — billed through Microsoft's commerce platform, with revenue share. ISVs can also use contact me listings for sales handled offline. The economics work because the cost of validation and the platform fee are amortised across many tenants.
The lifecycle. AppSource apps get early access to preview builds and Microsoft pre-tests them against upcoming release waves, flagging breaking changes well before customers update. That ongoing certification is the biggest operational reason to publish to AppSource even if you only have one initial customer.
Choosing. Build as a PTE when the code is genuinely one-customer-only. Build for AppSource when you expect to deliver the same functionality across multiple tenants, when the code is generic enough to package, or when you want Microsoft's compatibility safety net.
Hybrid. Many customer projects combine a small PTE for bespoke needs with several AppSource apps from ISVs for localizations, integrations, and vertical features. This is the normal shape of a Business Central solution.
Related guides
- AL extension architectureHow AL extensions are structured in Business Central — objects, namespaces, app.json, dependencies, and the runtime model.
- AL events and integration patternsHow AL events let extensions hook into Business Central — business events, integration events, subscriber patterns, and what to avoid.
- AL language and runtime evolutionHow the AL language for Business Central evolved from C/AL — runtime versions, language features added wave by wave, and what AL is becoming.
- Business Central CI/CD with AL-GoHow AL-Go for GitHub turns an AL extension repo into a build-test-deploy pipeline — secrets, environments, and continuous delivery.
- Business Central web servicesThe classic OData and SOAP web services in Business Central — how they differ from the v2.0 API, and when to use them.