Deploy and publish Office Add-ins
You can use one of several methods to deploy your Office Add-in for testing or distribution to users. The deployment method can also affect which platforms surface your add-in.
|Sideloading||As part of your development process, to test your add-in running on Windows, iPad, Mac, or in a browser. (Not for production add-ins.)|
|Network share||As part of your development process, to test your add-in running on Windows after you have published the add-in to a server other than localhost. (Not for production add-ins or for testing on iPad, Mac, or the web.)|
|AppSource||To distribute your add-in publicly to users.|
|Microsoft 365 admin center||In a cloud deployment, to distribute your add-in to users in your organization by using the Microsoft 365 admin center. This is done through Integrated Apps or Centralized Deployment.|
|SharePoint catalog||In an on-premises environment, to distribute your add-in to users in your organization.|
|Exchange server||In an on-premises or online environment, to distribute Outlook add-ins to users.|
If you plan to publish your add-in to AppSource and make it available within the Office experience, make sure that you conform to the Commercial marketplace certification policies. For example, to pass validation, your add-in must work across all platforms that support the methods that you define (for more information, see section 1120.3 and the Office Add-in application and availability page).
Deployment options by Office application and add-in type
The deployment options that are available depend on the Office application that you're targeting and the type of add-in you create.
Deployment options for Word, Excel, and PowerPoint add-ins
|Extension point||Sideloading||Network share||AppSource||Microsoft 365 admin center||SharePoint catalog*|
* SharePoint catalogs do not support Office on Mac.
Deployment options for Outlook add-ins
|Extension point||Sideloading||AppSource||Exchange server|
Production deployment methods
The following sections provide additional information about the deployment methods that are most commonly used to distribute production Office Add-ins to users within an organization.
When you add features or fix bugs in your add-in, you'll need to deploy the updates. If your add-in is deployed by one or more admins to their organizations, some manifest changes will require the admin to consent to the updates. Users will be blocked from the add-in until consent is granted. The following manifest changes will require the admin to consent again.
- Changes to requested permissions. See Requesting permissions for API use in add-ins and Understanding Outlook add-in permissions.
- Additional or changed Scopes. (Not applicable if the add-in uses the unified manifest for Microsoft 365.)
- Additional or changed Outlook events.
Whenever you make a change to the manifest, you must raise the version number of the manifest.
For information about how end users acquire, insert, and run add-ins, see Start using your Office Add-in.
Integrated Apps via the Microsoft 365 admin center
The Microsoft 365 admin center makes it easy for an administrator to deploy Office Add-ins to users and groups in their organization. Add-ins deployed via the admin center are available to users in their Office applications right away, with no client configuration required. You can use Integrated Apps to deploy internal add-ins as well as add-ins provided by ISVs. Integrated Apps also shows admins add-ins and other apps bundled together by same ISV, giving them exposure to the entire experience across the Microsoft 365 platform.
When you link your Office Add-ins, Teams apps, SPFx apps, and other apps together, you create a single software as a service (SaaS) offering for your customers. For general information about this process, see How to plan a SaaS offer for the commercial marketplace. For specifics on how to create Integrated Apps, see Configure Microsoft 365 App integration.
For more information on the Integrated Apps deployment process, see Test and deploy Microsoft 365 Apps by partners in the Integrated apps portal.
Customers in sovereign or government clouds don't have access to Integrated Apps. They will use Centralized Deployment instead. Centralized Deployment is a similar deploy method, but doesn't expose connected add-ins and apps to the admin. For more information, see Determine if Centralized Deployment of add-ins works for your organization.
SharePoint app catalog deployment
A SharePoint app catalog is a special site collection that you can create to host Word, Excel, and PowerPoint add-ins. Because SharePoint catalogs don't support new add-in features implemented in the
VersionOverrides node of the manifest, including add-in commands, we recommend that you use Centralized Deployment via the admin center if possible. Add-in commands deployed via a SharePoint catalog open in a task pane by default.
If you are deploying add-ins in an on-premises environment, use a SharePoint catalog. For details, see Publish task pane and content add-ins to a SharePoint catalog.
SharePoint catalogs do not support Office on Mac. To deploy Office Add-ins to Mac clients, you must submit them to AppSource.
Outlook add-in deployment
For on-premises and online environments that do not use the Azure AD identity service, you can deploy Outlook add-ins via the Exchange server.
Outlook add-in deployment requires:
- Microsoft 365, Exchange Online, or Exchange Server 2013 or later
- Outlook 2013 or later
To assign add-ins to tenants, use the Exchange admin center to upload a manifest directly, either from a file or a URL, or add an add-in from AppSource. To assign add-ins to individual users, you must use Exchange PowerShell. For details, see Add-ins for Outlook in Exchange Server.
GoDaddy Microsoft 365 SKUs
Microsoft 365 subscriptions provided by GoDaddy have limited support for add-ins. The following options are not supported:
- Deployment through the Microsoft Admin Center.
- Deployment through Exchange servers.
- Acquiring add-ins from AppSource.