Filters, drill-down and interactivity

Why this matters

Interactivity is what makes a dashboard more than a static chart: users can narrow the data to their own region, move from a total to its parts, and follow a question as far as they need. It also introduces new ways to be wrong. A filter set weeks ago and forgotten, a drill-down that silently changes a measure's meaning, or a dashboard so slow that nobody waits for it can undo the value of a well-designed report.

The exam's reporting objective includes delivering interactive summaries. This lesson covers filters, slicers and parameters; drill-down and drill-through; default views and hidden filters; performance; and documenting interactions.

The lesson

Filters, slicers and parameters

Filters restrict the data a report shows: one region, one product line, the last quarter. They can be applied at several levels, and the level matters.

• A report-level filter applies to every page.
• A page-level filter applies to all visuals on one page.
• A visual-level filter applies to a single chart.

A filter set at one level is not visible at another, which is how two charts on the same page can show different totals without either being wrong.

A slicer is a filter displayed on the page as a control, such as a list of buttons or a date range, that users click to change what they see. Slicers make filtering visible and easy, and they are usually connected to several visuals at once.

A parameter is a user-chosen value that changes a calculation rather than filtering data: a target growth rate in a what-if analysis, the number of top products to show, or the currency for display. Parameters let one report serve several scenarios.

Filters should be designed around the questions users ask. Too few, and the report cannot answer them; too many, and users are overwhelmed or combine filters in ways that produce empty or misleading results.

Drill-down and drill-through

Drill-down moves from a summary to more detail within the same visual, along a hierarchy: year to quarter to month, or region to city to store. A user clicks a bar for 2025 and sees its quarters. It suits exploration along a natural hierarchy.

Drill-through moves from one report page to another, more detailed page, filtered to the item selected. Clicking a customer on a summary page opens a customer detail page showing only that customer's orders. It suits moving from an overview to a focused view with different content.

Both need care with measures. A measure that is correct at one level may not be meaningful at another: an average order value per region is correct, but drilling down to a single order and showing its "average" is trivial, and a distinct count of customers does not add up across months, because the same customer may order in several. Drill paths should be tested at every level, not only the top.

A report should always make clear where the user is: which level, which filters and which selection, often with a breadcrumb or a visible filter summary.

Default views and the filter nobody noticed

Most people use a dashboard exactly as it opens, so the default view is the most important one. It should answer the dashboard's main question without any interaction, typically showing the whole organisation for the current period.

A common problem is a filter left applied by the report's author, such as a test filter to one region or a date range from development, that becomes the default for everyone. Every figure on the page is then correct for a subset that nobody realises they are looking at.

Protections include showing active filters prominently, resetting to a sensible default when a report opens, labelling totals with the filters that produced them ("Sales, North region, Q3 2025"), and a reset control that returns to the default view. Reviewing a report's default state before publishing is a simple check that catches this reliably.

Performance: why a slow dashboard is not used

Users abandon slow dashboards. A page that takes thirty seconds to respond to each click will be replaced by an exported spreadsheet, and the governed, refreshed report loses to a stale copy.

Common causes of slow dashboards include:

• Too much data loaded or queried: row-level detail when summaries would do.
• Too many visuals on a page, each running its own query.
• Complex calculations computed at query time rather than prepared in advance.
• Live queries against slow or busy sources.
• High-cardinality fields, such as order IDs, used in slicers or charts.

Remedies include pre-aggregating data to the grain the dashboard actually needs, reducing visuals per page, moving heavy calculations into the data preparation step, using imported or cached data where freshness allows, and indexing or partitioning the source. The target is for common interactions to respond within a few seconds.

Documenting what each interaction does

Interactive reports hide their logic behind clicks, so users need to know what each control does and what each figure means.

Useful documentation includes:

• Measure definitions, often available as tooltips or an information page: what "active customer" or "net revenue" means.
• Filter behaviour: which visuals each slicer affects, and whether filters carry across pages.
• Drill paths: what clicking on each visual does.
• Data freshness: when the data was last refreshed and how often.
• Ownership: who maintains the report and whom to contact about it.

Documentation should live in or beside the report, where users will see it, not in a separate document nobody opens. A short "how to use this dashboard" panel, with tooltips on each KPI, prevents most of the questions and most of the misreadings.