We have an Outlook web add-in deployed via centralized deployment that is presenting users with the following prompt:
"embedded page at FQDNofWebAppService says The domain EXO-OWA-FQDN is acting as Microsoft Office and can run Office add-ins, which may access your personal data. If you trust the domain to run as Office and access your data, click OK to continue."
If the user clicks OK, the add-in performs as expected; however, if the user clicks Cancel they see the following message in the taskpane:
"This add-in has been disabled to keep you safe. To continue using the add-in, validate that this item is hosted in a trusted domain or open it in the Office desktop app."
It appears that we only see this in OWA, not Outlook desktop as the last part of the message suggests.
I tried updating the AppDomains property of the manifest to include the OWA FQDN, but am still seeing this popup. I didn't include the FQDN of the app service instance it's being hosted out of because that's already specified in the sourcelocation property.
I'm expecting to be able to, as the tenant/global admin, to be able to trust the add-in (Similar to how global admins grant consent to apps to avoid users faced with consent prompts) such that users aren't presented with the prompt. Is this possible?
I did come across this office-js issue on Github, however, it's dated and referenced Exchange Server whereas this is Exchange Online: https://github.com/OfficeDev/office-js/issues/1441
I received an answer to this after also posting an issue on GitHub: https://github.com/OfficeDev/office-js/issues/3310
Bottom line, the prompt was appearing because we were self-hosting the OfficeJS file (As a workaround for an issue we found in the OfficeJS file) instead of accessing it from the Microsoft hosted location.