Dashboard filters and interactivity

This is the exact file agents read, including the credit header and licence notice. Save it as dashboard-filters-interactivity/SKILL.md.

---
name: dashboard-filters-interactivity
description: >
  Design the filters, controls and linked interactions on a dashboard so a viewer answers their own question fast, instead of drowning in slicers that slow the page and surprise them. Start from the tasks the viewer performs (overview first, zoom and filter, details on demand), decide what is fixed context and what they change, choose the scope and the control for each filter, set a sensible default rather than "show all", design cross-filtering and drill paths on purpose, respect the tool's filter order of operations, and hold a performance budget. Covers global versus local filters, date, dropdown, search, checkbox, range and toggle controls, default and persisted state, cross-highlighting, drill-down versus drill-through, hover-preview and click-commit, reset and undo, Tableau actions and context filters, Power BI slicers, the filters pane and edit interactions, accessibility and mobile. Use it when someone says "add filters to my dashboard", "make this dashboard interactive", "which slicers should I use", "my dashboard is slow when I filter", "clicking one chart changes everything", "add a drill-down", or "nobody can find anything on this dashboard". Do NOT use it to choose which metrics to show or lay out the tiles (see dashboard-design), pick a single chart type (see chart-selection), write a narrative report or dashboard commentary (see data-storytelling), schedule a static report (see report-automation), or run the analysis behind the numbers (see the data-analysis skills).
license: Free to use and adapt under CC BY 4.0, with credit to Afeez Adebayo. Link afeezadebayo.com, https://www.linkedin.com/in/afeez-adebayo/ and this skill's page at https://afeezadebayo.com/skills-md/data/dashboards-reporting/dashboard-filters-interactivity/.
---

# Dashboard filters and interactivity

## When to use this, and when not to

Use this skill when a dashboard exists or is being built and the job is the interactive layer: the filters, slicers, date pickers, drill-downs, click actions and linked views that let a viewer narrow the data to their own question. The triggers are a request to add filters or make a dashboard interactive, a question about which slicers or controls to use, a complaint that the dashboard is slow when filtered, that clicking one chart unexpectedly changes everything, or that viewers cannot find what they need.

Do not use it to choose which metrics appear or lay out the tiles, which is `dashboard-design`, to pick a single chart type, which is `chart-selection`, or to write the narrative that explains a result, which is `data-storytelling`. Scheduling a static report is `report-automation`, and the analysis that produces the numbers is the data-analysis skills. This skill assumes the metrics and layout are decided, and designs how the viewer moves through them.

The core idea: interactivity is a cost, not a free feature. Every control adds a thing to learn, a way to get lost, and a query to run. Add a control only when a viewer has a real task it serves, and follow the pattern that has worked since Shneiderman named it: overview first, zoom and filter, then details on demand (referenced in openai/plugins, "dashboards-and-real-time-visualization"). A dashboard with twenty filters and cross-filtering everywhere is not more powerful, it is slower and more confusing than one with three good controls and deliberate links.

## Inputs the agent must have before starting

1. **The viewer tasks.** What each audience actually does: notice an exception, compare this period to last, find the worst segment, inspect one account. The task list decides every control, so ask for it first. "The regional manager filters to their region and finds the three worst stores" is enough; "make it interactive" is not.
2. **What is fixed and what changes.** Which dimensions a viewer changes often (date range, region, segment) and which are set once and left (the current fiscal year). The first become on-canvas controls; the second belong in a quieter filter pane.
3. **The data size and cardinality.** Roughly how many rows, and how many distinct values the filter fields hold. A field with thousands of values cannot be a checklist, and a shared filter over a very large table is where dashboards go slow.
4. **The tool and the delivery.** Tableau, Power BI, Looker Studio, a spreadsheet, or a hand-built page. The reasoning is the same; the mechanics in the appendix differ, and version-dependent behaviour carries a "verify before relying on this" note.
5. **Whether any interaction writes back or changes data.** A parameter or action that edits a record, triggers a job, or changes a shared setting is an irreversible action on someone's behalf and waits for explicit confirmation. Default to read-only.
6. **Access and sensitivity of the underlying data.** Whether drill-down can reach personal or restricted rows, and what row-level security applies, so interaction never exposes data a viewer should not see.

