Filtering applying inconsistently based on visualization type on Platform Analytics dashboardIssue The analytics list visualization and the server-backed visualizations (score, dial, charts) receive identical filter input but resolve it in different places, and only one of them validates.Both get filterConfigurations bound to @state.parFilters.Server-backed path: visualization-base ships the configuration to /multivisdata (transform-props-to-data-request.js:449, after only timezone adjustment in parse-filter-configurations.js:35). ReportingFilterConfigurationParser checks each mapping against the data source table and discards those that do not resolve.List path: the query is assembled in the browser. The sn_analytics_list client script "Update encoded query" takes encodedQueries[table] from global.mergePARFilters().v2, string-concatenates it onto the data source query, then posts to /exec. There is no check that the conditions resolve against table.When a condition references a field that does not exist on the list's table, GlideRecord compiles it to 0 = 1. The list then returns zero rows for reasons invisible to the user, while an equivalently configured score or chart on the same table returns data.Reference: visualization-addons/sn-par-analytics-list/src/plugin-xmls/update/sys_ux_client_script_dbc2c96a9f5b121006dd0127aa0a1cfb.xml:65 for the lookup, and lines 79-88 for the concatenation. Requires a Zurich & further instance where hierarchy expansion still pulls cross-table filter mappings onto a child class. Enhancements removed the trigger in Australia and the master.1. On a Zurich & further instance, create a Platform Analytics dashboard.2. Add a filter with source table sys_user. Under Data to filter, add an entry for Incident → Caller and enable Apply to hierarchy. caller_id exists on the incident but not on the problem.3. Add a Single Score visualization on the problem, and a List visualization on the problem. Both are set to follow filters.4. Select any user in the filter.Expected: both visualizations apply the same effective filter and return consistent results.Actual: the score returns a count; the list returns no records. Enabling Session Debug → Debug SQL shows AND 0 = 1 in the list query and not in the score query.Independent of the repro, the failure mode is observed on a Zurich customer's instance but not on the OOTB Zurich instance. The score query carries four resolved conditions and returns 1. The list query includes the same four, plus AND 0 = 1 AND 0 = 1 AND 0 = 1, and returns nothing. The reporter confirmed that manually removing those three terms makes the same query return the record. Release Related to the known issue at ServiceNow end. Resolution it is a defect on Zurich versions and reproducible in Australia as well, planned to be fixed in Australia onwards releases as part of a bigger enhancement feature to support filters on hierarchy.Root causeIf the filter has "Data to filter" entries. In Zurich, entries defined for other tables were being applied to the table through hierarchy expansion. Let's say that some of the resulting conditions resolved against that table, and part of the referenced fields do not exist on it.While creating a filter condition to append, GlideRecord compiles an unresolvable condition to 0 = 1, so the list query could never return rows. We can see this from the debug statements we had collected during our analysis.Why do the list and the dial behave differently?Both visualizations receive the same input. filterConfigurations is bound to @state.parFilters for both. The difference is where the filter is resolved:Dial/score sends the filter configuration to the server via /multivisdata. The server-side parser checks each mapping against the data source table and drops the ones that do not resolve.The list builds its query in the browser (mergePARFilters().v2 → encodedQueries[table] → string concatenation) and posts it to /exec. There is no equivalent validation on that path, so the unresolvable conditions reached the database.What changed in Australia?We have a few enhancements in Australia that work with hierarchical filters.