When Addins stop showing themselves

4 November 2026

So I have two users where some addins do not appear. One user has had the issue for a while and its followed to new devices.

Working on a issue where two office addins that are deployed to All Users via the M365 Integrated addins deployment from the M365 Admin Center just do not appear for them.

Checking the deployments we have it set to a group for one addin and All Users for the other. Users are in the correct group so thats not an issue. Both are on an up to date build of M365 Apps on the current channel.

Checking the web versions of both and the addins are not loading there either. Ok so not a deployment issue then! (urm.. of course not they are working for others!!)

Time to capture HAR files from a working device and a non working device. Pushing them through your AI of choice (makes analysing easier) we can see on the non-working device that its asking the mailbox for what addins are available for the user, and its returning an HTTP 500 error. Not good.

Loading up the Exchange Online tools to interrogate the mailbox in question it looks like it may be corrupt. Again not good.

So off to Microsoft Support we go. Will let you know how I get on, and when I am back from holiday I’ll add the Exchange Online commands.

So, how does this all work and hang together?

When you deploy from Settings > Integrated apps in the M365 admin center, you pick an app from the Microsoft marketplace or upload a manifest, then choose who gets it (everyone, specific users or groups, or just you) and consent to any permissions. At that point the admin center stores the manifest and the assignment in the tenant’s Centralized Deployment service. Nothing is installed on the client by you; the assignment is just metadata held by Microsoft.

For Outlook add-ins, the manifest is also provisioned into Exchange Online as an organization app, which is why Get-OrganizationApp shows it. Exchange then works out per mailbox which org apps apply, by expanding the user or group assignment. When Outlook (desktop, web, or mobile) starts, it asks Exchange for the app manifests for that mailbox, and that is where a mailbox-level problem would surface as a 500. For Word, Excel and PowerPoint, the clients instead query the Office config service at startup to get the apps assigned to the signed-in identity.

Once the client has a manifest, Microsoft’s involvement is mostly over. The client reads the source URL from the manifest and loads the add-in’s web content directly from the vendor’s hosting (for example Claude and Eptura) inside a sandboxed webview.

Any SSO token requests go to Entra ID, and the add-in’s own logic and API calls run on the vendor’s infrastructure, not in your tenant. So Microsoft processes the manifest, assignment and group resolution, Exchange processes mailbox applicability, and the vendor processes everything the add-in actually does.