If the viewer tasks are unknown, stop and ask. A filter that serves no task is clutter you will have to remove later.

## The workflow, step by step

### 1. List the viewer tasks and map them to the interaction pattern

Write each task as "[viewer] needs to [verb] [what]". Then place each on the Shneiderman path: an overview everyone sees first, a way to zoom or filter to a subset, and details on demand for the one row that matters (openai/plugins). Interaction should reduce effort, not hide essential context behind constant clicking.

Decision rule: if a task is served by the overview alone, it needs no control. Add a control only for a task the overview cannot answer.

### 2. Separate fixed context from what the viewer changes

Split the filters into two groups. Context that is set once and rarely touched (the current year, the active product line) goes in the filter pane or a page-level filter, out of the way. Dimensions the viewer changes often (date range, region, segment) become visible on-canvas controls, because a slicer shows the current state at a glance while a filter pane hides it (Microsoft Learn, "Slicers in Power BI").

Decision rule: if a viewer changes a filter on most visits, put it on the canvas. If they set it once and forget it, put it in the pane.

### 3. Choose each filter's scope: global or local

A global filter changes the whole dashboard; a local filter changes one view. Make shared dimensions such as time, region and segment global, so one change moves the whole page together. Keep a filter local when its view uses a different dataset or when a global change there would confuse (aufaitux, "Dashboard filter design guide").

Decision rule: a dimension that exists in every tile is global. A dimension that exists in one tile, or that would wrongly blank the others, is local to that tile.

### 4. Choose the control type for each filter

Match the control to the field, not habit (aufaitux):

- **Date:** a range picker with presets (last 7 days, last 30 days, this quarter). Relative dates recompute on each load.
- **A short list (2 to 5 options):** radio buttons or a button group for single select; checkboxes for multi-select, with a live result count.
- **A long list (more than about 10 options):** a dropdown with search. Past about 50 values, a searchable modal or typeahead, never a wall of checkboxes.
- **A number:** a range slider paired with typed inputs.
- **A binary:** a single toggle.
- **The active state:** show applied filters as chips, each with its own remove control, and a visible "clear all".

Decision rule: if a list filter would render more than about 10 to 15 items on screen at once, switch to a searchable dropdown. If it exceeds the control's hard limit, such as Power BI's 2,000-item paste cap, it needs search and a default, not a full list (Microsoft Learn).

### 5. Set a sensible default, never a raw "show all"

Default each control to the most common question, not to everything. Defaulting a high-cardinality field to "all values selected" loads the whole table and shows noise; default instead to the most recent period or the viewer's own segment, and persist the state so a returning viewer lands where they left off (aufaitux). In Power BI, note that "Select all" then clearing items applies an inverted "is not" filter, so new values added on refresh are included automatically, which can surprise (Microsoft Learn).

Decision rule: if the field has more than a few dozen values, do not default to all. Default to the top segment or latest period, and let the viewer widen from there.

### 6. Design cross-filtering and linked views on purpose

Linking views (brush and link) is powerful and the main source of "I clicked one chart and everything changed". Decide, per visual, what a selection should do: filter the others, highlight within them, or nothing. Turn interactions off for visuals that must stay stable, such as a KPI row or a target, using Power BI's Edit interactions or, in Tableau, by scoping each dashboard action (Microsoft Learn; Tableau, "Actions"). Tableau offers distinct actions for this: a filter action narrows another view, a highlight action dims the rest without filtering, and parameter or set actions let a click change an input (Tableau, "Actions").

Decision rule: a KPI, a total or a target does not change when a viewer clicks a detail chart. Set its interaction to none. Default to highlight rather than filter when the viewer needs to keep seeing the whole.

### 7. Choose drill, commitment and recovery

Pick the drill pattern: drill-down stays in place and goes deeper down a hierarchy; drill-through moves to a detail page filtered to the one thing clicked, which keeps the summary uncluttered (Microsoft Learn). On the desktop, hover previews and a click commits; on touch, a tap previews and an explicit action commits, because hover does not exist (openai/plugins). Keep a selection that survives a data refresh, and always give an explicit reset and a way back (openai/plugins).

