Blog
Publishing your solution to Microsoft AppSource
We have shipped more than ten solutions to Microsoft AppSource, including one approaching 3,000 objects. Every one of those projects taught the same lesson: the build is the easy part. This post describes the journey as we have lived it, and where projects usually stall.
What AppSource is, and why publish there
AppSource is Microsoft’s public marketplace where Business Central customers discover, trial and install third-party apps. A listing gives you reach, credibility and a self-service install path straight into a customer’s SaaS environment: no manual deployment, no per-tenant hand-holding.
For an ISV, AppSource turns a bespoke extension into a repeatable product. The same effort that today serves one client can serve hundreds, with Microsoft handling discovery and distribution.
The journey at a high level
The path has a recognisable shape, even if every app travels it differently:
- Partner Center account: your commercial identity with Microsoft, where the offer, listing and pricing live.
- App designed for multi-tenant SaaS: the code must run cleanly as a per-tenant extension, with proper ID ranges, no platform assumptions and no per-customer hard-coding.
- Technical validation via AppSourceCockpit and Microsoft’s pipeline: automated checks compile your app, run the test suite and enforce a long list of rules.
- Passing Microsoft’s automated validation: affixes, dependency rules, permission sets, translations and more must all be in order.
- Marketing collateral: listing copy, screenshots, a working trial, support and privacy URLs.
- Ongoing maintenance: your app must stay compatible across two major BC releases a year, indefinitely.
The build is only the first leg. The validation and maintenance legs are where unprepared teams lose months.
Why apps fail validation
The rejections we see most often are rarely about features. They are about discipline:
- Object IDs outside the registered range, or affix rules broken on standard object extensions.
- Missing or incomplete permission sets, so the app cannot be used by a non-admin.
- Dependencies that are not declared, or that point at apps not on AppSource.
- A trial that does not actually work, or a broken support/privacy URL.
- Test coverage that does not meet the bar, or code that fails the automated analysers.
Every one of these is fixable up front and expensive to discover late. Knowing the rules before you write a line saves a full validation cycle, and each cycle costs days, not hours.
The maintenance reality
A listing is never finished. Twice a year, a new BC version ships, and your app must be validated against it before customers upgrade. APIs get deprecated, analysers tighten, new rules appear. An app that is not actively maintained falls out of compatibility, and then out of the marketplace. Budget for the lifecycle, not just the launch; the cheapest time to plan for next year’s release is before you publish this year’s.
What the 3,000-object app taught us
Scale teaches you things no checklist can: how to structure object ranges so they never collide, how to pass validation on the first or second attempt rather than the fifth, and how to architect for a decade of twice-yearly upgrades rather than a single release.
The expensive part of AppSource is not the code Microsoft sees. It is the rework, the failed cycles and the maintenance debt you avoid by getting the structure right from day one. A partner who has done it end to end turns a multi-month gamble into a planned, predictable launch.
Publishing to AppSource is real work, and not every solution belongs there. When the fit is right, though, it is the single biggest multiplier available to a Business Central ISV.
Thinking about taking your solution to AppSource, or stuck in a validation loop? Tell us your story and we will tell you whether your solution belongs there — and what it will take.