Currently all trusted app domains must be listed fully qualified in the manifest, e.g.
<AppDomain>https://customer1.acme-eu.com</AppDomain>
<AppDomain>https://customer2.acme-eu.com</AppDomain>
<AppDomain>https://customer3.acme-us.com</AppDomain>
<AppDomain>https://customer4.acme-us.com</AppDomain>
Our company has several root domains for their customer tenants. In the example above acme-eu.com and acme-us.com.
But as these customer tenant URLs (e.g. https://customer2.acme-eu.com) are sensitive data we can not put them in our delivered add-in manifest because all other customers would have the chance to see them.
Currently our customers need to use the O365CentralizedAddInDeployment PowerShell command to configure additional domains before using our add-in which is extremely error prone and sometimes just not working. Many hours of support needs to be invested to get the configuration fixed. For example after every change in the configuration all users needs to manually clear their add-in cache in Excel.
Having wildcards in the manifest would enormously help us and our customers:
<AppDomain>https://*.acme-eu.com</AppDomain>
<AppDomain>https://*.acme-us.com</AppDomain>
During add-in submission Microsoft can validate that the used domains are trustful.
6 Comments
I just ran into this same problem. We are a SaaS data warehouse app that isn't multi-tenant specifically to silo customer data, security, ...
We are also using a unique sub-domain for each customer. They love our product, except for when they want to pull some data to self analyze in Excel. Right now they have to create a report definition, run the report, export to CSV then open in Excel.
We, specifically me, created a proof of concept Excel add-in that take the customer's domain name as configuration of the add-in and were able to make our api calls to do do all that behind the scenes and just load data directly into Excel. Demo was a hit, but then in development I ran into this brick wall. I am unable to do OAuth authentication because Excel won't let me load the authentication page from the customer's unique site! Not in the taskpane, not in a dialog, nada. I added the internal QA site to the manifest and then it worked.
Because OAuth requires a page to open on the end user's machine to do the authentication and authorize the app (add-in) I can't think of any way around this hard restriction (limitation) for Office add-in manifest AppDomain.
And it is completely NOT feasible to list all customers' domains in the manifest as we are adding one or more new ones nearly every week.
I briefly looked into Office.auth but the customers' would need their IT involved to setup stuff in their AAD/Entra to get it to function, and to use of it sounded to be way more complex than OAuth which has plenty of helper libraries and full examples.Hi christian-sap, Could you please share more details about your workaround? I'm particularly interested in how you're currently delivering the add-in. I assume publishing it to AppSource isn't an option—am I correct?
Hi jayantsingh , our add-in is published to AppSource but our customers need to use the O365CentralizedAddInDeployment PowerShell module to configure their AppDomains (Set-OrganizationAddInOverrides command). This procedure is very error-prone and troubleshooting is almost impossible which leads to high frustration.
Thanks christian-sap . May i know what add-in is this and how are you documenting the installing/discovery?
Hello, any updates on this? Is this in development pipeline? There is some solution available for supporting wildcards in Office on Windows https://learn.microsoft.com/en-us/office/dev/add-ins/develop/trusted-domains. This shouldn't be a complex addition for Office on the web. Even the Windows solution require an admin intervention which adds extra friction.