Decision rule: if a detail view would crowd the summary, make it a drill-through to its own page, not another tile. Every interactive path has a visible way back to the overview.

### 8. Respect the tool's filter order of operations

Filters do not all run at once, and the order changes the result. In Tableau the sequence is data source, then context, then dimension filters, with Top N and other dimension filters running together, then table calculations (Tableau, "Order of operations"). So a Top N inside a filtered view can rank across the unfiltered set unless the narrowing filter is made a context filter: filter to one region and ask for the top 10 customers, and without a context filter you get the global top 10, not the region's (The Data School, "Context filters"). Get the result correct before making it fast.

Decision rule: if a view combines a Top N (or another computed limit) with a filter that should scope it, make the scoping filter a context filter so the ranking is computed within the subset.

### 9. Hold a performance budget

Slow interaction is a top reason dashboards are abandoned, so set a budget and keep to it. Apply filters live only when the source responds in under about 300 milliseconds; otherwise use an Apply button so several filters update in one query, and show a skeleton loader rather than a spinner or a blank (aufaitux). Keep the primary controls few, two or three in view with the rest behind a menu, and keep the visual count modest, since every visual re-queries on each change (poweruser, "Why is Power BI so slow"). Do not share one filter across many sheets or visuals by default: one cross-sheet title filter over 27 million rows took over five minutes to load, and applying it per sheet cut that to under a second, a 99.8% reduction (dev.to, "How we reduced Tableau load time"). Avoid high-cardinality filters and automatic date hierarchies on large tables, pre-aggregate where you can, and use context filters sparingly because each adds overhead.

Decision rule: if a filter change takes longer than a few seconds, do not add another control. Reduce the shared scope, add an Apply button, or pre-aggregate first.

### 10. Make it accessible and mobile-ready

Controls must be reachable by keyboard, carry visible focus and real labels, and announce their state to a screen reader. On mobile, do not stack a filter rail before the data: put filters in a bottom sheet or drawer with an Apply button that returns the viewer to the affected view, and show a count badge such as "Filters (3)" (openai/plugins; aufaitux). Do not rely on hover for anything essential, because it does not exist on touch.

Decision rule: every control works by keyboard alone, and nothing essential is available only on hover.

### 11. Verify against the quality bar

Run the finished design against the quality bar below before handing it over. Every item is checkable, not aspirational.

## Worked example, end to end

A sales operations dashboard has grown to twelve filters down the side, cross-filtering turned on everywhere, and a load that stalls for twenty seconds whenever anyone touches a slicer. Clicking a regional bar also resets the headline KPIs, so no one trusts them.

Starting from the tasks: the VP wants the national overview and the worst region; a regional manager wants their region and its three worst stores; an analyst wants to inspect one store. Three tasks, three depths, which is the overview, zoom and filter, details-on-demand path.

The controls are cut to three on the canvas: a date range defaulting to the last 30 days, a region dropdown with search, and a segment toggle. The other nine filters move into a collapsible menu, since they are set rarely. Defaults stop loading the whole table: the date is the last 30 days, not all time, and region defaults to national with the manager's own region remembered on return.

Interactions are made deliberate: the KPI row's interaction is set to none so clicking a region no longer disturbs the headline numbers; clicking a region highlights rather than filters the trend, so the national line stays visible for comparison; a store drill-through opens a filtered detail page rather than crowding the overview. The "top 3 worst stores" table was ranking nationally even after a region was picked, so the region filter is made a context filter and the ranking now computes within the region.

Performance is brought inside budget: because the regional queries run in about a second, an Apply button batches the filter changes into one refresh, a skeleton loader shows while it runs, and the single shared cross-sheet filter is replaced with per-view filtering. Load drops from twenty seconds to about one. A visible "reset" returns anyone to the national overview, every control is keyboard-reachable, and on mobile the filters sit in a bottom sheet with a count badge. The dashboard now answers each viewer's question in a couple of clicks, and the KPIs hold still.

## Templates you can use verbatim

**Interactivity spec (fill this in before adding any control):**

