Drillthrough pages are one of the most powerful — and most misunderstood — features in Power BI. This lesson teaches you how to build production-ready detail views that pass the right filter context, navigate cleanly in both directions, and even bridge across separate report files with cross-report drillthrough.

You're presenting a regional sales summary to your leadership team. The VP of Sales points at the Southeast region's underperforming revenue bar and asks, "Can we see what's actually driving that?" You click on the bar, right-click, and in two seconds you're on a dedicated detail page showing every sales rep, product category, and customer account scoped specifically to the Southeast — no slicer adjustments, no page switching, no frantic explaining. That's drillthrough working exactly as it should.
Drillthrough pages are one of the most underused and misunderstood features in Power BI. Most practitioners know they exist, but far fewer know how to build them in ways that actually hold up in production: pages that carry the right filter context, navigate cleanly in both directions, maintain visual consistency, and can even bridge across separate report files. When done well, drillthrough transforms a report from a static summary into a genuine investigative tool — one that lets users follow their intuition without asking you to build a new view every time.
By the end of this lesson, you'll know how to build drillthrough pages that feel professional and intentional, not bolted on. You'll understand the filter mechanics under the hood, so you can predict and control exactly what context gets passed. You'll build a working back button, handle edge cases, and wire up cross-report drillthrough so users can navigate between files seamlessly.
What you'll learn:
.pbix files in Power BI ServiceYou should already be comfortable building reports in Power BI Desktop — creating visuals, working with pages, and understanding how filters propagate through a data model. Familiarity with filters, slicers, and cross-filtering in Power BI will make the filter mechanics section much easier to follow. If you've built any bookmark-based navigation, that context will help in the back button section — the bookmarks, buttons, and page navigation article covers the foundation.
Before you build anything, you need to understand what drillthrough is actually doing under the hood — because once you understand the mechanics, everything else falls into place.
When a user right-clicks on a data point and selects a drillthrough target, Power BI is doing two things simultaneously. First, it reads the filter context of the data point being clicked — the combination of all dimension values that uniquely define that point. Second, it applies that context as a page-level filter on the destination drillthrough page before rendering any visuals.
This is fundamentally different from cross-highlighting or slicer-based filtering. The context arrives as a filter, applied at the page level, not as a visual interaction. That distinction matters because page-level filters in Power BI have specific behavior: they're not visible in slicers, they don't appear in your filter pane unless you look for them, and they propagate through all relationships in your model in the same way any other filter would.
The field or fields you place in the Drillthrough field well of the destination page determine what context gets passed. Think of that field well as a declaration: "This page is designed to receive drillthrough on this field. When a data point containing this value arrives, apply it as a filter."
Here's the key nuance that trips up a lot of practitioners: the drillthrough field well accepts a field from your model, but what gets applied as a filter is the value of that field as it exists on the source visual. If your source visual shows Region = Southeast, and you've placed Region in the destination page's drillthrough well, then arriving at that destination page means Region is filtered to Southeast at the page level. Every visual on that page now operates within that filter context automatically.
Key insight: Drillthrough passes the filter values of the clicked data point to the destination page — not the visual's own filter settings, not slicer selections from other visuals (unless you enable that), just the dimensional context of the clicked element itself. Understanding this boundary is critical for predicting what your detail page will show.
If your source visual is a matrix with rows broken out by Region and columns by Quarter, right-clicking on a specific cell passes both Region and Quarter to the destination page — provided both fields exist somewhere in the destination's drillthrough well or are naturally constrained by your model relationships.
Let's build something real. We'll use a sales analytics model with these tables:
Sales fact table with columns: OrderDate, Revenue, Quantity, CustomerID, ProductID, SalesRepIDDim_Region with RegionKey, Region, TerritoryDim_Product with ProductKey, Category, SubCategory, ProductNameDim_SalesRep with SalesRepKey, SalesRepName, ManagerDim_Customer with CustomerKey, CustomerName, SegmentYour summary report page shows revenue by region as a bar chart. You want a drillthrough page that, when invoked from any region bar, shows the full breakdown: top products, top customers, rep-level performance, and a transaction table — all scoped to that region.
Add a new page to your report. Right-click the page tab and rename it something descriptive: Region Detail. This page is where users will land after drilling through.
Now, immediately set this page's visibility. In the Format pane with the page canvas selected, find Page information and toggle Hidden to On. This prevents users from accidentally navigating to this page directly from the tab bar — drillthrough pages should only be accessed via drillthrough. If they navigate here without filter context, every visual would show unfiltered data, which is confusing and often misleading.
Click anywhere on the blank canvas of your Region Detail page. In the Visualizations pane, you'll see a section labeled Drillthrough below the main well areas. Drag the Region field from Dim_Region into the Add drillthrough fields here area.
The moment you do this, two things happen. Power BI automatically creates a Back button in the top-left corner of the page. And any visual on any other page that contains the Region field will now offer your Region Detail page as a drillthrough target when a user right-clicks.
Tip: You can add multiple fields to the drillthrough well. This is useful when you want to support drillthrough from more granular data points — for example, adding both
RegionandCategoryallows drillthrough from a matrix cell that shows a specific region/category combination. But be careful: adding a field to the drillthrough well doesn't mean it's required for drillthrough to trigger. The page becomes available as a drillthrough target from any visual containing any of the fields in the well.
Now build the actual content. Here's a layout that works well for a region detail page:
Header section: A card visual showing Region (the dimension itself) so users can immediately confirm what context they're viewing. Add a second card for Total Revenue (your revenue measure) and a third for Total Orders.
Top performers section: A horizontal bar chart showing Revenue by SalesRepName, sorted descending. Another horizontal bar chart showing Revenue by ProductName, top 10 by value.
Customer breakdown: A clustered bar showing Revenue by CustomerName, again top 10.
Transaction detail: A table visual with OrderDate, SalesRepName, ProductName, CustomerName, Quantity, and Revenue — ordered by OrderDate descending.
All of these visuals will automatically be filtered to the Region value passed via drillthrough. You don't need to add any page-level filters manually. The drillthrough mechanism handles it.
Go back to your summary page. Right-click on one of the region bars in your bar chart. You should see a Drillthrough option in the context menu with Region Detail listed underneath it. Click it.
You should land on your Region Detail page with all visuals scoped to that specific region. Check the filter pane — you'll see a page-level filter applied for Region equal to the value you clicked.
Warning: If the drillthrough option doesn't appear when you right-click, there are three common causes. First, the field in your source visual and the field in the drillthrough well might be from different tables that aren't related — check your model relationships. Second, the field in the source visual might be a measure rather than a dimension — drillthrough works on dimension values, not measure results. Third, you might have the source visual selected (clicked on the visual itself, not a data point within it) rather than right-clicking on an actual bar or data point.
Power BI auto-generates a back button the moment you add a field to a drillthrough well. It's functional, but it's styled with a default arrow icon that often doesn't match your report's design language. Here's how to handle it properly.
The auto-generated back button uses the Back action type. When a user clicks it, Power BI navigates to the page they came from — not a fixed destination, but literally the previous page in the navigation stack. This is important because your drillthrough page might be reachable from multiple source pages, and the back button correctly returns users to whichever page they came from.
This is different from a Page navigation button action, which would send users to a hardcoded page regardless of how they got there. For drillthrough back navigation, you almost always want the Back action, not page navigation.
Select the auto-generated back button. In the Format pane, you can change the fill color, border, shape, icon, and text. A common pattern is to replace the default arrow icon with a styled button that matches your report's color scheme.
To add text alongside the icon: in the Format pane, expand Button text and enable it, then type something like "← Back to Summary." This gives users clear affordance without relying on icon recognition alone.
If you want to replace the back button entirely with a custom bookmark-driven button (for example, because you have a more complex navigation flow), the approach is covered in depth in the advanced navigation patterns article. For straightforward drillthrough scenarios, the auto-generated button with custom styling is usually the right choice.
Tip: Resist the urge to delete the auto-generated back button and rebuild it from scratch as a page navigation button. If your drillthrough page is accessible from three different summary pages, a hardcoded page navigation button will send users back to the wrong page two-thirds of the time. The Back action type handles this correctly without any extra configuration.
Place your back button in a consistent location across all drillthrough pages in your report — typically the top-left corner or within a dedicated navigation header band. If you're building multiple drillthrough pages, users expect the back button to be in the same spot on each one.
If you've built a consistent header bar across your report using themes and template files, you'll want the back button to live within that header rather than floating freely on the canvas.
The basic drillthrough setup gets you far, but production reports usually require finer control over what context gets passed and how.
By default, drillthrough passes only the filter context from the clicked data point. If a user has applied slicers on the source page — say, filtering to Q3 only — those slicer selections are not carried forward to the drillthrough page by default.
This is the right default behavior in many cases. The drillthrough page is meant to show the complete picture for that dimension value, not an arbitrary slice of it. But sometimes you genuinely want slicer context to carry forward. A user filtering to a specific date range and then drilling into a region should probably see the regional detail within that same date range.
To enable this, look at the drillthrough well on your destination page. There's a toggle labeled Keep all filters (in some versions shown as a switch within the Drillthrough area of the Visualizations pane). Turn it on.
With this enabled, all active filters from the source page — slicers, visual-level filters, page-level filters — travel with the user to the drillthrough page in addition to the dimensional context of the clicked data point.
Warning: "Keep all filters" sounds appealing but can produce surprising results. If a user has multiple slicers active on the source page, all of them carry forward. If those slicers filter on fields that are also relevant to your drillthrough page's visuals, you might inadvertently show an empty page or highly filtered results that confuse the user. Test this behavior explicitly with combinations of slicer states before shipping a report with Keep All Filters enabled.
Sometimes you want to let users drillthrough to a detail page without clicking a specific data point — essentially an "all regions" or "all products" view using the drillthrough layout. This is called all-up drillthrough, and it's controlled by a toggle.
In the drillthrough well area on your destination page, you'll see an option that says When used as tooltip, show data from all data in current page context or similar wording depending on your version. More relevant is the toggle that appears in the drillthrough field well labeled Keep all filters — but the all-up behavior is enabled differently.
To support drillthrough from a visual that shows an aggregate (not broken out by your drillthrough field), your destination page needs to be accessible from top-level visuals. In practice, this means the field in your drillthrough well should be a field that exists somewhere in the model context of the source visual, even if it's not explicitly shown as an axis or legend.
For true "all-up" access — navigating to a drillthrough page without any filter applied — most practitioners use page navigation buttons instead of drillthrough. Drillthrough is designed for filtered context; if you want an unfiltered detail page, a regular navigation button is the cleaner tool.
When you add multiple fields to the drillthrough well, the page becomes accessible from visuals that contain any of those fields. The filter context that arrives includes the values for whichever of those fields were present in the source visual.
A practical example: Your drillthrough well contains both Region and Category. If a user drills through from a visual that only shows Region, the page receives a Region filter but no Category filter — so all category data shows up within that region. If they drill through from a matrix with both Region and Category visible, both filters arrive.
This creates a single detail page that can serve multiple use cases. The Region card at the top of your detail page will show the region value; the category breakdown will either be filtered or unfiltered depending on where the user came from. Build your visuals to be meaningful in both states.
Your drillthrough page isn't just a visual canvas — it's a filter context, and DAX measures evaluate within it. Understanding DAX's context transition and CALCULATE helps you build measures that communicate the drillthrough context explicitly.
Here are some measures worth including on your drillthrough pages:
A context-aware title measure:
Drillthrough Region Label =
VAR CurrentRegion = SELECTEDVALUE(Dim_Region[Region], "All Regions")
RETURN
"Detail View: " & CurrentRegion
Drop this into a card visual to show a dynamic title that reflects the current filter context. If the page is accessed with a Region filter applied, it shows the region name. If somehow accessed without context, it shows "All Regions" as a fallback.
Period comparison that respects drillthrough context:
Revenue vs Prior Period =
VAR CurrentRevenue = [Total Revenue]
VAR PriorRevenue = CALCULATE([Total Revenue], DATEADD(Dim_Date[Date], -1, YEAR))
VAR Variance = CurrentRevenue - PriorRevenue
RETURN
IF(ISBLANK(PriorRevenue), BLANK(), Variance)
This measure works correctly within drillthrough context because [Total Revenue] itself respects whatever filter context is active — including the drillthrough filter. The region filter applied by drillthrough scopes Total Revenue to that region, and DATEADD handles the prior period comparison within that scope. This builds on the time intelligence patterns you'd use anywhere else in the model.
Rank within drillthrough context:
Sales Rep Revenue Rank =
RANKX(
ALL(Dim_SalesRep[SalesRepName]),
[Total Revenue],
,
DESC,
DENSE
)
This ranks each sales rep by revenue. Within a drillthrough page filtered to a specific region, ALL(Dim_SalesRep[SalesRepName]) removes the row context filter from the rep dimension while respecting the page-level region filter — so you get ranking within the region, not globally. This is exactly the kind of nuance that separates a well-considered detail page from a generic dump of data.
Key insight: DAX measures on drillthrough pages don't need special treatment — they already operate within the filter context that drillthrough provides. The power comes from writing measures that are intentionally useful at the grain of your drillthrough context, not just measures copied from your summary page.
Single-report drillthrough is powerful, but cross-report drillthrough unlocks a different level of architecture: you can build a central detail report and let any summary report across your organization link into it. This is particularly valuable in organizations where different teams own different reports but share a common semantic model.
Cross-report drillthrough requires that both the source report and the destination report connect to the same dataset (semantic model) in Power BI Service. They don't need to be in the same workspace, though permissions need to allow access.
The destination report's drillthrough page is configured exactly the same way as a within-report drillthrough page — you add fields to the drillthrough well. The difference is on the source report's side, where you enable the cross-report drillthrough option.
In the source report, go to File > Options and settings > Options > Current File > Report settings. Enable Allow visuals in this report to use drillthrough targets from other reports.
Now, when a user right-clicks on a data point in the source report, the context menu will show drillthrough targets from other reports that share the same dataset and have compatible drillthrough fields configured — provided those other reports are published to Power BI Service and the user has access to them.
The destination report's drillthrough page needs no special cross-report configuration. The same field in the drillthrough well that enables within-report drillthrough also enables cross-report drillthrough. The only requirement is that the report is published to Power BI Service and accessible to the user navigating from the source report.
Note: Cross-report drillthrough only works in Power BI Service, not in Power BI Desktop preview mode. When testing cross-report drillthrough, you need to publish both reports and test them in the browser. Don't expect to see cross-report targets when previewing in Desktop.
Here's where cross-report drillthrough has a meaningful gotcha: the Back button's behavior changes. When navigating within a single report, the Back button returns users to the previous page in that report. In cross-report drillthrough, the Back button attempts to return users to the source report — which means it triggers a cross-report navigation in reverse.
This works when the user's browser handles it correctly, but it can sometimes produce unexpected results depending on how the reports are embedded or accessed. Test this explicitly in your production environment before shipping it to users.
If Back navigation in cross-report scenarios is unreliable in your environment, consider replacing the auto-generated back button with explicit copy of the destination context (showing "You came from: Southeast Region summary" as a text card) and instructing users to use browser navigation.
A pattern that works well in enterprise settings: build one canonical Detail Hub report that contains all your drillthrough destination pages — customer detail, product detail, region detail, rep detail. Publish it to a shared workspace. Then configure every summary report across the organization to point to this hub.
The benefits compound quickly. When you improve the detail pages, every report in the organization benefits immediately — no need to update drillthrough pages in dozens of separate files. Your detail hub can have its own row-level security applied independently, so users only see data they're authorized for regardless of which summary report they drilled from.
This architecture pairs naturally with Power BI deployment pipelines — you can promote the detail hub through dev/test/production stages independently of the summary reports that link to it.
Technical correctness is necessary but not sufficient. The difference between a drillthrough page that gets used and one that gets ignored is almost always design and clarity.
The very first thing a user should see when landing on a drillthrough page is confirmation of what context they're in. A large, prominent card showing the dimension value ("Southeast Region") at the top of the page eliminates the "wait, where am I?" confusion.
Pair this with a subtitle that shows the filter's origin: "Drillthrough from Sales Summary" or similar. This can be a static text box — you don't need DAX for it since the page name and its position in the navigation hierarchy usually communicates this. But a dynamic card using SELECTEDVALUE() as shown earlier is more professional.
A drillthrough page should show information that's genuinely more granular or differently organized than the source page — not just the same charts with a filter applied. If your source page shows revenue by region, your drillthrough shouldn't show revenue by region again (filtered to one region — that's just a bar chart with one bar). Show revenue by sales rep, by product, by customer, by week. Descend to the next level of detail.
Think about what question the user was implicitly asking when they drilled through. "Why is Southeast underperforming?" means they want to see the breakdown — who, what, when — not a smaller version of the same chart they just left.
A drillthrough page with fifteen visuals is overwhelming. Target four to six high-signal visuals plus a transaction-level table for users who want to go all the way to the row level. Prioritize: what are the two or three questions this page must answer? Build those first.
For visual variety and layout techniques that work well in detail pages — particularly using small multiples and custom tooltips — the advanced charts and custom formatting article has useful patterns. You might also consider pairing your drillthrough pages with tooltip pages so users get a preview of detail before deciding to drill through.
Let's build a three-page drillthrough system using realistic sales data. You'll create a summary page, a region detail page, and a product detail page — with the back button configured and context labels working.
Setup: Use the AdventureWorks or Contoso sample dataset, or any sales dataset with at least a date dimension, a geography/region dimension, a product dimension, and a sales fact table.
[Territory] or [Region] from your geography table into the Drillthrough field well.SELECTEDVALUE(DimGeography[SalesTerritoryRegion], "All Regions") — this is your context header[Total Sales] — shows total revenue in context[Total Sales] by [ProductCategoryName], sorted descending[Total Sales] by [SalesPersonName], top 10, sorted descendingOrderDate, CustomerName, ProductName, SalesAmount — sorted by OrderDate descending[ProductCategoryName] to the drillthrough field wellSELECTEDVALUE(DimProduct[ProductCategoryName], "All Categories")[Total Sales][Total Sales] by [ProductSubcategoryName][Total Sales] by [OrderDate] (month level) — shows trend within this categoryProductName, Total Sales, Total Orders sorted by Total Sales descending[Total Sales] by [SalesTerritoryRegion][Total Sales] by [ProductCategoryName]Add this measure to your model:
Context Header =
VAR SelectedRegion = SELECTEDVALUE(DimSalesTerritory[SalesTerritoryRegion])
VAR SelectedCategory = SELECTEDVALUE(DimProduct[ProductCategoryName])
RETURN
SWITCH(
TRUE(),
NOT ISBLANK(SelectedRegion), "Region: " & SelectedRegion,
NOT ISBLANK(SelectedCategory), "Category: " & SelectedCategory,
"All Data"
)
Place this in a card visual on both detail pages. It shows a human-readable summary of which filter context is active, which helps when both fields might be set simultaneously.
"Drillthrough option doesn't appear in the context menu"
The most common cause is a missing or broken relationship between the table containing your drillthrough field and the table containing the field shown in your source visual. Check the model view — trace the relationship path from your source field to the field in your drillthrough well. If there's no path, the drillthrough association can't be made. The Power BI relationships guide explains how to diagnose relationship issues.
Another cause: right-clicking on a measure value rather than a dimension value. Drillthrough is triggered by dimension context, not measure values. If you're clicking on a KPI card or a measure-only visual, there's no dimensional context to pass.
"My drillthrough page shows all data, not filtered data"
This means the filter isn't arriving correctly. Check that the field in your drillthrough well exactly matches (same table, same column) the field that appears in the source visual. If you've added a calculated column with the same name in a different table, Power BI might not recognize them as the same field for drillthrough purposes.
Also verify the page is actually receiving the filter: open the Filter pane while on the drillthrough page after navigating there. You should see a page-level filter applied. If you don't see it, the drillthrough field well configuration isn't matching the source field.
"The back button sends me to the wrong page"
This happens when someone has replaced the auto-generated back button with a Page Navigation button. Check the button's action type in the Format pane — it should be Back, not Page navigation. If it's set to page navigation pointing to a specific page, change it to the Back action type.
"Cross-report drillthrough doesn't appear as an option"
Confirm that both reports are published to Power BI Service (not just Desktop), that both connect to the same dataset, and that the source report has Allow visuals to use drillthrough targets from other reports enabled in its options. Also confirm that the logged-in user has access to the destination report — if they can't access it, it won't appear as a drillthrough target.
"My detail page has visuals showing BLANK after drilling through"
This usually means the drillthrough filter is applying correctly, but there's no data matching that combination in the fact table. Check your data first — if the region genuinely has no transactions for certain measure combinations, BLANK is the correct result. If you expect data but see BLANK, check whether the filter being applied is at the right granularity. Using HASONEVALUE() in a conditional measure can help distinguish "filtered to one value with no data" from "not filtered at all."
Tip: During development, temporarily make your drillthrough page visible (turn off Hidden) and navigate to it directly from the tab. Then open the Filter pane to see what page-level filters are active by default (none). This helps you establish a baseline and understand what changes when drillthrough context arrives.
Drillthrough pages, when built well, are one of the most valuable tools in a Power BI report's UX arsenal. You've now seen the full picture: how filter context is passed and controlled, how to build destination pages that are genuinely useful rather than just filtered duplicates, how to configure back navigation that works correctly across all source pages, and how to extend the pattern across report files with cross-report drillthrough.
The mental model to carry forward: drillthrough is a contextual filter delivery mechanism. Your destination page is built to receive a specific kind of filter context, show data within that context meaningfully, and return users cleanly to where they came from. Every design decision flows from that model.
Where to go from here:
Drillthrough is the feature that turns a reporting dashboard into a genuine analytical tool. Get it right, and users stop asking you to build new views — they start finding answers themselves.