Dashboard is empty and shows "Meetings failed to load"

Symptoms

• The Decisions dashboard is empty and shows "Meetings failed to load. Please refresh."
• Refreshing does not help.
• It affects many or all users in the organisation at once, rather than one person.
• It happens in the Teams app, in a web browser, and in Outlook alike.
• It typically starts suddenly, without any change to Decisions.

For confirmation:
Use browser developer tools (F12 → Network) show calendar requests to Microsoft Graph failing with HTTP 403 and this response body: 

{
  "error": {
    "code": "ErrorAccessDenied",
    "message": "Access to OData is disabled: [ESAPRC_3]: Request was blocked due to a
                Tenant-Configured UserAgent AllowList being set for this Organization.
                The UserAgent in the request is ..."
  }
}

Cause

Your Exchange Online configuration may have EwsApplicationAccessPolicy set to EnforceAllowList. This policy permits mailbox access only to clients whose User-Agent header matches an entry in the EwsAllowList.

Despite the "Ews" naming, Microsoft applies this policy to Microsoft Graph and Outlook REST (OData) calls. Decisions reads each user's calendar from Microsoft Graph directly from the client.

Decisions runs inside Teams, the browser and Outlook rather than calling Microsoft 365 from its own servers. Web applications cannot set their own User-Agent header so Microsoft 365 sees the host client's agent. Any allow-list entry that permits Decisions necessarily permits other applications running in the same client.

Before you start

These settings can only be changed in Exchange Online PowerShell. There is no Exchange admin center page for the allow list. (The EAC does expose a per-mailbox Exchange Web Services on/off toggle under Recipients → Mailboxes → Manage email apps settings, but that is a different setting and will not resolve this.)

You will need the ExchangeOnlineManagement module and an account with Exchange administrator rights:

Install-Module ExchangeOnlineManagement -Scope CurrentUser
Connect-ExchangeOnline

Step 1 — Confirm the cause 

Get-OrganizationConfig | fl EwsEnabled, EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList

If EwsApplicationAccessPolicy reads EnforceAllowList, this article applies. If all the values are blank, no policy is configured and the cause lies elsewhere — please contact Decisions support.

A per-mailbox setting overrides the organisation setting, so also check an affected user:

Get-CASMailbox user@yourdomain.com | fl EwsEnabled, EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList 

Record the current values before changing anything. They are what you restore to if you want to undo the change.

Step 2 — Choose an approach

Four options, from broadest to narrowest. Each is described in full below.

Option A — Allow all browsers and Teams clients (including Safari)

Every browser and every Microsoft Teams client sends a User-Agent beginning with Mozilla/5.0. A single entry therefore covers all of them — Chrome, Edge, Firefox, Safari, the Teams desktop and mobile apps, and Outlook:

Set-OrganizationConfig -EwsAllowList @{Add="Mozilla/*"}

Existing entries are kept. This is the only approach that covers Safari: Safari's User-Agent contains no marker unique to it, and the nearest alternative (*Safari/*) also appears inside Chrome's own User-Agent, so it is no narrower in practice.

Understand what this permits: Mozilla/* matches essentially any client presenting a browser-style User-Agent, which is trivial for any HTTP client to do. It is close to allowing everything. If that is acceptable, Option C expresses the same policy more clearly and gives you a way to exclude specific applications.

Option B — Allow named client families

If you would rather keep the allow list meaningful, add the Teams clients and the major browser families:

Set-OrganizationConfig -EwsAllowList @{Add="*Teams/*","*TeamsMobile-*","*Chrome/*","*Edg/*","*EdgiOS/*","*CriOS/*","*Firefox/*"}

This option does not cover Safari — use Option A or C if you have Safari users.

It also needs occasional maintenance. New clients and platforms introduce new markers, so a future client rollout can reintroduce the outage. If that is a concern, prefer Option A or C.

Option C — Use a block list instead

A block list inverts the policy: every client is allowed except those you name. If your intent is "allow everything except specific applications," this expresses it directly and needs no maintenance as clients change.

Set-OrganizationConfig -EwsApplicationAccessPolicy EnforceBlockList -EwsBlockList "UnwantedApp/*","AnotherApp/*"

To add or remove individual entries later without replacing the whole list:

Set-OrganizationConfig -EwsBlockList @{Add="SomeApp/*"; Remove="OtherApp/*"}

Notes:

• A policy can use an allow list or a block list, not both. Switching to EnforceBlockList replaces your current configuration — the allow list stops being enforced.
• Anything you have not explicitly blocked is permitted. Before switching, review what the allow list was originally introduced to keep out, and name those applications in the block list.
• Decisions, Teams, Outlook and all browsers will work, and keep working through client updates.

Option D — Turn the policy off

If the restriction is no longer needed at all, clear it:

Set-OrganizationConfig -EwsApplicationAccessPolicy $null -EwsAllowList $null

Then confirm the values are blank. If the policy value does not clear, Microsoft's documented "allow all client applications" state achieves the same result:

Set-OrganizationConfig -EwsApplicationAccessPolicy:EnforceBlockList

With no block list specified, all client applications are permitted.

Do not set EwsEnabled to $false. That disables mailbox access entirely rather than removing the restriction, and will not resolve this issue.

Applying the change to specific mailboxes only

A per-mailbox setting takes precedence over the organisation policy. If you prefer to keep organisation-wide enforcement and exempt only the people who use Decisions, apply the same allow list per mailbox:

Set-CASMailbox -Identity user@yourdomain.com -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList "Mozilla/*"

This does not apply automatically to new users. Set-CASMailbox targets individual mailboxes and does not accept a group, so each newly licensed user will be blocked until the command is run for them. At scale, drive it from group membership on a schedule:

Get-ADGroupMember "Decisions-Users" | ForEach-Object {   Set-CASMailbox -Identity $_.UserPrincipalName `     -EwsApplicationAccessPolicy EnforceAllowList -EwsAllowList "Mozilla/*" } 

 Step 3 — Verify

Get-OrganizationConfig | fl EwsApplicationAccessPolicy, EwsAllowList, EwsBlockList

Allow up to an hour for the change to propagate. It is not immediate. Users should then reload the Decisions tab, or restart Teams.

Important note on the Exchange Web Services retirement

Microsoft begins retiring Exchange Web Services on 1 October 2026, with full retirement from 1 April 2027. That programme uses a different, newer setting — EwsEnabled together with EwsAllowedAppIDs, which takes Microsoft Entra application IDs rather than user-agent strings.

That programme does not affect Decisions. EWS is a SOAP-based API; Decisions does not use it. Microsoft's own prescribed remediation for the retirement is to migrate applications to the Microsoft Graph API — which is what Decisions already uses. Setting EwsEnabled to $false, or Microsoft doing so automatically on 1 October 2026, does not block Decisions.

The two settings are nonetheless easy to confuse, because both are described as "the EWS allow list" and both live on Get-OrganizationConfig:

If you are reviewing your Exchange configuration ahead of the retirement deadline, check the user-agent policy described in this article at the same time — work on one is a common way for the other to be altered inadvertently. 

Note: EwsAllowedAppIDs is not returned by a plain Get-OrganizationConfig. To read it you need the switch below — without it the field appears empty whether or not it is configured.

Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | fl EwsAllowedAppIDs 

 Microsoft references

• Control access to EWS in Exchange
• Set-OrganizationConfig
• Set-CASMailbox