skip to content

In Power BI, what filters a drill-through page when a reader right-clicks a data point?

level: middleimportance: must knowfreq 60%

answer

  1. the target page announces what it expects
  2. only visuals containing those fields offer it
  3. a toggle decides whether the rest of the context travels
  4. not the same as walking a hierarchy in one visual
  5. Power BI adds a way back for you

basics

~20 s

The values of the fields placed in the target page's drill-through well, taken from the clicked data point. With Keep all filters on, the source visual's other filters travel too, so the detail page matches the context the reader came from.

solid answer

~40 s

A drill-through page is an ordinary report page that declares which fields it expects, by putting them in its **drill-through** field well. Any visual elsewhere in the report that contains those fields then offers a right-click **Drill through** entry. When the reader takes it, Power BI navigates to that page and applies the clicked point's values for the declared fields as page filters. The **Keep all filters** toggle, on by default, additionally carries over the other filters that were affecting the source visual — slicers, page filters, cross-filtering — so the detail page shows the same slice the reader was looking at. Power BI adds a **back button** to the target page automatically. This is navigation to a different page; it is not drill-*down*, which walks a hierarchy inside one visual.

code

text · 11 lines
text
-- Target page "Customer detail" (hidden from the tab strip)
Drill through well:  Customer[CustomerName]
Keep all filters:     On

-- Reader is on the summary page with:
   Slicer: Year = 2026
   Clicks: bar for CustomerName = "Contoso Ltd"

-- Filters arriving on the target page
   CustomerName = Contoso Ltd     <- from the drill-through well
   Year = 2026                    <- only because Keep all filters is On

go deeper

for a junior

Know that drill-through is a right-click navigation to a detail page, that the target page declares the fields it expects, and that a back button appears automatically.

for a middle

Explain the mechanics: declared fields become page filters holding the clicked values, Keep all filters decides whether the surrounding context travels, and drill-down is a different feature.

for a senior

Demonstrate design judgment — choosing slice-faithful versus full-profile detail pages, hiding target pages, echoing the passed context in the title, and diagnosing a greyed-out or unfiltered target as a model problem.

for a principal

Decide where detail belongs at all: a drill-through page inside the report, a paginated report for row-level extracts, or cross-report navigation between separately owned reports — and set the convention so readers meet one pattern everywhere.

## What drill-through is for Summary pages answer "how big" and "which way is it moving". They rarely answer "why", because the rows that explain a number do not fit next to the number. Drill-through solves that by putting the detail on its own page and letting the reader arrive there already filtered to whatever they clicked. ## How the target page declares itself You build the target page normally, then drop one or more fields into the page's **drill-through** well. Those fields are the page's contract: they say "I am a detail page about a Customer" or "about a Product and a Month". Two consequences follow. First, only visuals containing those fields offer the right-click entry. If the page declares `Customer[CustomerName]` and the reader right-clicks a bar on a chart broken out by product, no drill-through to that page is offered, because there is no customer value to pass. This is the most common "why is drill-through greyed out" support ticket. Second, each declared field becomes a filter on the target page, pinned in the filter pane, holding the value that came from the click. The page's own visuals then all see it, because it is a page-level filter like any other. ## Keep all filters Next to the drill-through well sits a **Keep all filters** toggle, on by default. On means the filters that were shaping the *source visual* — page-level filters, slicers, report-level filters, cross-filtering from another visual — travel to the target page as well. Off means only the declared drill-through fields travel. The choice is a real design decision, not a formality. Leave it on when the detail page must show exactly the slice the reader was staring at ("orders for this customer, in the date range and channel I had selected"). Turn it off when the detail page is meant to be a complete profile — "everything we have ever done with this customer, regardless of what page 1 was filtered to". Getting it wrong produces the report bug "drill-through shows fewer rows than the number I clicked", or its mirror, "drill-through shows more than the total". ## Navigation and the back button Power BI adds a back button to a drill-through target automatically, and it returns the reader to the page and state they left. It is worth keeping. Detail pages are usually hidden from the page tab strip so nobody lands on them cold — a hidden page is still reachable by drill-through, and hiding it is the normal pattern. **Cross-report drill-through** extends the idea across reports in the same workspace: the target report enables it, and a source report can then offer navigation into it, passing the shared fields. It depends on the two models sharing field names and on the setting being enabled, so treat it as a deliberate integration rather than an incidental feature. ## Drill-through is not drill-down The vocabulary trips people up. **Drill-down** stays in one visual and walks a hierarchy — Year to Quarter to Month, Country to State to City — using the drill controls in the visual's header; the visual re-queries at the next level. **Drill-through** leaves the visual entirely and navigates to a different page carrying the clicked context. Expand-all is a third thing again: it shows parent and child levels together on one axis. An interviewer asking about drill-through is usually listening for whether you distinguish these three, because a candidate who conflates them will design the wrong thing when asked for "more detail". ## Practical notes and failure modes Drill-through passes *values*, so the field must exist in a table the target page's visuals can be filtered by — the model has to connect them. A detail page built on a table with no relationship to the field being passed will simply ignore the filter and show everything, which looks like a broken page but is a modelling problem. Row-level security still applies on the target page: drill-through never widens what a reader may see, because the filters run inside the model's queries. Finally, put a title on the detail page that echoes the passed value. A page that says "Orders — Contoso Ltd, 2026 Q2" tells the reader what they are looking at and instantly exposes the case where the wrong context travelled.

  • A reader says Drill through is greyed out on your chart. What is the most likely cause?
    The visual does not contain the field the target page declared in its drill-through well, so there is no value to pass. Either add that field to the source visual's context, or declare a field on the target page that the source visuals actually carry.
  • When would you turn Keep all filters off on a drill-through page?
    When the detail page is meant to be a full profile rather than a slice: an all-time customer page, or a product page you want identical no matter which page the reader arrived from. Leave it on when the reader must see exactly the rows behind the number they clicked, which is the more common intent.
  • How is drill-through different from drill-down in a Power BI visual?
    Drill-down stays inside one visual and moves along a hierarchy, re-querying at the next level. Drill-through navigates to a different report page and applies the clicked point's field values as filters there. One changes the grain of a chart; the other changes the page you are on.

saying these in an interview costs you the question

  • Confuses drill-through with drill-down through a hierarchy
  • Thinks drill-through automatically carries every filter regardless of settings
  • Believes any visual on the page can drill through to any page
  • Says drill-through can show rows the reader's security role hides
  • Forgets that the target page's declared fields are what make it reachable

context