Per-Tenant Extensions vs Marketplace Apps in Business Central

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.

The practical difference

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

Choose a per-tenant extension when the requirement is genuinely specific

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.

Choose Marketplace when the capability is a product

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.

Do not use distribution type as an architecture shortcut

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.

Questions to answer before choosing

1. Will another unrelated customer buy the same capability without a code fork?
2. Can customer differences be handled through setup rather than conditional code?
3. Who owns the intellectual property and source repository?
4. Who must respond when a Business Central preview breaks the extension?
5. Does the app transfer data to another service, and how will privacy and consent be documented?
6. Does the business model justify Marketplace validation, listing, support, and release operations?
7. What happens to customer data when the extension is uninstalled or replaced?

A decision rule that stays useful

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.