Last updated: November 10, 2026
By ZapAI Team
Business Central extensions are packages of AL code that add fields, pages, logic and integrations to Microsoft Dynamics 365 Business Central without changing Microsoft’s base application. They come in three kinds. Apps from AppSource, which Microsoft has folded into Microsoft Marketplace, per-tenant extensions built for one customer, and dev extensions that live only in sandboxes. Every one of them has to keep up with two major updates a year.
Business Central extensions are AL code packages that add features to Business Central. Buy an AppSource app when the need is common, build a per-tenant extension when it’s unique and transactional, and use Power Automate or Copilot Studio when it isn’t.
Every Business Central customer we meet has apps installed. Few can say who approved them, what each costs per year, or who gets the email when one blocks an update. No criticism intended. Installing is easy. Owning is the hard part, and it shows up in March or September, when a grace period ends.
This guide is for finance and IT leads deciding whether to buy an app, build an extension, or skip code and use Power Platform. Product facts come from Microsoft Learn and Microsoft’s pricing page, checked on November 10, 2026. Opinions are labeled as ours.
What Are Business Central Extensions?
An extension is a package of AL code that adds to Business Central without editing Microsoft’s code. It can add tables, fields, pages, reports, business logic and connections to outside services, and it installs, updates and uninstalls as one unit.
Under the hood, Business Central online is built this way. Microsoft’s guide to managing apps describes every environment as a collection of apps, Microsoft’s and other publishers’ together. The Base Application is an app. So is the System Application. Microsoft also ships optional first-party apps, such as PayPal Payments Standard, Envestnet Yodlee Bank Feeds and Late Payment Predictions.
Extensions don’t overwrite base code. They subscribe to Microsoft’s events, extend tables and pages, and add their own objects, which is what lets Microsoft update your environment monthly without anyone merging code. It’s also why NAV customers must convert old C/AL modifications first, which our NAV to Business Central migration guide covers step by step.
Apps also depend on each other. Remove a library app and everything built on it goes too. Draw the map.
How Do AppSource Apps, Per-Tenant Extensions and Dev Extensions Differ?
AppSource apps are global apps published once and installed by any customer. Per-tenant extensions, or PTEs, are uploaded to one specific environment. Dev extensions are published from Visual Studio Code or Designer and exist only in sandboxes.
| Type | Who publishes it | Where it can run | Who controls versions | Can depend on |
|---|---|---|---|---|
| AppSource app (global) | An ISV, through Microsoft Marketplace | Production and sandbox | The publisher ships versions, your admin applies them, and major updates move it to the latest compatible version | Other global apps only |
| Microsoft app (global) | Microsoft | Production and sandbox | Microsoft, with every Business Central update | Other global apps |
| Per-tenant extension | Your partner or in-house developer | Production and sandbox | You decide when to publish, install, upgrade or remove it | Global apps, other PTEs, dev extensions |
| Dev extension | A developer, from Visual Studio Code or Designer | Sandbox only | Uninstalled when the sandbox is upgraded or relocated, with data kept | Global apps, PTEs, other dev extensions |
This table condenses Microsoft’s extension types and scope page, updated August 2026. A global app and a PTE can’t share the same app ID, and if a publisher later lists an app on Marketplace under the ID of an existing PTE, the PTE can no longer be updated. Odd edge case. Real consequences.
One change is coming. Uploading PTEs from the Extension Management page is deprecated and planned for removal in 2027 release wave 1, with the admin center and its API as the replacement. Still deploying the old way? Move.
What matters most isn’t technical. It’s ownership. With an AppSource app, the publisher carries the update burden for every customer at once, while with a PTE you and your partner carry it alone, and Microsoft’s terms say so in plain words that a lot of statements of work leave out.
What Does AppSource Validation Check, and What Doesn’t It?
Validation is a technical gate. Microsoft checks that an app is signed, compiles against its dependencies, follows coding rules and doesn’t break earlier versions, for every country and release it targets. It doesn’t prove the app does its job well.
Microsoft’s technical validation checklist lists the mandatory requirements, and it says the technical validation is fully automated. Here’s what a submission has to clear.
- A valid manifest whose name, publisher and version match the offer listing
- Registered affixes and a registered object ID range for the publisher
- A digitally signed app file
- Compilation against its resolved dependencies, per country and release
- AppSourceCop analysis with no violations or breaking changes
- Its own permission sets, so users never need SUPER to set it up or use it
- Upgrade code, data classification on every field, and translation files
- A clean publish, sync, install, uninstall and reinstall cycle
That’s useful. A passing app installs cleanly. It shouldn’t demand SUPER.
Now the gaps. Microsoft’s page on maintaining Marketplace apps and PTEs says Microsoft tests code for technical compatibility and the publisher is still responsible for all functional and logical validation. So nobody at Microsoft confirmed that a tax app calculates your county rate correctly, that an EDI app maps your largest customer’s documents, that support answers within a day, or that the outside service an app calls handles your data the way you’d expect. Those are your questions to ask.
Section 1400 of the commercial marketplace certification policies adds one promise. Add-on apps must function, and their data must upgrade, on the current version of Business Central online. Sources conflict on pricing, though. Section 1400.3 lists add-on apps as Free, Free or Trial, or Contact Me, while Microsoft’s developer docs describe paid per-user plans sold through Marketplace since version 23. Check each listing.
What Happens to Extensions When Business Central Updates?
Microsoft ships two major updates a year, in April and October, plus a minor update every other month. Each major release gives you a five-month update period and a one-month grace period. After that, an extension that blocks the update might be uninstalled automatically, with its data kept.
Dates come from Microsoft’s update cycles page, updated October 2026.
| Period | When | What it means for extensions |
|---|---|---|
| Preview | About a month before each April and October release | Create sandboxes on the preview version. Microsoft automatically tests PTEs running in production and emails your notification recipients about incompatibilities. |
| Update period | Five months from general availability | Admins schedule the update. A failed update rolls the environment back and retries seven days later. |
| Grace period | One month, September or March | The update date can’t be pushed later. Users may see in-product warnings. |
| Enforced update period | After the grace period ends | Extensions blocking the update might be uninstalled automatically. Data stays and returns when a compatible version is installed. |
| Critical security update | Any time | An incompatible app, PTE or dev extension blocking it might be uninstalled within 14 days. |
| Minor updates | Every month except April and October | By default, AppSource apps update only with major updates. |
Read the enforced period row twice. Uninstalling an extension keeps its tables, yet every process that depended on it stops until a compatible version arrives, and Microsoft notes that the compatible version won’t install itself automatically on environments where it was removed. Picture a warehouse scanning app vanishing on a Monday. Data safe. Shipping stalled.
Publishers face a clock too. An app incompatible with the newest version might be pulled from Marketplace 30 days after release, which blocks new installs but leaves yours alone. And there’s no undo. After a successful update, you can’t restore to a version in its grace or enforced period.
A note on older advice. Partner blogs still describe a rule that removes a PTE 90 days after the first incompatibility notice. The current Microsoft pages, including the update lifecycle page for tenant customizations updated November 5, 2026, describe the update, grace and enforced periods instead. Plan around the Microsoft wording.
The settings that control timing
Four admin center settings decide how updates land, per Microsoft’s update management guide.
- Update window. The default runs 8 PM to 6 AM local time, the minimum is six hours, and an update that doesn’t finish inside it gets canceled and retried seven days later.
- Notification recipients. Microsoft’s incompatibility emails go here, and if nobody is listed, no email is sent.
- Apps Update Cadence. Default updates AppSource apps with major updates only. You can switch to minor and major updates. It doesn’t touch PTEs.
- Deployment schedule for PTEs. Upload a fixed PTE version set to install with the next major update, so the compatible code is in place before the switch.
Use a team alias for notifications. Not one person’s inbox.
What Can an Extension Access in Your Data?
An installed app runs its code inside your environment. Users reach its features through the permission sets it ships, but the app’s code can be granted rights its users don’t have, and it can call outside services. Treat every install as trusted code.
Start with who can install. Microsoft’s install and uninstall guide requires the EXTEND. MGT. – ADMIN permission set, or the D365 Extension MGT user group, to manage apps on the Extension Management page, and an Entra role with admin center access to use Manage Apps. Every user who works with an app also needs the permission sets that come with it.
Those permission sets are System type. You can’t edit them. Copy and trim instead.
Paid apps add a licensing layer. Entitlements map each Marketplace license plan to the app’s permission sets, and the license only sets the ceiling. Users still need permissions assigned inside Business Central. Access is the overlap.
Code is a different story. With inherent permissions, a developer can grant a method rights while it runs, for objects within the same extension, and Microsoft states that security administrators can no longer control a permission once it’s applied that way. That’s a sensible design for buffer tables and install code. It also means your permission review can’t see everything an app does. Ask the publisher where they use it.
Data can leave, too. Apps that call tax engines, EDI networks, payment gateways or scanning services send your records over HTTP to systems outside Business Central, and AppSource validation says nothing about how those services store them. In a sandbox copied from production, Microsoft blocks those calls until an admin turns on Allow HttpClient Requests for each extension, library apps included, per the production and sandbox environments page. Production has no such brake. Ask every publisher what data leaves, where it goes, and under which data processing terms.
Source code is protected by default. For PTEs whose IP you own, Microsoft recommends allowing debugging and including source in symbols. Put that in the contract.
Which Extensions Do SMBs Add Most?
In our project work, the usual additions are sales tax calculation, EDI, warehouse scanning, payment processing, document capture, financial reporting and US payroll. Some overlap with features Business Central now has natively, so check the base product before you buy.
| Category | What Business Central does natively | Why companies add an app | Overlap to check first |
|---|---|---|---|
| Sales tax | Tax areas, jurisdictions and rates you maintain yourself | Rate content and multistate exposure they’d rather not maintain by hand | Whether the app keeps or replaces your tax area setup |
| EDI | E-documents framework, with EDI exchange in public preview in version 29 | Trading partner maps, retailer compliance and a network connection | The e-documents roadmap |
| Warehouse scanning | Warehouse documents and mobile pages | Handheld scanners, label printing and faster picking screens | Warehouse features you already have |
| Payments | Payment journals, bank reconciliation, first-party bank feeds | Card processing, ACH and positive pay files for specific banks | Microsoft’s own bank and payment apps |
| Document capture | Inbound e-documents and the Payables Agent | OCR on varied invoice formats and approval routing | The Payables Agent’s limits and Copilot Credit cost |
| Reporting | Financial reports, Excel layouts, Power BI apps | Board packs and consolidation formats | Power BI before buying another report writer |
| US payroll | Not included | Payroll calculation and tax filing | An outside payroll provider with an integration |
Sales tax deserves caution, because Microsoft’s US sales tax documentation shows the native setup and tells you to work with your tax advisor on rates and effective dates. Fine for a company selling in a few jurisdictions. Harder for a distributor shipping to dozens.
Document capture has a newer rival. The Payables Agent turns PDF invoices into unposted purchase invoices for Copilot Credits per document, and our Business Central agents guide lays out its limits. Compare both before renewing an OCR subscription.
We won’t rank vendors. Fit depends on your volumes, trading partners and bank.
What Do Business Central Extensions Really Cost?
App prices are set by each publisher, per user, per environment, per transaction or by quote. A per-tenant extension costs partner time to build and then more partner time every April and October to keep it compatible, for as long as it stays installed. Neither shows up on Microsoft’s Business Central price list.
Microsoft’s Business Central pricing page lists Essentials at $80, Premium at $110 and Team Members at $8 per user per month, paid yearly, and says only that you can add apps. Our Business Central pricing breakdown covers the license side and how app pricing models scale. Here we’ll stick to what catches buyers out.
Transactable apps first. Microsoft’s guide to selling Business Central apps through Marketplace describes per-user plans billed monthly or yearly, an optional one-month free trial, and licenses you assign in the Microsoft 365 admin center. One line matters for budgeting. The number of app licenses can differ from your Business Central users, and nothing keeps the two aligned. Count who actually needs the app.
Then the costs nobody quotes.
- Setup and mapping, which can rival a year of subscription on EDI and tax apps
- Regression testing every April and October
- PTE upkeep, owned by you and your partner
- Duplicate apps doing overlapping jobs
- Exit cost, if data lives in app tables
For PTEs, budget year two before approving year one. Microsoft tells resellers to spell out upgrade duties and upkeep costs in their terms. Silent contract? Ask. Our Business Central implementation guide shows where extension work fits in the project plan.
Should You Buy an App, Build an Extension, or Use Power Platform?
Buy an app when the need is common across companies. Build a per-tenant extension when logic has to run inside a Business Central transaction and nothing on Marketplace fits. Use Power Automate, Power Apps or Copilot Studio when the work happens around Business Central rather than inside it.
These are ZapAI’s default rules. A real requirement can overturn any of them.
| If the need is | Our default | Why |
|---|---|---|
| Hiding fields, reordering pages, simplifying a role | Personalization or profile customization | No code, nothing to upgrade |
| Emailed quote requests or PDF vendor invoices | Built-in agents | Microsoft maintains them, billed per document |
| Approvals, alerts or moving data to Teams, Outlook or SharePoint | Power Automate | Event triggers and the approvals connector, outside the posting path |
| A focused form for people who rarely open Business Central | Power Apps | Fast to build, though licensing needs checking per user |
| Plain-language questions or actions across several systems | Copilot Studio agent | Uses the connector or MCP server with the user’s own permissions |
| Sales tax, EDI, payments, scanning, payroll | AppSource app | Shared problem, regulated content, publisher carries updates |
| Validation that must block a posting, new tables, unique pricing logic | Per-tenant extension | Only AL runs inside the transaction |
Our first test is simple. Must it stop a posting? Then it’s AL. A flow reacts after a sales order exists. It can’t reject that order before the ledger sees it.
Power Automate earns its place for everything that happens next. Microsoft’s Power Automate integration overview describes automated flows triggered by record changes or business events, instant flows users run from the Automate menu, and approvals. One limit stands out. The Business Central connector doesn’t support service-to-service, service principal or managed identity authentication, so unattended flows run under a named user’s connection. Plan who that is. Our Power Automate team builds those flows, and our Power Apps developers handle the forms.
Copilot Studio agents are the newest option. Microsoft’s guide to creating Copilot Studio agents for Business Central says the connector and MCP server act with the signed-in user’s permissions, and builders need a Copilot Studio license with Copilot Credits capacity. The MCP default is read-only. Keep it that way at first.
No-code still needs discipline. Our Power Platform ALM guide covers moving flows and agents to production safely.
How Should You Vet a Business Central App Before Installing It?
Check the publisher’s update record, the app’s permissions and outbound data, its licensing model, its dependencies and its exit path, then test it in a sandbox copied from production before anyone signs. Below is the checklist we work from.
Before the demo
- Does the listing name your country and your Business Central version?
- How fast did the last three major updates ship?
- Is it transactable, quote-based or both?
- Which other apps does it depend on?
- Who provides support, the publisher or a reseller?
- Can you get references in your industry?
In the sandbox
- Install it in a sandbox copied from production, never in production first.
- Turn on Allow HttpClient Requests only for the apps you’re testing, and log what they call.
- Assign its permission sets to a test user without SUPER and run every process.
- Check which base pages and posting routines it changes.
- Uninstall it, reinstall it, and confirm the data comes back.
- Run a month-end close with it installed.
Before production
- Get the data processing terms for any outside service it calls.
- Write down the exit plan. Which tables, which export, which replacement?
- Confirm the license count and renewal date.
- Name an internal owner.
- Add it to the app inventory.
Preview versions need their own rule. Per Microsoft’s managing apps page, preview versions of Marketplace apps install only in sandboxes through a publisher’s preview key, updating one triggers a force sync that can lose data, and nothing in the admin center or Extension Management flags an installed version as a preview. Track them yourself.
Who Should Approve and Manage Extensions?
One named owner should approve every install, and only a small admin group should hold extension rights. Test every new app in a sandbox copied from production, and track each installed app in one inventory with an owner and a renewal date that you review before every major update.
Below is the governance model we set up for clients. Practice, not policy.
- Limit EXTEND. MGT. – ADMIN to two or three people, and remove it from implementation accounts after go-live.
- Route every new app or PTE through a short request that names the business owner, the cost and the data it touches.
- Test in a sandbox copied from production. Business Central Essentials and Premium include three sandboxes, so there’s room.
- Keep notification recipients current, using a shared alias that IT and your partner both read.
- Pick an Apps Update Cadence on purpose and record why.
- Keep PTE source in a repository your company controls, with a build pipeline your partner can’t take with them.
- Review the inventory every February and August, before the preview environments open.
Item six is about control. If the only copy of your PTE source sits on a partner’s laptop, changing partners turns into a rebuild, which is exactly the trap our guide to switching your Dynamics 365 partner warns about.
Power Platform needs the same treatment. Flows and Copilot Studio agents touching Business Central belong under your data policies and environment strategy, which our Power Platform governance guide sets out. Integrations with CRM count too, and our Business Central and Dynamics 365 Sales integration guide shows where the built-in sync ends and custom work begins.
Coming from GP? Same inventory, different add-ons. See our GP to Business Central migration guide.
What Could Change After Ignite 2026?
Possibly a few things. Ignite runs November 17 to 20, 2026, in San Francisco. Extension rules rarely change at conferences, but agent tooling and Marketplace terms move fast. Expect a refresh by late November.
We’ll watch MCP data query tools, new Copilot Studio tools for Business Central, and Marketplace selling terms.
Wrapping Up
Extensions are how the product grows, and every one carries an owner, a cost and an update clock. AppSource validation proves an app installs and compiles. It doesn’t prove it fits your business. Buy for common problems, build only for logic that must run inside a transaction, and push everything else to Power Platform. Then govern all of it.
ZapAI is a Microsoft Dynamics 365, Power Platform, Fabric and AI consulting firm in Irving, Texas, working with businesses across Dallas-Fort Worth and nationwide. Our Business Central consultants vet AppSource apps, build and maintain per-tenant extensions, and replace small customizations with flows where that’s the better fit. Not sure what’s installed in your environment right now? Ask us for a Business Central app review, and we’ll inventory your apps, permissions and update risks before the next release wave.
Questions Teams Ask About Business Central Extensions
What is a per-tenant extension in Business Central?
A per-tenant extension, or PTE, is AL code built for one customer and uploaded to a specific environment. You control when it’s installed or upgraded, and you and your partner are responsible for keeping it compatible with each Business Central update.
Does Microsoft test AppSource apps?
Technically, yes. Automated validation checks signing, compilation, coding rules and breaking changes for every targeted country and release. Microsoft says the publisher remains responsible for functional and logical validation, so business accuracy is yours to test.
What happens if an extension blocks a Business Central update?
The update fails, the environment rolls back, and Microsoft retries seven days later. If the problem lasts past the five-month update period and one-month grace period, the extension might be uninstalled automatically. Its data stays in the environment.
Do we lose data if we uninstall an app?
Not by default. Business Central keeps the data so a reinstall brings it back. If you turn on Delete Extension Data, the data for that app and its dependents is deleted, and only a point-in-time restore within 28 days can recover it.
Who can install apps in Business Central?
Users with the EXTEND. MGT. – ADMIN permission set or the D365 Extension MGT user group, on the Extension Management page. The admin center’s Manage Apps page needs an Entra role with admin center access.
Can we try an app before buying it?
Usually. Publishers selling per-user plans through Marketplace can offer a one-month free trial, and other listings offer trials or demos on request. Either way, install it in a sandbox copied from production first.
Should we use Power Automate instead of an extension?
Use Power Automate for approvals, notifications and moving data after something happens. Use an extension when logic must run inside Business Central, such as blocking a posting or adding tables. Plenty of requirements need both.