Per-tenant extensions vs AppSource
By Emil Björk · Microsoft business apps consultant, Gothenburg
When to ship a Business Central extension as a per-tenant (PTE) vs publishing to AppSource — distribution, validation, and lifecycle differences.
On this page (7)
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.
Frequently asked questions
What is a per-tenant extension?
- An AL extension uploaded to one specific Business Central environment from the admin centre — for customer-specific fields, integrations, and workflows. It skips Microsoft's marketplace validation, ships as fast as you build it, and is invisible to other tenants.
What does AppSource validation give me?
- Microsoft pre-tests AppSource apps against upcoming release waves and gives ISVs early access to preview builds, so breaking changes surface before customers update. Per-tenant extensions get no such safety net — you recompile and republish yourself each wave.
Can I sell a Business Central extension without AppSource?
- Not as a packaged product to multiple customers. AppSource is the only marketplace route; Microsoft makes apps transactable with revenue share or lets ISVs use contact-me listings for offline sales.
What does a typical customer solution look like?
- A small per-tenant extension for bespoke needs plus several AppSource apps from ISVs for localisations, integrations, and vertical features. That hybrid 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.
- 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.
- The AL test frameworkWriting automated tests in AL — test codeunits, test runners, TestPage, mocking, test isolation, and CI with AL-Go.
- Writing your first AL extensionA first-walkthrough of building, publishing, and running a basic AL extension for Business Central — toolchain, project structure, and deployment.
- The Business Central API and OData servicesHow external systems talk to Business Central — the v2.0 REST API, OData web services, bound actions, and call limits.
Browse every guide in Business Central or just AL & development.
Was this helpful?
Signals which guides land and which need work. No account, no comment box — corrections go through the contact page.
Spot something wrong or want a topic covered? Send a correction or a topic request — both are welcome.