// article
Per-tenant extensions and Microsoft Marketplace apps are both AL extensions, but they solve different distribution and ownership problems. Choosing the wrong model can leave a customer with unnecessary validation overhead, duplicated code across environments, or a critical customization whose support responsibilities are unclear.
The decision should be made before development starts because identity, deployment, dependencies, commercialization, testing, and release management all follow from it.
| Question | Per-tenant extension | Marketplace app |
|---|---|---|
| Who is it for? | One specific Business Central environment or customer | A repeatable product distributed to multiple customers |
| Who controls publication? | The customer or its partner controls publish, install, upgrade, and unpublish actions | The publisher submits releases through Microsoft Marketplace and its validation process |
| Identity | Defined by app ID, version, and environment scope | A global app identity distributed through Marketplace |
| Commercial model | Usually project or support work for one customer | Usually a supported product with repeatable licensing and documentation |
| Best fit | Customer-specific workflow, report, integration, or data model | Common capability that can be configured rather than forked |
A PTE is a strong fit when the functionality reflects one company's process, contractual rules, proprietary data, or integration topology. The customer and partner can control when it is published and upgraded, and the extension can depend on global apps or other PTEs.
That flexibility is not a license to create a separate fork for every preference. Parameterize what should be configuration, keep customer-specific code in a clear repository, and document the owner of every dependency. Multiple PTEs with the same ID and version can contain different content in different environments, but Microsoft warns that this creates management overhead. A reliable team makes every released package traceable to source and a build.
A Marketplace app is appropriate when the same core capability serves many tenants and can be supported through a shared product roadmap. It must be designed for multiple countries or clearly limited markets, clean installation and upgrade paths, tenant-safe configuration, documentation, telemetry, privacy, and support.
Marketplace distribution adds a Microsoft certification and technical-validation loop. That effort is valuable when it protects a repeatable product, but it is usually unnecessary for a one-customer workflow.
Both models require upgrade-safe AL. Both need source control, automated builds, tests, permission sets, upgrade code where schemas change, telemetry, and a documented support path. Neither model justifies modifying Microsoft base code.
A common product can also use a layered architecture: a Marketplace app supplies the shared capability, while a small PTE contains customer-specific orchestration. Keep the boundary explicit. The PTE may depend on the global app, but the global app cannot depend on the customer's PTE.
If the value is the customer's unique process, start with a well-engineered PTE. If the value is a repeatable capability for a market, design a product and accept the operational responsibilities of Marketplace. If the answer is uncertain, build a clean PTE boundary first, validate demand, and avoid promising a Marketplace product before the support and validation model exists.
Record that decision with the extension owner, target environments, dependency policy, upgrade cadence, support contact, and exit plan. Revisit it when a second customer asks for the capability. That review is the right time to separate reusable product code from customer-specific behavior instead of copying the original extension.
Bitta Apps can help with Business Central AL architecture, integration design, and release-wave support whether the correct destination is a customer-owned PTE or a reusable Marketplace app.