From AppSource to Enterprise Procurement: Distributing Your Office Add-In to Large Customers
Every ISV that builds an Office Add-In eventually runs into the same uncomfortable truth: shipping working code is roughly half the job. The other half is Office Add-in distribution — getting the add-in validated, listed, approved by a cautious IT department, and deployed across thousands of seats inside a locked-down Microsoft 365 tenant. A great deal has been written about building add-ins. Almost nothing has been written about distributing them, which is strange, because distribution is where enterprise deals actually stall. The demo goes well, the product team is delighted, and then someone from the customer’s IT security function asks how, exactly, you intend to get this thing into their tenant, what permissions it requests, and where the data goes. If you do not have crisp answers, the deal waits while you find them.
This article is the missing manual. It covers the three distribution routes and when each fits, what Microsoft actually checks during AppSource submission, what enterprise administrators scrutinise before they approve anything, how a staged rollout really works, and how updates reach users once you are live. It is written for ISVs — the SaaS and software vendors we spend much of our time with — who have an add-in built or nearly built and now need it running inside large customers’ tenants. It deliberately avoids development how-to content; the assumption is that the engineering is done and the harder organisational problem is in front of you.
The Three Routes to a User’s Ribbon
There are three legitimate ways an Office Add-In reaches an end user, and choosing between them is the first distribution decision you make. (Sideloading — a developer manually loading a manifest into their own Office client — is a fourth, but it is a development and testing mechanism, not a distribution channel, and most enterprise tenants disable it for ordinary users anyway.)
Public listing on AppSource
AppSource is Microsoft’s public marketplace. A listing there makes your add-in discoverable to any Microsoft 365 user in the world, subject to their tenant’s policies, and it is the route Microsoft’s validation programme is built around. For an ISV selling a horizontal product, a public listing is close to mandatory: it is where prospects expect to find you, it signals that Microsoft has validated the add-in against its store policies, and — critically for enterprise sales — it is the catalogue that the Microsoft 365 admin centre draws on when an administrator deploys an add-in centrally. Even customers who will never let users install anything themselves generally prefer to deploy a validated AppSource listing rather than a manifest file you emailed them.
Private line-of-business deployment
If your add-in exists for a small number of known customers — or a single one — you can skip the public store entirely. An administrator in the customer tenant uploads your manifest as a custom app and assigns it to users. This route avoids AppSource validation and keeps the add-in invisible to the wider world, which suits genuinely bespoke work. Its weaknesses mirror its strengths: every customer deployment is a manual handover of manifest files, there is no Microsoft validation badge to lean on during security review, and each manifest update means asking every customer’s administrator to act. It works well at five customers and becomes an operational headache at fifty.
Admin-managed centralised deployment
The third route is less an alternative than the enterprise endpoint of the other two. Microsoft 365 centralised deployment, driven from the Integrated apps area of the admin centre, is how an administrator pushes an add-in — from AppSource or from an uploaded manifest — to specific users, groups, or the whole organisation. The add-in simply appears in users’ ribbons; nobody installs anything. For any customer above a few hundred seats, this is how you will actually deploy Office Add-ins to enterprise customers, and your job as the vendor is to make the administrator’s path through it as short as possible. Large tenants routinely block self-service installation from the store altogether, so “users can just install it themselves” is not a distribution strategy; the administrator is your real gatekeeper, and everything later in this article is about persuading that person.
AppSource Submission: What Microsoft Actually Checks
Submission happens through Partner Center, and validation is a genuine review rather than a rubber stamp. It helps to think of Microsoft’s checks in three layers.
The first layer is functional. Validators exercise the add-in as a user would: it must load without errors on the platforms your manifest declares, every advertised feature must work, and nothing may crash, hang, or dead-end. If your add-in requires an account on your platform — and for most SaaS companion add-ins it does — you must supply working test credentials and clear testing notes. A remarkable proportion of first-pass rejections are nothing more exotic than a validator who could not sign in.
The second layer is the manifest and metadata. The manifest must be technically valid, the requested permissions must match what the add-in actually does, and the listing content — description, screenshots, support URL, privacy policy, terms — must be present, accurate, and consistent with the product the validator experiences. Overstating capability in the description is treated as seriously as understating permissions in the manifest.
The third layer is trust. All add-in traffic must run over HTTPS, the privacy policy must exist and say something meaningful, and sign-in flows must behave properly — including graceful handling when consent is declined. Microsoft also operates a compliance programme above baseline validation, in which publishers can attest to (and optionally have certified) their security and data-handling practices. That is optional for listing but increasingly noticed by the enterprise administrators we discuss below, and for an ISV targeting regulated customers it is worth the effort.
Rejections and realistic timelines
The most common rejection causes we see are prosaic: missing or broken test accounts; functionality that fails on one declared platform (typically Office on the web or Mac when the team developed exclusively against Windows desktop); mismatches between manifest, description, and actual behaviour; missing privacy policies; and sign-in flows that trap the validator in a loop. None of these is hard to fix; all of them cost you a full validation round trip.
On timing, plan in weeks rather than days. An individual validation pass typically comes back within a few business days, but almost nobody passes first time, and each rejection means a fix, a resubmission, and another pass. Teams that budget a single validation cycle at the end of a project discover the problem precisely when a customer is waiting. Build two or three cycles into the plan and treat a first-pass approval as a pleasant surprise. When we worked with AuditBoard — a provider of auditing, compliance and risk management software whose add-in links evidence from Word and Excel documents to their platform — part of our role alongside accelerating development was advising on good practice in add-in development, including recommendations on submission to Microsoft and compliance with AppSource guidelines. Getting those details right before first submission is considerably cheaper than discovering them through rejection notices.
What Enterprise IT Admins Scrutinise
Passing AppSource validation gets you onto the shelf. It does not get you deployed. Before an enterprise administrator assigns your add-in to ten thousand mailboxes, someone — an IT security team, an architecture board, sometimes a formal third-party-risk function — reviews it, and their questions are predictable enough that you can prepare every answer in advance.
Requested permissions. The manifest’s permission declarations and any Microsoft Graph scopes your add-in requests are the first thing reviewed, because the admin centre surfaces them at deployment time. Every scope you request must be defensible in one sentence. If your Outlook add-in requests read/write access to the entire mailbox when it only ever reads the current message, expect the review to stall while someone asks why. Least privilege is not just good engineering here; it is a sales asset.
Data flows. Where does document content go when a user clicks your button? Which endpoints does the add-in call, what is stored, for how long, in which region, and under which subprocessors? Enterprises increasingly expect a data-flow diagram as a standard artefact. If your answer involves content leaving the tenant, say so plainly and explain the controls — evasiveness is read as risk.
Identity integration. Administrators strongly prefer add-ins that sign in with the user’s existing Entra ID identity — single sign-on rather than a separate username and password — because it means conditional access policies, MFA, and offboarding all apply automatically. If a departing employee’s account is disabled, their access to your platform through the add-in should die with it. Modern add-ins should use Microsoft’s current nested app authentication approach for this; add-ins still popping legacy authentication dialogs read as dated and generate review questions.
Vendor posture. Finally, the review broadens from the add-in to you: certifications such as ISO 27001 or SOC 2, penetration test summaries, incident response commitments, and the inevitable security questionnaire. This is standard SaaS procurement, but the add-in adds a twist — you are asking to run code inside the customer’s Office applications, which some reviewers weight more heavily than a browser-based SaaS alone.
It is worth remembering the context these reviewers are working in. Many enterprise IT teams spent the last two years migrating away from legacy Office extensibility, and the lessons of the April 2026 VSTO migration deadline are fresh: unmanaged add-in estates became expensive liabilities. The same teams are working through the EWS to Microsoft Graph migration ahead of the October 2026 cut-off. The upside for you is that a modern web add-in with Graph-based integration is exactly what they want to standardise on; the downside is that governance is tighter than it has ever been, and they have institutional memory of vendors who made their lives difficult.
The Enterprise Rollout: Pilots, Stages and Propagation
Once approved, deployment itself follows a rhythm that experienced administrators will impose whether you suggest it or not — so suggest it, because vendors who arrive with a rollout plan look like vendors who have done this before.
The pattern is pilot, stage, then organisation-wide. A pilot group of a few dozen users — ideally including both enthusiasts and sceptics from the business function that wanted the add-in — runs it for a week or two while the administrator confirms nothing unexpected appears in support queues. Staged deployment then widens assignment group by group, typically by department or region, before the final assignment to everyone. Centralised deployment assigns by user, group, or tenant, so align your stages with groups the customer already maintains rather than asking them to build new ones.
Two operational details matter more than they appear. First, propagation is not instant: after an administrator assigns an add-in, it can take up to a day to appear in every user’s ribbon, and it appears silently. If nobody tells users the button is coming, the launch lands flat and the pilot feedback you wanted never arrives. Encourage the customer to pair each deployment stage with a short announcement — a screenshot of where the button appears and one sentence on what it does outperforms any manual. Second, plan the support path before stage one: your support team should know which tenant is at which stage, and the customer’s service desk should know what the add-in is, because “what is this new button?” tickets will land on them first.
For your own engagement model, this phase rewards responsiveness. When we built the Outlook Add-In for Workiro — a business collaboration and productivity platform — the add-in shipped alongside a Graph API server-side integration for syncing email conversations into their platform, and we worked closely with their team on user experience and on extending their microservices architecture to support it. The lesson that generalises: enterprise rollout surfaces integration and UX issues that no test tenant ever will, and the vendors who thrive are the ones whose engineering team is still engaged when the pilot group starts clicking.
How Updates Reach Users — and When They Don’t
Distribution does not end at deployment, and the update model is one of the web add-in platform’s genuine advantages — provided you understand its two-speed nature.
Your add-in’s code is hosted on your infrastructure and loaded at runtime, so ordinary changes — bug fixes, UI improvements, new behaviour behind existing entry points — deploy the moment you release them, to every user in every tenant, with no marketplace review and no administrator involvement. This is dramatically better than the old world of MSI packages and desktop deployment cycles, and it means your web release cadence is your add-in release cadence.
The manifest is the slow path. Anything declared there — new ribbon buttons, new permissions, new Office applications, changed entry points — requires a manifest update, which for an AppSource-listed add-in means another validation pass, and in centrally deployed tenants the updated manifest then propagates on the administrator’s schedule, not yours. The practical consequence is an architectural one: design your manifest to be as stable as possible, keep entry points generic, and put changeable behaviour in the hosted code where you control release timing. A new permission scope is the most expensive change of all, because it may re-trigger the customer’s security review — grounds for thinking hard about scopes before the first enterprise deployment, not after.
Monetisation, Briefly
A short word on commercial models, because the question always arises. The marketplace does support paid and transactable offers, but the overwhelming majority of successful ISV add-ins we encounter are free to install and function as companions to a paid platform subscription: the add-in authenticates the user against your platform, and your backend enforces entitlements exactly as it does for your web application. This keeps pricing conversations in your sales process where they belong, keeps the AppSource listing friction-free, and means an enterprise can deploy the add-in tenant-wide without a per-seat marketplace transaction. Unless you have a specific reason to transact through the marketplace, the free-companion model is the sensible default; whichever you choose, decide before submission, because it shapes the listing.
How McKenna Consultants Can Help
Distribution is a solvable problem, but it is full of one-way doors — permission scopes, manifest design, listing decisions — that are cheap to get right early and expensive to unwind after your first enterprise deployment. McKenna Consultants has been building Microsoft Office Add-Ins for many years, and our engagements routinely cover the whole journey: development, AppSource submission and validation, the security-review answers enterprise customers demand, and the rollout patterns that get an add-in from approval to ten thousand ribbons. We have done this for audit and compliance platforms like AuditBoard and collaboration platforms like Workiro, working as an extension of in-house teams rather than around them.
If you have an Office Add-In that needs to reach large customers — or an enterprise deal waiting on answers about permissions, deployment, or AppSource — we can help you give those answers with confidence. Get in touch and talk to us about where your add-in needs to go next.
