I'm restricting Exchange Web Services in my tenant by using an allow list. With EWS enabled but EwsApplicationAccessPolicy set to EnforceAllowList, Power Automate flows that use the Office 365 Outlook connector's "Send an email (V2)" action fail. Microsoft documentation says the connector was migrated to Microsoft Graph, although some operations may still use EWS, so I'm trying to determine which setting controls access.
My organization configuration includes EwsEnabled set to True, an EwsAllowedAppIDs list, and an EwsAllowList containing patterns such as Azure.Connectors.Office365Outlook.Office365OutlookConnector*, Azure.Connectors.Outlook.OutlookConnector*, PowerApps/*, LogicAppsDesigner/*, microsoft-flow/*, azure-logic-apps/*, okhttp/*, and Microsoft%20Teams/*. There is no obvious Power Apps or Power Automate application ID in the admin reports or available EWS discovery tools.
Am I mixing up EwsAllowList and EwsAllowedAppIDs? Do I need to identify the actual Entra application ID used by Power Automate and add it to EwsAllowedAppIDs, or should the connector's user-agent entry be sufficient?
3 Answers
First check whether EWS is actually disabled globally or merely restricted. If EwsEnabled is False, the allow list will not override that and EwsAllowedAppIDs will have no effect. If EwsEnabled is True and EwsApplicationAccessPolicy is EnforceAllowList, then the application must satisfy the relevant allow-list check.
Those are separate controls. EwsAllowList and EwsBlockList belong to the application access policy and match the caller’s client or user-agent string. EwsAllowedAppIDs is a different allow list that matches the Entra application ID, so the connector patterns do not automatically satisfy that requirement.
If the flow is being blocked by the application-ID policy, identify the real application ID from Entra sign-in or service-principal sign-in logs. Filter for activity involving Exchange Online rather than relying on a GUID copied from an unofficial source. After changing the organization configuration, allow some time for the setting to propagate before testing again.
The Exchange Online usage reports and sign-in logs can help reveal which application is making the request. Also keep in mind that Microsoft is continuing its EWS retirement, so even a working allow-list configuration may only be a temporary compatibility measure; moving the flow to a supported Graph-based action is the safer long-term approach.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures