Arcade data expressions broken in Dashboards - Data source error - 7 May 2026

CourtneyTregurthaNairn

Hi all,

This morning (7 May 2026, NZ time) all of our Arcade data expressions in ArcGIS Dashboards stopped working overnight. Everything was functioning correctly last night and nothing has changed on our end.

What we're seeing:

Some widgets powered by Arcade data expressions show "Data source error" while others using Arcade are working fine
Running broken expressions in the editor returns: "Test execution error: Execution error - Accessor must be a string. Verify test data."
The issue affects dashboards in our organisation, not just me
Widgets NOT using Arcade expressions are working fine
The feature layers themselves are accessible in Experience Builder and Map Viewer without issue
Accessing the REST endpoint directly returns a 403: "You do not have permissions to access this resource or perform this operation" — but only when accessed via Dashboards

Importantly, I tested ESRI's own public snowplow monitoring demo dashboard and it also shows a "Data source error" on the Status of Streets widget, which suggests this is a platform-wide issue rather than something specific to our organisation.

ArcGIS Online status page shows all services operating normally. Sharing permissions on our feature services have not changed. We have tried logging out and back in, hard refreshing, and testing in incognito windows none of these resolved the issue.

We have not been able to identify a specific code pattern causing the issue. The affected expressions use FeatureSetByPortalItem with Portal("https://www.arcgis.com") and were working correctly last night.

Has anyone else experienced this today? Is there a known issue or recent platform update that may have caused this?

Thanks

CourtneyTregurthaNairn

Update - Issue Identified and Workaround Found!

We found the cause, though we're unsure what triggered it as nothing changed on our end overnight.

Arcade expressions that build lookup dictionaries now throw "Accessor must be a string" if any record has a null key, previously this was silently skipped. The fix was adding a null check before dictionary assignments:

if (IsEmpty(pKey)) continue;

We also found expressions using intermediate arrays were returning null results. The fix was restructuring to push directly to the output array instead.

View solution in original post

CourtneyTregurthaNairn

Update - Issue Identified and Workaround Found!

We found the cause, though we're unsure what triggered it as nothing changed on our end overnight.

Arcade expressions that build lookup dictionaries now throw "Accessor must be a string" if any record has a null key, previously this was silently skipped. The fix was adding a null check before dictionary assignments:

if (IsEmpty(pKey)) continue;

We also found expressions using intermediate arrays were returning null results. The fix was restructuring to push directly to the output array instead.

ZenMasterZeke

Could you post a bit of code snippet surrounding the key check, just so the context is clearer (to me, anyway 😏)?