```
Viewer tasks:        [viewer] needs to [verb] [what]  (one line each)
Overview:            what everyone sees before touching a control
Fixed context:       filters set once -> filter pane
Changed often:       filters touched most visits -> on-canvas controls
Per filter:          field | scope (global/local) | control type | default
Cross-filter map:    which visual filters/highlights which; which stay static
Drill:               drill-down (in place) or drill-through (detail page)
Reset + state:       how to get back; what persists between visits
Performance:         live (<300ms) or Apply button; shared-filter check
Access + mobile:     keyboard, labels, focus; mobile drawer + Apply
Write-back?:         any action that changes data -> confirm first
```

**Filter decision table (one row per filter):**

| Field | Values | Scope | Control | Default |
|---|---|---|---|---|
| Date | continuous | global | range + presets | last 30 days |
| Region | 6 | global | dropdown | national |
| Product | 2,000+ | global | search dropdown | top segment |
| In stock | 2 | local | toggle | on |

**Per-control checklist:** serves a named task; scope correct (global or local); control fits the field size; default is not raw "show all"; active state shown as a chip; keyboard-reachable and labelled; interaction with KPIs set to none; a visible reset exists.

## Failure modes and anti-patterns

1. **Filter sprawl.** A dozen controls down the side, most never used, so the real ones are lost and the page is slow. Spot it by counting controls against tasks: more controls than tasks means sprawl. Fix: keep two or three primary controls in view, move the rest behind a menu, and remove any that serve no task (poweruser; aufaitux).
2. **Defaulting to "show all" on a big field.** A high-cardinality filter opens with everything selected, loading the whole table and showing noise. Spot it from a slow first load and a full, unscoped view. Fix: default to the latest period or the top segment, and let the viewer widen (aufaitux; Microsoft Learn).
3. **Surprise cross-filtering.** Clicking one chart silently changes the KPIs or an unrelated visual, so viewers stop trusting the numbers. Spot it by clicking each chart and watching what else moves. Fix: set interactions on KPIs and totals to none, and default to highlight rather than filter where the whole must stay visible (Microsoft Learn; Tableau).
4. **Top N wrong under a filter.** A "top 10" ranks across the whole dataset even after the viewer filters to a subset, because of the filter order of operations. Spot it by filtering to one group and checking the ranked list matches that group. Fix: make the scoping filter a context filter so the rank computes within the subset (Tableau; The Data School).
5. **Instant filtering on a slow source.** Live filtering is left on over a large or slow dataset, so every click stalls the page. Spot it when a single filter change takes more than a few seconds. Fix: add an Apply button to batch changes, stop sharing one filter across many views, pre-aggregate, and show a skeleton loader (dev.to; aufaitux).

## Quality bar

- Every control serves a named viewer task; there are no controls without a task.
- Fixed context sits in the filter pane; frequently changed dimensions are on-canvas controls.
- Each filter's scope (global or local) is set correctly, and the control type fits the field size.
- No high-cardinality field defaults to "show all"; defaults are the latest period or the top segment, and state persists on return.
- Cross-filtering is deliberate: KPIs and totals are set to not change on click, and highlight is used where the whole must stay visible.
- Drill-through is used for detail that would crowd the overview, and every interactive path has a visible reset.
- Any Top N or computed limit that should respect a filter uses a context filter so it computes within the subset.
- Filtering meets a performance budget: live only under about 300ms, otherwise an Apply button, with no single filter shared across many views by default.
- Controls are keyboard-reachable, labelled and focus-visible, nothing essential is hover-only, and mobile uses a drawer with an Apply button.
- Any interaction that writes back or changes data waits for human confirmation.

## Data handling and safety

Interactivity can reach data a static view would not. Drill-through and detail-on-demand can surface personal or restricted rows, so respect the row-level security and access controls on the source rather than letting a filter bypass them, and never widen a viewer's access through an interaction. Do not paste real customer records or credentials into prompts while designing controls. A parameter action, set action or write-back control that edits a record, triggers a job or changes a shared setting is an irreversible action on someone's behalf, so default to read-only and confirm before enabling it. Never fabricate a filter value, a count or a benchmark to fill a control; an empty state that says "no data matches" is honest, and anything version-dependent carries a "verify before relying on this" note. When the dashboard informs decisions about health, money, legal standing or employment, keep a human-review step and state that it is a decision aid, not the decision.

