The add-in that worked, and still did not ship
A team finishes a polished add-in, demos it to everyone, then submits it to AppSource and waits. A week later it bounces over a privacy policy that does not name the app. They fix it, resubmit, and it bounces again over a localhost reference in the manifest. Three weeks in, the add-in still is not live. Publishing an Office add-in to AppSource is not hard, but it is unforgiving of small mistakes, and most of the pain is avoidable if you know what the reviewers check before you submit. This guide walks through the submission process, the realistic timeline, the rejection reasons that catch almost everyone the first time, and the decision most teams should make first: whether you even need the store.
Key Takeaways
You may not need AppSource at all
For an internal add-in, centralized deployment through the Microsoft 365 admin center skips the store and the review entirely.
Submission goes through Partner Center
You create a Partner Center account, upload your manifest, complete the listing, and submit for certification.
Plan for up to four weeks on a first submission
A clean review takes three to five business days, but first submissions usually need revisions, which stretches the timeline.
HTTPS and no localhost are absolute
Every endpoint must use HTTPS with valid TLS. Localhost references are rejected because reviewers cannot reach your machine.
Three live URLs are mandatory
Valid support, privacy, and license URLs that do not 404, with the privacy policy naming the add-in specifically.
SSO and custom functions need test notes
If your add-in uses single sign-on or custom functions, you must give reviewers a fallback flow and test instructions.
Do you even need to publish to AppSource?
Not always. If your add-in is only for your own organisation, centralized deployment through the Microsoft 365 admin center pushes it to chosen users or groups with no Microsoft review and instant updates. AppSource is for public distribution, reaching customers outside your tenant, and earning the trust signal of a Microsoft-validated listing.
This is the first decision, and skipping it wastes weeks. There are two ways to get an add-in to users. Centralized deployment, done by an administrator in the Microsoft 365 admin center, installs the add-in for the people you choose inside your own tenant. There is no certification, no public listing, and updates to your hosted files are live immediately. For an internal business tool, this is almost always the right path.
AppSource, the public marketplace, is the route when you want to sell the add-in, reach users outside your organisation, or present the credibility of a Microsoft-reviewed listing. It comes with the certification process this guide is about. If neither of those applies to you, you can stop here and deploy internally.
Many products do both: internal deployment for early customers and pilots, then AppSource once the add-in is proven and you want public reach. There is no rule forcing you to start with the store.
What do you need before you submit?
Getting these ready before you open the submission form is what keeps a first attempt from bouncing.
A Partner Center account. You register and get approved before you can submit, so do this early rather than at the finish line.
A validated manifest. The manifest must pass schema validation, and for the XML add-in-only manifest that means schema version 1.1. Every URL in it must be HTTPS and point to a live hosted location, never localhost.
Hosted, production web files. Your add-in's HTML, JavaScript, and assets must be on a real server or hosting service with valid TLS, because reviewers test the live add-in, not your machine.
Three policy URLs. A support URL, a privacy policy URL, and an end user license agreement URL, all starting with https and all returning a real page, not a 404. The privacy policy must describe how you handle user data and must reference the add-in by name, not just your website.
Test notes and a demo account. Reviewers need to exercise every feature. Provide a test or demo account, sample data, and clear instructions, and avoid any account that requires your team to take an action before they can sign in, since the validation team works across time zones.
Listing assets. Your app name (matching the manifest), description, screenshots, icon at the correct size, and category. These are what customers see in the store.
What does the submission and validation process look like?
You upload your manifest and complete the listing in Partner Center, then submit. The package goes through automated certification checks, after which a human validation team tests the add-in on every platform whose APIs it declares. A clean Office add-in review runs three to five business days; a first submission with revisions can take up to four weeks.
After your account is approved, you build the submission in Partner Center: upload the manifest, complete the store listing, set your support, privacy, and EULA links, choose categories, and add your test notes. When the manifest uploads correctly you get a confirmation that the manifest checks passed.
On submission, the package first runs through automated checks against the certification policies, then goes to the validation team. They review and test the add-in on all the platforms that support the methods you declared, which is why an add-in that claims Mac support but does not actually work there will fail. A clean Office add-in review takes three to five business days depending on queue volume, though Teams and SharePoint Framework submissions are faster.
The honest expectation for a first submission is up to four weeks, because revisions are normal and each round trip adds time. Build that into your launch plan rather than promising a date that assumes a flawless first pass. If you change anything you submitted, such as the manifest, screenshots, or icon, after certification, it goes through validation again. Changes to your hosted web service alone do not require resubmission.
Why do Office add-ins get rejected, and how do you avoid it?
The most common rejection reasons are localhost or non-HTTPS URLs, missing or invalid support, privacy, and license links, a privacy policy that does not name the add-in, manifest schema errors, single sign-on without a documented fallback, and custom functions without test instructions. Almost all of these are fixable before you ever submit.
The validation team sees the same mistakes constantly, and they are nearly all preventable. Localhost references fail every time, because the reviewer cannot reach your development machine. Any non-HTTPS endpoint fails, since HTTPS with TLS 1.2 or higher is required for all add-in resources without exception.
The policy URLs are the other big bucket. One of the top reasons submissions fail is missing or broken support, privacy, and EULA links. The privacy policy in particular must do more than exist: it has to describe how user data is handled and reference the add-in itself, not just point at your company website, or it fails and you resubmit.
Two feature-specific traps catch teams. If your add-in uses single sign-on, you must include step-by-step instructions for the SSO flow plus a fallback for when SSO is unavailable. If it includes custom functions, you must provide test instructions for at least one function so the reviewer can validate it. And a small one that bites: do not reuse an existing add-in's ID for a new add-in, but do keep the same ID when you update an existing one. Our Office add-in manifest guide covers the manifest-side details that trip up validation.
If you have built an add-in and you are staring at a validation rejection you cannot decode, or you would rather not learn these rules the hard way on a deadline, that is exactly the kind of thing we get over the line quickly, because we have shipped add-ins through this process. See how we work on our page.Office Add-in development services
What happens after your add-in is approved?
Once your add-in is live in AppSource, there are a couple of things worth doing. Create an installation link, which gives customers a click-and-run experience: selecting the link opens the Office application with your add-in installed, no searching the store required. Put it on your website, in emails, and anywhere customers discover you, since it removes friction from adoption.
You can also enter the Microsoft 365 App Compliance program through Partner Center. It is optional, but completing the Publisher Attestation signals a level of security and data-handling diligence that enterprise buyers increasingly look for, and it can be the difference in a procurement review.
For ongoing updates, remember the split: changes to your hosted web files go live without resubmission, but changes to anything you submitted through Partner Center, the manifest, the listing, screenshots, or icon, trigger a new validation pass. Plan releases accordingly so a small listing tweak does not unexpectedly pull your add-in into re-review.
How does internal deployment work if you skip the store?
If AppSource is not for you, centralized deployment is straightforward. An administrator goes to the Microsoft 365 admin center, adds your add-in by uploading the manifest or pointing to its location, and assigns it to specific users, groups, or the whole organisation. The add-in appears for those users automatically, with no store search and no Microsoft review.
The big advantages are speed and control. Updates to your hosted web files are live immediately, you are not subject to certification timelines, and the add-in stays private to your tenant. For internal business tools, line-of-business integrations, and anything you do not intend to sell, this is the path that gets value to users fastest.
The same technical requirements still apply, your files must be on HTTPS with valid TLS and your manifest must be valid, but the validation gauntlet does not. Many of the add-ins we build for clients never touch AppSource for exactly this reason.
AppSource vs centralized deployment
| Factor | AppSource (public) | Centralized deployment (internal) |
|---|---|---|
| Microsoft review | Yes (3-5 days clean) | None |
| Reaches users outside your tenant | Yes | No |
| Time to first deployment | Days to weeks | Immediate |
| Updates to hosted files | Live without resubmission | Live immediately |
| Trust / discoverability signal | High (store listing) | N/A (private) |
| Best for | Products you sell or distribute | Internal business tools |
Frequently asked questions
How long does AppSource approval take?
A clean Office add-in review takes three to five business days. First submissions usually need revisions, so plan for up to four weeks end to end. Teams and SharePoint Framework submissions are validated faster, often within a day.
Do I have to publish to AppSource to use my add-in?
No. For internal add-ins, an administrator can deploy directly through the Microsoft 365 admin center with no review and instant updates. AppSource is only needed for public distribution, reaching users outside your tenant, or the credibility of a Microsoft-validated listing.
Why did my Office add-in fail validation?
Common causes are localhost or non-HTTPS URLs, missing or broken support, privacy, or license links, a privacy policy that does not name the add-in, manifest schema errors, single sign-on without a fallback flow, and custom functions without test instructions.
Do I need to resubmit when I update my add-in?
Only when you change something submitted through Partner Center, such as the manifest, listing, screenshots, or icon. Changes to your hosted web service alone go live without resubmission. Keep the same add-in ID when updating an existing add-in.
What URLs do I need to publish an add-in?
Valid HTTPS URLs for a support page, a privacy policy, and an end user license agreement, none of which may return a 404. The privacy policy must describe how user data is handled and reference the add-in specifically, not just your website.
Can I sell my Office add-in on AppSource?
Yes. AppSource supports paid offers and in-app purchases. If you use in-app purchases, you provide license keys or test credentials in the certification notes so reviewers can validate the purchase flow during review.
Prepare for the reviewer, not just the user
Publishing an Office add-in to AppSource is mostly an exercise in anticipating what the validation team checks: HTTPS everywhere, no localhost, three valid policy URLs, a privacy policy that names the add-in, and clear test notes for anything involving sign-on or custom functions. Get those right before you submit and a clean review is days, not weeks. And if your add-in is internal, the smartest move is often to skip the store entirely and deploy through the admin center. If you want the submission handled, or you are stuck in a rejection loop, tell us about your add-in and where you want it to reach. Reach out through our contact page whenever you are ready.