Apache Superset native filters and cross-filtering: what teams must decide first
Native filters are the dashboard controls that let a viewer narrow every chart on a dashboard, or a chosen subset of them, to a value such as a region, a product line or a date range. Cross-filters go a step further: clicking a value in one chart applies it as a filter to other charts. A team rolling out shared dashboards to non-analysts needs these when people will ask the same questions of the same data repeatedly and should not have to edit charts to answer them. If most viewers only need a fixed view, a dashboard with separate charts may be enough. Before building anything, decide which dimensions viewers should control, which charts each filter should affect, and whether anyone will rely on clicks inside a chart to drive the rest of the page.
Superset 4.0.0 removed the legacy Filter Box and automatically migrated existing filter boxes to native filters, and it also removed the Filter Sets feature. Teams carrying dashboards from older versions should check which filters were converted and whether any saved filter configurations depended on Filter Sets, because that feature no longer exists. The horizontal filter bar became generally available in 6.0.0, which removed its HORIZONTAL_FILTER_BAR feature flag. Earlier, the DASHBOARD_CROSS_FILTERS flag was removed in 5.0.0. Confirm the exact behavior of cross-filters and filter bar settings against the release you will run, using the UPDATING notes, since those notes record which flags and features changed.
Filter types and scoping options and when each fits
This table pairs each native filter type and scoping option with the user task it supports and the trade-off to weigh before rollout. Read it as a starting point for the design review, then confirm the exact filter types and scoping behavior in the Superset documentation for the version you plan to run. The main takeaway is that filter type should follow the question users ask, and scope should follow where the filter's values make sense.
| Option | User task it supports | Trade-off to weigh | When to choose it |
|---|---|---|---|
| Value filter | Pick one or more categories such as region, product line or status | Option lists load from the dataset, so high-cardinality columns can slow the filter and produce long lists | Users need to narrow by known categories; keep lists short or search-enabled |
| Numerical range filter | Limit results to a band such as order value or age group | Bounds that do not match the data distribution confuse users; define the range from the column's real values | Users compare measures across bands rather than exact values |
| Time range filter | Set a reporting window such as last quarter or a custom date span | Relative and absolute options behave differently across time zones and data refresh times; confirm the behavior with your data | Most operational and finance dashboards need a single, obvious period control |
| Time grain filter | Switch between day, week, month or similar aggregation levels | Only useful when the charts share a temporal column; a grain that does not fit the data can produce sparse or misleading lines | Users want the same chart at different levels of detail without building separate charts |
| Scoped to selected charts | Apply a filter to only the charts where its values apply | Charts left out of scope still show unfiltered totals, which can confuse readers comparing panels | The filter column exists in some datasets but not others on the same dashboard |
| Scoped to tabs | Limit a filter to the charts on one tab of a multi-tab dashboard | Users may not see a filter's effect on other tabs and assume it applies everywhere | Tabs represent distinct business questions with different dimensions |
| Horizontal filter bar | Keep filters visible at the top of the dashboard while users scroll | Consumes screen space on smaller displays; confirm current layout and behavior for your version | Dashboards with a small set of primary filters used on most charts |
| Cross-filtering from chart clicks | Click a bar or slice to filter the rest of the dashboard | Adds queries and can surprise users when a click clears or changes other panels; test with real usage patterns | Exploration dashboards where users drill from a summary into detail |
How filter design differs for executives, analysts and embedded users
Executive dashboards answer a small set of questions quickly, usually about performance against a target for the most recent period. The design goal is that the first view is correct and readable without any interaction, so filters should be few and their defaults should match the headline number the dashboard is known for. A filter that changes the meaning of a KPI card without a visible label is a common source of disputes in leadership reviews.
- Default to the reporting period leadership uses: Set the time filter default to the period the business reports on, such as the last closed month, and confirm that the default matches the figure in the monthly pack.
- Hide filters that split headline numbers: Remove or collapse dimension filters that can produce partial totals for a KPI, and keep drill-down for analysts elsewhere.
- Keep cross-filtering off by default: A click on one chart should not silently recolor or recompute a summary that executives read as company-wide.
- Name filters in business terms: Use labels such as Region or Product line, not column names, so a reader can tell what the current view includes.
- Show the active filter state: Use the horizontal filter bar, where available in your version, so the current scope is visible at the top of the page.
Before release, check that the default view matches a number already agreed with finance, and that every filter state an executive might leave behind still produces a total they recognize.
Analyst dashboards exist to be taken apart. Analysts add filters, move between charts and test hypotheses, so the design should expose more dimensions and make the scope of each filter explicit. The main risk is not missing data but misreading it, because a filter scoped to one chart or tab can leave other charts on a different population without any obvious signal.
- Expose more dimensions, scoped deliberately: Scope each native filter to the charts whose data it should change, and confirm the scope on every tab that holds charts.
- Use cross-filtering for exploration: Enable cross-filters where a click on a category should narrow related charts, and document which charts react to which source.
- Set defaults to all values: Leave dimension filters unset by default so analysts start from the full population and add constraints themselves.
- Mark filters that change the population: Give filters clear names and descriptions where a choice removes rows from a total, so analysts know when a number is a subset.
- Plan for query load: Many interacting filters each trigger queries on the warehouse, so review cached results and the number of charts that refresh when a filter changes.
Test a sample of analyst paths end to end, comparing a filtered total against the same total from SQL Lab, before publishing the dashboard to a wider group.
Embedded dashboards sit inside another product, so the filters a customer sees are part of that product's experience and its data boundary. Filters must work with the access rules that the host application applies, and the customer should not be able to widen a view past what they are entitled to see. Design decisions about defaults and visible controls are therefore tied to the embedding model and to how identity is passed in.
- Set defaults from the host context: Where the host knows the customer, a tenant or account filter should be fixed by the embedding setup rather than left for the user to change.
- Limit visible controls: Show only the filters that customers need, since each exposed control is a path to explore data the product team has not reviewed.
- Test cross-filtering with tenant data: Confirm that a click in one chart cannot reveal values outside the tenant, and that cached results are not shared across tenants.
- Align with embedded features: Check how drill and filter behavior is supported in embedded views for your Superset version before promising it in product documentation.
- Keep labels product-consistent: Use names that match the host application's vocabulary so customers do not need Superset knowledge.
Confirm with your embedding design that the filter scope, tenant isolation and caching behavior were tested together, not separately.
Setting up native filters in a dashboard
This sequence takes a dashboard from raw datasets to filters that users can trust. Each step produces a checkable result, so filter behavior is confirmed before the dashboard reaches wider audiences.
Confirm the datasets and columns filters will read
Before any filter is created, the dashboard owner and the data owner agree which datasets back the charts and which columns users will filter on. Check that those columns exist in every dataset that the filter will touch, that values are consistent in case and format, and that the column types match what users expect (for example, dates stored as dates rather than text). Mismatched columns are the most common reason a filter appears to do nothing. The step is done when each planned filter column has been confirmed against each dataset in writing.
Create native filters on the dashboard
In edit mode, the dashboard owner adds native filters from the filter panel and selects the filter type for each one, such as value, numerical range, time range or time grain, based on how users will narrow the data. Give each filter a label that describes the business question it answers, not the column name. Pick a dataset and column for each filter. The step is done when every planned filter exists in the dashboard and each one lists a dataset and column. Filters saved without a column produce no effect, so this should be checked before moving on.
Scope each filter to the charts it should affect
For each filter, the dashboard owner opens its scoping settings and selects the charts, or the tabs on a tabbed dashboard, that the filter should change. Charts that use a different dataset or lack the filter column should be excluded deliberately, not left to chance. Where the filter should apply to everything, confirm that is the intent. The step is done when a written scope map exists for every filter, listing which charts and tabs it touches and which it does not. Illustrative example: a region filter scoped to sales charts only, leaving a headcount chart untouched.
Set default values and their behavior
The dashboard owner sets a default value for each filter where a sensible starting point exists, such as the current quarter or the user's own region, and decides whether a filter should start empty, which shows all data. Defaults shape what users see first and the load each chart places on the database, so each default should be a value the audience actually needs. Confirm that the dashboard renders correctly with defaults applied and again after a user clears them. The step is done when a default table has been reviewed by the dashboard owner and recorded.
Enable cross-filtering where chosen
Cross-filtering lets a click on one chart filter the other charts on the same dashboard. The dashboard owner enables it only for chart pairs where the relationship is meaningful and the shared dimension exists in both datasets. Document which charts act as cross-filter sources, because each click triggers new queries against the database. The horizontal filter bar, now generally available since 6.0.0, can be used to present these filters at the top of the dashboard; confirm your version's behavior in the Superset documentation. The step is done when the list of cross-filter sources and targets is written down and a click on each source produces the expected change on its targets.
Test filters with representative users
Ask a small group of users who represent the intended audience to perform the questions the dashboard should answer, using only the filters. Watch for filters that users cannot find, labels they misread, defaults that hide data they expected, and charts that fail to update. Test with at least one account whose row level security or role restrictions limit the data, so you can see how filters combine with access rules. The step is done when the testers complete the agreed tasks without help and every issue found has been fixed or accepted by the owner. Record the test cases so they can be repeated after any change.
How filters change query load and caching
Every filter change on a native filter bar can send new queries to the warehouse for each chart it touches, so the number of charts a filter reaches is a load decision, not only a layout one. A filter scoped to all charts on a dashboard, combined with cross-filtering enabled on several charts, means one click can fan out into many parallel queries against the same database. Before rollout, list each filter with the charts it applies to, count how many of those charts will re-query on a change, and ask the database owner what concurrency the warehouse tolerates at peak. Narrow scoping and a short list of cross-filtering sources are the cheapest load controls you have.
Default values decide the first-load query, and that is the query most users will see first. A filter with a default that selects everything forces the full dataset query on every page open, while a default that narrows to a recent period or a team reduces the scan before anyone touches a control. Set defaults with the users who open the dashboard most often in mind, and test the first render on the slowest expected data source, not on a small development database. Record the default for each filter in your dashboard design notes so later edits do not silently widen the first query.
Do not promise response times for filtered dashboards until you have confirmed how caching behaves in your deployment. The Superset architecture documentation describes an optional caching layer and optional Celery worker and beat processes, and most installations use Redis and Celery for the features that depend on them. Confirm whether your chart and query results are cached, for how long, and whether cache keys differ per user or per role, because those answers determine whether repeated filter combinations are cheap. Measure with real filter combinations against a staging copy of the warehouse, then report the observed behavior with its conditions attached.
Access control and filter risks to review
Native filters shape what a user sees on a dashboard, but they do not decide what data a user may read. The four cards below cover the places where filter design can be mistaken for access control, leak information, or let the wrong people change how a dashboard behaves.
Filters do not replace row level security
A native filter only changes the query a chart sends for the current view. A user who clears the filter, opens the chart in another dashboard, or queries the same dataset through SQL Lab still reaches every row their role allows. Enforce restrictions with row level security rules on the dataset, then use filters only for convenience. Test with a restricted account to confirm that the rows are missing from the query results, not just hidden on screen.
Filter values reveal dimension members
A select filter populated from a column lists every distinct value the user can see, which can expose customer names, project codes, or regions the user is not otherwise meant to know exist. Check which datasets feed each filter, whether row level security applies to the value list, and whether a search box lets users probe for values. For sensitive dimensions, consider a text search filter or a curated value list instead.
Edit rights control scoping and defaults
Anyone with edit access to a dashboard can change which charts a filter applies to, what its default value is, and whether it is required. A reviewer who sees a dashboard as safe may find that a colleague has since re-scoped a filter so it no longer reaches a restricted chart. Limit edit rights to owners, record who changed filter configuration, and review scoping after each change to a shared dashboard.
Cross-filters can widen what users infer
Cross-filtering lets a click on one chart narrow every other chart on the page. Users can then combine results to infer values in charts they could see only in aggregate, especially with small groups where one remaining row identifies a person. Review which chart pairs can cross-filter on each dashboard, and check that small-cell results are acceptable to share before enabling click interactions.
Filter definitions in version control
Filter scoping, defaults, and value sources live in dashboard metadata that changes through the user interface. Export dashboards and compare filter configuration between releases, and confirm that a change to the Superset version does not alter filter behavior before rollout. Check the release notes for filter feature changes, since earlier flags for the legacy filter box and cross-filters have been removed.
Questions teams ask before building filters
Who builds the filters, DeployOpen or our own team?
Either can. Filter setup happens inside Superset's dashboard editor, so the people who know your datasets and business questions can do it directly. DeployOpen takes on the work when you want an outside team to plan, configure, test and document it. Most engagements are fixed-scope, so deliverables and acceptance checks are agreed in writing before work starts. Ask any partner, DeployOpen included, to state which dashboards, datasets and filter types are in the quote and which items are excluded. A split also works well: your analysts configure filters while an outside team reviews the design, tests scoping and writes the standards your editors follow.
Can our internal analysts build native filters alone?
Yes, for a small set of dashboards with clear questions. Native filters are configured in Superset's own interface, and an analyst with edit rights on the dashboard and access to the datasets can add a filter, choose its column and scope it to charts. The harder parts are judgment calls: which filters belong on a dashboard at all, which default values make the first view useful, how a filter behaves across tabs, and whether every chart that should respond actually does. Gaps usually appear when several people edit the same dashboard. Before you decide, confirm that your analysts have time for testing, a non-production database to test against, and a review step before dashboards reach wider audiences.
What drives the cost of a dashboard filter project?
The main drivers are the number of dashboards, the complexity of the datasets behind them and the depth of testing. Each dashboard adds layout decisions, filter scoping and checks of every chart it touches. Dataset complexity matters because virtual datasets, joins and calculated columns make it harder to confirm that a filter applies to the right chart. Testing scope matters because cross-filters and tabbed dashboards multiply the combinations a reviewer must check. Business sign-off rounds add time when stakeholders review late. Costs are one-time for the initial build and recurring when dashboards change or Superset is upgraded. Ask any quote to itemize dashboards in scope, dataset work, test cases, review rounds and handover, and to state what a later change costs.
How long does validation take as the dashboard count grows?
Validation time grows with the number of dashboards, filters and user groups, and no fixed figure applies across installations. Testing a filter means checking that it narrows the right charts, that default values load correctly, that cross-filters respond on click and that each role sees the expected result. A set of dashboards with many shared filters needs a test pass for each combination that matters. Ask the partner to state the test cases per dashboard and the environment used, and ask your own team how many stakeholders must approve. Upgrades add another validation cycle, so re-test filters after each one. The breaking-change notes in UPDATING.md list changes between versions and should guide that retest.
Do filters increase load on the warehouse and cache usage?
Yes, filters change the queries that run, so they change warehouse load. Every filter change re-queries the charts it applies to, and cross-filters trigger new queries each time a user clicks a value. Users who explore by filtering can send far more queries than a static view. The caching layer is optional in Superset, but the architecture documentation notes that async queries, alerts, reports and dashboard thumbnails depend on the caching layer and worker components, so plan those together. Reduce load by limiting filters on heavy datasets, setting sensible default values and pointing expensive filters at pre-aggregated datasets. Ask your warehouse team to review query patterns in a staging environment before release.
What do business owners need to provide for filter design?
Business owners need to supply the questions each dashboard answers, the dimensions users filter by and the view people should see first. Without these, filters tend to multiply until nobody uses them. Owners should list the top questions per audience, the filters that matter, the values that define a sensible default such as a current period or a region, and any filter that must stay on the dashboard. They also need to say who may see which rows, because row-level restrictions shape what a filter returns. Named reviewers who approve the design and test results before wider release keep the schedule predictable. Ask for a short sign-off record per dashboard so later changes have a documented baseline.
Do native filters change after a Superset upgrade?
Yes, some filter behavior has changed across major releases, so check your configuration after each upgrade. Superset 4.0.0 removed the legacy Filter Box, automatically migrated existing filter boxes to native filters and removed Filter Sets. Superset 5.0.0 removed the deprecated DASHBOARD_CROSS_FILTERS flag. Superset 6.0.0 made the horizontal filter bar generally available and removed its HORIZONTAL_FILTER_BAR feature flag. Any configuration that still sets those flags needs cleanup before the upgrade. Include filter re-testing in the upgrade plan, and read the breaking-change notes for your target version before you schedule the work.
What changed in recent Superset versions
Several filter behaviors that older dashboards depend on were removed or moved between major releases, so a dashboard built years ago may not look or behave the way its owners remember. In Superset 4.0.0, the legacy Filter Box was removed and existing filter boxes were automatically migrated to native filters. The Filter Sets feature was removed in the same release and has no direct replacement, so any team that relied on saved filter combinations needs to rebuild that behavior with native filters and default values. The migration is automatic, but automatic does not mean equivalent. A migrated filter keeps its column and scope as the migration interprets them, and that interpretation is worth checking chart by chart.
The feature flag history matters for the same reason. Superset 5.0.0 removed the deprecated DASHBOARD_CROSS_FILTERS flag, so cross-filtering stopped being something a team toggled and became part of how dashboards are built. In 6.0.0, the horizontal filter bar became generally available and its HORIZONTAL_FILTER_BAR feature flag was removed, so a team that once enabled it on purpose will find it active without a setting to review. Before upgrading any environment that predates these releases, confirm which flags your superset_config.py still sets. Leftover flag entries should be removed on purpose, not left to fail silently.
Upgrading old dashboards is where these changes bite. Back up the metadata database, run the upgrade in staging first, and read the breaking change notes in the UPDATING.md file for every version between your current release and the target. Then open each business-critical dashboard in staging and compare filter scopes, default values and cross-filter behavior against production. Record any difference and decide whether it is a defect to fix or an intended change to communicate to users before the cutover.
How DeployOpen scopes and delivers filter design
DeployOpen plans, builds, documents and supports self-hosted Apache Superset inside your own infrastructure, including the filter design for your dashboards. Filter work starts with a written scope that names the dashboards, datasets and users involved, so the filters are designed around how your teams read the data.
How we scope
- Engagements are fixed-scope, with dashboards, filter types and deliverables agreed in writing before work starts.
- We inventory the dashboards, datasets and charts that need native filters or cross-filtering, and record which ones are shared.
- The written scope states which filters apply to which charts and tabs, and which default values users will see on first load.
How we build
- We configure native filters, scoping and cross-filters in your Superset instance, following the filter design agreed in scope.
- We test each dashboard with representative users and check that filter combinations return the expected results.
- We measure the query load that filters add to your warehouse and adjust datasets, defaults and caching settings where needed.
How we hand over
- You receive a filter inventory listing each filter, its scope, its default and the datasets behind it.
- We document the filter conventions so dashboard owners can add or change filters without breaking existing charts.
- Handover includes a walkthrough with the team that will own dashboards after go-live, covering troubleshooting and changes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- Retained support can cover review of new dashboards and filters before they reach wider audiences.
- Superset upgrades can change filter behavior, so we can test dashboards in staging against each upgrade before production.
