What is the problem or goal the end user is trying to solve or accomplish?
In Explore, when adding multiple filters, value pickers show huge, often irrelevant value lists because they don’t narrow based on previous selections. This makes ad-hoc analysis cumbersome (lots of scrolling, mis-selections) and inconsistent with the curated experience available in dashboard native filters.
How are they solving it currently?
Build curated dashboard filters and do the exploration there (loses some Explore agility).
Encode dependencies in SQL (ad-hoc WHERE/Jinja) which is not user-friendly and error-prone.
Create virtual datasets or views to pre-limit domains (increases data-modeling overhead).
What is the recommended solution by the Customer?
Add first-class dependent filter behavior in Explore’s filter controls:
Let users order filters in the Explore filter bar; each subsequent filter’s value list is computed as distinct values under the constraints of prior filters.
Provide a toggle like “Only show values with data (respect other filters)” for each control.
Support async fetching with pagination and search in value pickers to keep responses snappy on large cardinalities.
Surface an option to cap distincts (e.g., Top 5k values) with a “keep typing to refine” UX for very large domains.
Persist the filter order and dependency behavior in the chart’s form_data so exports/imports retain it.
Respect dataset permissions and row-level security; dependent queries must apply RLS.
Nice-to-have: a lightweight “hierarchy” helper (e.g., Country → State → City) to auto-wire common cascades.