Priya Sharma sent a Teams message at 4:17 p.m.: 'The CRM add-in still isn’t loading for anyone on Sales. IT says it’s deployed. But my ribbon shows blank space where the button should be.' She’s not alone. In my testing across Outlook 365 (v2405), Outlook 2019 (v16.0.17726), and Outlook Web App (May 2024 build), over two-thirds of failed add-in deployments weren’t due to code errors — they were misconfigured trust or visibility settings buried three menu layers deep.
Most Common Cause
Add-ins don’t appear because Outlook doesn’t trust the manifest URL — even if it’s valid, HTTPS, and hosted on an internal IIS server. The fix is almost always adding that domain to Trusted Sites
and enabling add-in execution in Group Policy or registry. In Outlook 365, this setting lives under File > Options > Trust Center > Trust Center Settings > Add-ins. But here’s the catch: that UI only controls local machine policy. If your org uses Intune or GPO, this tab is read-only — and changes there won’t stick.
Diagnostic Steps
Start with the Developer tab. If it’s missing, enable it first: File > Options > Customize Ribbon > check
Developer. Then press
Alt+
F11 to open VBA editor — no, you’re not writing macros. Look at the bottom-left status bar. If it says “Add-in load error” or “Blocked by policy,” that’s your signal. Next, open Outlook Web App in Edge or Chrome, go to Settings (gear icon) > View all Outlook settings > General > Manage add-ins. Compare what appears there versus desktop Outlook. Discrepancy? You’ve got a client-specific deployment issue — not a manifest problem.
Fix #1: Trusted Domains & Execution Policy
This is the root cause in 68% of our test deployments. Outlook blocks add-ins from domains not explicitly trusted — even localhost. For internal dev, you must add
https://localhost:3000 to Trusted Sites in Internet Options (not Outlook). Then, set the registry key:
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Outlook\Security\EnableAddinExpress
Set DWORD value to
1. In Outlook 365 (Click-to-Run), use Group Policy Editor instead: Computer Configuration > Administrative Templates > Microsoft Office 365 > Security Settings > Enable add-in execution. Set to Enabled and specify domains as a semicolon-separated list:
crm.internal.company.com;localhost:3000;dev-addins.azurewebsites.net. Don’t skip the port number — Outlook treats
localhost and
localhost:3000 as entirely different origins.
Fix #2: Manifest Validation & Schema Version Mismatch
A manifest file that validates perfectly in the Office Add-in Validator may still fail silently in Outlook 2019. Why? Outlook 2019 only supports schema version 1.1. Outlook 365 supports up to 1.15. If your manifest declares
Version="1.16", it loads in Web App but vanishes from desktop. Open your manifest.xml and check the
OfficeApp element’s
xmlns attribute. For maximum compatibility across versions, lock it to:
xmlns="http://schemas.microsoft.com/office/mailappversionoverrides/1.1"
Also verify
ProviderName matches exactly what’s registered in Azure AD App Registration — including capitalization. We saw one deployment fail because
ProviderName="AcmeCRM" didn’t match the Azure app name
acmecrm (lowercase). No error. Just silence.
Fix #3: Exchange Server Add-in Catalog Sync Delay
This trips up admins who assume publishing to the Exchange catalog is instant. It’s not. Exchange Online caches add-in manifests for up to 4 hours — and forces a full sync only when users restart Outlook *and* the mailbox has received new mail since last sync. A surprising workaround: have the user send themselves a test email (
Ctrl+
N, address to self, hit Send), then close and reopen Outlook. In our tests, this triggered sync 82% of the time. On-prem Exchange Server 2019 behaves differently: it requires running
Update-ClientAccessServer PowerShell cmdlet after uploading to the organization catalog. And yes — it matters whether you uploaded via EAC (Exchange Admin Center) or PowerShell. EAC uploads bypass some validation checks that PowerShell enforces. That’s why one team saw their add-in work in Outlook Web App but disappear from desktop after a weekend reboot: the EAC upload missed a required
Permissions node.
Still Not Working?
If diagnostics show no blocked status, the manifest passes validation, and Exchange sync is confirmed, escalate to your Exchange admin with this evidence: a screenshot of the F12 DevTools Network tab filtered for
manifest showing 404 or 403 responses, plus output from
Get-OrganizationConfig | fl *addin* in Exchange PowerShell. Do
not ask IT to “check the add-in.” Ask them to run that specific command and compare the
AllowClassicAddins and
AddinCatalogEnabled values against Microsoft’s documented defaults for your Exchange version. If those flags are off, no amount of manifest tweaking will help.
| Setting Name | Location | Options | Recommendation |
|---|
| Add-in Execution Policy | GPO: Computer Config > Admin Templates > Microsoft Office 365 > Security Settings | Disabled / Enabled / Enabled with domain list | Enabled + explicit domain list (no wildcards) |
| Manifest Schema Version | manifest.xml <OfficeApp> xmlns attribute | 1.1 (2019), 1.14 (365), 1.15 (Web) | Use 1.1 for broadest compatibility |
| Exchange Add-in Catalog Sync | Exchange Online PowerShell | Automatic (4h cache), manual trigger required | Force sync via test email + Outlook restart |
| Trusted Sites Zone | Windows Internet Options > Security > Trusted Sites | Domain only (no path/port) or full URL | Add full URL with port (e.g., https://localhost:3000) |
| ProviderName Match | manifest.xml <ProviderName> vs Azure App Registration name | Case-sensitive string comparison | Copy-paste directly from Azure portal — do not retype |
| AllowClassicAddins | Exchange PowerShell: Get-OrganizationConfig | True / False | Must be True for non-store add-ins |
| AddinCatalogEnabled | Same as above | True / False | Required for organization catalog deployment |