## Appendix: tool-specific notes (verify before relying on these)

- **Tableau:** use dashboard actions for interactivity, a filter action to narrow another view, a highlight action to dim the rest, and parameter or set actions to let a click change an input; actions run on hover, select or menu. Mind the order of operations and make a scoping filter a context filter (the grey pill) so a Top N computes within it. Use the performance recorder, and extract rather than live-query large sources to hold the load budget.
- **Power BI:** slicers are on-canvas controls (list, dropdown, button, numeric range, relative date, hierarchy); the filters pane holds fixed scope. Sync slicers across pages from the View ribbon. By default a slicer filters every other visual, so use Edit interactions to set KPIs and totals to none. Add Apply all and Clear all buttons to batch changes and cut queries, use drill-through pages for detail, and turn off auto date/time on large models, preferring a dedicated date table.
- **Looker Studio:** use controls for filtering, set a sensible default date range on the report, and use cross-filtering deliberately rather than leaving every chart linked. Define fields once in the data source so filters behave consistently.
- **Spreadsheets (Excel, Google Sheets):** slicers on a pivot table or filter views give light interactivity; keep the control count small and watch recalculation cost as the data grows.
- **Hand-built HTML:** filter the data client-side, debounce rapid input, and update only what changed rather than rebuilding the DOM; in Chart.js, use `chart.update('none')` for filter-triggered updates. Make controls real form elements with labels, keyboard support and visible focus, and keep the page responsive to phone width. See `chart-selection` for the chart mechanics and `dashboard-design` for the layout.

## Sources

- Tableau, "Actions" and "Tableau's order of operations" (help.tableau.com): the dashboard action types (filter, highlight, go to URL, go to sheet, change parameter, change set values) and their run triggers, and the filter sequence (data source, context, dimension and Top N together, then table calculations) that makes a context filter necessary to scope a Top N. Verified 4 November 2026.
- Microsoft Learn, "Slicers in Power BI" and the effective-filtering guidance: slicer types and the slicer-versus-filters-pane split, the inverted "is not" behaviour of Select all, sync slicers, Edit interactions to stop a visual changing, Apply and Clear all buttons, drill-through, and the 2,000-item paste limit. Verified 4 November 2026.
- The Data School, "Context filters: how to control Tableau's order of operations": the worked New York City plus Top 10 customers example showing a Top N ranking across the whole set until the scoping filter is added to context. Verified 4 November 2026.
- Aufait UX, "Dashboard filter design guide": matching the control to the field (dropdowns with search above 8 to 10 options, searchable modal above 50, checkboxes with counts, radio for 2 to 5, range sliders, chips for active filters), global versus local scope, the sub-300ms threshold for live versus Apply filtering, persisted state, zero-result handling, and keyboard and mobile requirements. Verified 4 November 2026.
- dev.to, "How we reduced Tableau workbook load time by 99.8% using smarter filter design": a shared cross-sheet filter over about 27 million rows loading in over five minutes, cut to about 0.65 seconds by applying the filter per sheet, plus guidance to avoid filters on all worksheets by default and to aggregate at source. Verified 4 November 2026.
- poweruser (Substack), "Why is Power BI so slow": limiting a page to roughly three visuals and two to three front-page filters, turning off interactions on static visuals, replacing auto date/time with a calendar table, and preferring a star schema, because every interaction re-queries connected visuals. Verified 4 November 2026.
- Existing skill implementations reviewed as benchmarks: anthropics/knowledge-work-plugins `build-dashboard` (interactive HTML dashboard with dropdown, date and combined filters), openai/plugins `dashboards-and-real-time-visualization` (the overview-zoom-filter-details pattern, brush and link, drill-through, hover-preview and click-commit, reset and undo), and nimrodfisher/data-analytics-skills `dashboard-specification` (justify every filter and drill-down). Reviewed 4 November 2026 to confirm this skill adds decision rules, the order-of-operations correctness step, the performance budget and the accessibility bar the rivals leave out.