Advanced Filter/Sort – "Data source is not active" Error After Publishing a View on a Custom Form

Finance and Operations/AX
1

Hello everyone,

We are experiencing a reproducible issue in Dynamics 365 Finance when working with published views on a custom form.

Environment

  • D365 Finance Version: 10.0.47 (10.0.2527.109)
  • Platform Update: PU71 (7.0.7858.96)
  • The issue occurs on a custom form, not on a standard Microsoft form.

Scenario

A user can initially open the “Advanced Filter/Sort” dialog (formerly Ctrl+F3) without any issues. Existing views are displayed correctly and can be edited and published.

Issue

After modifying and publishing an existing view, the affected user can no longer open the Advanced Filter/Sort dialog.

Instead, the following error message is displayed:

“Data source is not active”

From that point on, the standard Advanced Filter/Sort functionality is no longer available for that user on the affected form.

What We Have Observed

  • The issue can be temporarily resolved by deleting the Usage Data for the affected form.
  • To be clear, this is not related to Personalizations; only the form-specific Usage Data is deleted.
  • After clearing the Usage Data, the Advanced Filter/Sort dialog works again.
  • All views become available and usable.
  • As soon as an existing view is modified and published again, the error reappears.
  • The user who publishes the view does not experience the issue.
  • The behavior is fully reproducible.

Our Assumption

Since the issue only appears after publishing a view and can be resolved by clearing the form’s Usage Data, we suspect a relationship between published views, stored Usage Data, and the initialization or activation state of the form datasources.

Questions

  • Has anyone experienced a similar issue with published views on custom forms?
  • Are there any known limitations or special considerations when using Advanced Filter/Sort together with published views on custom forms?
  • Are there any known Microsoft issues or hotfixes related to this behavior?
  • Are there specific requirements regarding datasource initialization, activation, naming, or query structure that published views depend on?

Any suggestions or experiences would be greatly appreciated.

Thank you.

2

Hi @Cem_Aras

This sounds like it could be a mismatch between cached Usage Data (SysLastValue) and the datasource/query state after a view is republished, since clearing Usage Data temporarily fixes it, that’s a strong signal.

A couple of things worth checking:

  • Security/permissions gap: Does the affected user have the same table/field-level access as the person publishing the view? If the republished view touches a datasource or field the user doesn’t have access to, it can get disabled during form init for them specifically.
  • Custom form specifics: Since standard forms aren’t affected, worth checking if this form extends a standard form vs. is fully custom, and whether any datasource has custom init/activate logic that could be interacting oddly with the republished query.

Given it’s fully reproducible and only affects non-publisher users, I’d log this via LCS with the repro steps; it feels like either a caching bug tied to custom forms + published views, or a permissions gap that only surfaces after republish. Curious if it happens for all non-publisher users or just some; that would help narrow it down.