Stop treating Power BI reports as isolated artifacts. This lesson teaches you how to design cross-report drillthrough and shared bookmark strategies that turn your entire report collection into a connected analytical ecosystem — with context flowing seamlessly between reports, teams, and data domains.
Picture this: your organization has a Sales Performance report, a Customer Analytics report, an Inventory report, and a Finance dashboard — each built by a different team, each sitting in its own workspace silo. A regional sales manager clicks on the Northeast territory in the Sales Performance report, sees something alarming in the revenue trend, and wants to dig into the underlying customer churn data. But that data lives in a completely different report. So she opens a new browser tab, navigates to the Customer Analytics report, remembers what she was filtering for, manually applies the same filters, and finally finds what she needed — three minutes and four clicks later. That friction compounds thousands of times a day across your enterprise, and it erodes trust in the entire BI ecosystem.
Cross-report drillthrough and shared bookmark strategies solve this problem at the architectural level. Instead of treating each Power BI report as an isolated artifact, you design them as nodes in a connected graph — where context flows between reports seamlessly, where a manager can move from a high-level KPI card straight into a granular transaction-level view in another report, carrying full filter context with her. By the end of this lesson, you'll be able to design and implement that connected experience, and you'll understand exactly why each piece works the way it does.
What you'll learn:
You should be comfortable with:
Before you build anything, you need a clear mental model of the mechanism. Single-report drillthrough — which you're probably already using — works by marking a report page as a drillthrough target and declaring which fields act as drillthrough filters. When a user right-clicks on a visual and chooses drillthrough, Power BI passes the current filter context from that visual to the target page.
Cross-report drillthrough does the same thing, but it allows the target page to live in an entirely different report file. The filter context crosses the report boundary. Mechanically, Power BI serializes the drillthrough filter state and passes it as part of the navigation event. The destination report then applies those filters to its own data model.
Here's the critical architectural constraint: the fields used as drillthrough filters must exist in both the source and destination data models. This doesn't mean both reports need to use the same dataset — but it does mean the field names must match exactly. In practice, this is a strong argument for using a shared dataset (a certified or promoted dataset published to a workspace) as the foundation for both reports. When two reports connect to the same shared dataset, you're guaranteed field name compatibility, the relationships are identical, and you get the added benefit of a single refresh schedule.
Important: Cross-report drillthrough requires that users have at least Read access to the destination report. If a user can see the source report but not the destination, they'll receive an error when attempting the drillthrough. Plan your workspace permissions accordingly.
The feature must also be explicitly enabled on the destination report. Navigate to File > Options and settings > Options > Current file > Report settings, and check "Allow visuals in this report to use drillthrough targets from other reports." This is a per-report setting that you configure in Desktop before publishing.
Let's work with something real. You're the BI architect for a retail company. You have three reports:
All three reports connect to a single shared dataset called RetailCore_Certified, published in the Enterprise Analytics workspace. The shared dataset includes tables for Sales, Customers, Products, Stores, Date, and bridge tables connecting them.
The cross-report drillthrough flow you want to enable:
This is a real interconnected ecosystem. Let's build it.
Open Product Operations Report in Power BI Desktop. You're going to create a dedicated drillthrough target page called Category Detail - Drillthrough.
Step 1: Create the page and configure it as a drillthrough target.
Add a new page and name it Category Detail - Drillthrough. In the Visualizations pane, you'll see the "Drillthrough" section at the bottom. This is where you define which fields act as the drillthrough keys.
Drag Products[Category] from the Fields pane into the "Add drillthrough fields here" well. This tells Power BI: "When a user drills through to this page using Category as context, apply that category filter to this page."
Step 2: Enable cross-report drillthrough on this page.
With the drillthrough page selected, look at the Drillthrough section in the Visualizations pane. You'll see a toggle labeled "Cross-report." Turn this on.
Why does this toggle exist? It's a security and intentionality gate. A report author has to explicitly declare that this page can receive context from external reports. This prevents arbitrary cross-report navigation to pages that weren't designed to handle external filter context.
Step 3: Decide whether to keep all filters.
Below the cross-report toggle, you'll see "Keep all filters." When this is enabled, the destination page also inherits any report-level and page-level filters that were active in the source report at the time of drillthrough. When disabled, only the drillthrough key field filters are passed.
For our scenario, we want "Keep all filters" set to On for the Category drillthrough. If a director was looking at the Northeast region in the Executive Dashboard before drilling into Category, she probably wants the Category Detail to also be scoped to Northeast. The filter context makes the destination more useful, not less.
Step 4: Build meaningful visuals on the drillthrough page.
A drillthrough page that just shows a table of data is a wasted opportunity. Design it to answer the specific question someone would have when they arrive there.
For Category Detail - Drillthrough, add:
Total Units in Stock filtered to the drilled categoryInventory Level over the last 90 days using Date[Date] on X-axis and a measure on Y-axisSupplier Name, Lead Time (Days), Last Order Date, and Stockout Count (Last 90 Days) for products in that categoryThe back button in cross-report drillthrough has a subtlety worth understanding: it navigates back to the source report page, not just the previous page within the current report. Power BI handles this automatically when the drillthrough originated from another report. Don't suppress or remove the back button — it's often the only intuitive way for users to return to their starting context.
Now open Executive Sales Dashboard in Power BI Desktop.
Step 1: Enable the cross-report drillthrough feature for this report.
Go to File > Options and settings > Options > Current file > Report settings. Check the box labeled "Allow visuals in this report to use drillthrough targets from other reports." Save and close.
Step 2: Find the visual that will serve as the drillthrough source.
You have a clustered bar chart showing Sales Amount by Products[Category]. This is the natural launch point. A director sees that the Outdoor Furniture category is underperforming and wants to understand if it's an inventory or operations issue.
Right-clicking on a bar in this chart while in the Power BI service will show a "Drillthrough" submenu. For this to offer cross-report destinations, the destination report must already be published to the same workspace, and it must have at least one cross-report drillthrough page configured with Products[Category] as the drillthrough field.
Critical Workspace Rule: For cross-report drillthrough to work in the Power BI service, both reports must be in the same workspace. This is a hard constraint as of the current Power BI architecture. If your source and destination reports live in different workspaces, cross-report drillthrough will not surface as an option. This has significant implications for how you organize your enterprise workspace structure.
Step 3: Validate the connection after publishing.
Publish both reports to the same workspace. Open the Executive Sales Dashboard in the Power BI service. Right-click on any bar in the category chart. You should see a "Drillthrough" option that expands to show the destination report name and the specific page (Category Detail - Drillthrough).
If the drillthrough option doesn't appear, check:
Products[Category]) exists with the same exact name in the source report's data modelOne of the most powerful — and often overlooked — aspects of cross-report drillthrough is that your DAX measures in the destination report automatically respond to the filter context passed from the source. You don't need special measures for drillthrough scenarios. But you can write smarter measures that surface additional context.
Consider this measure in the Product Operations report:
Stockout Rate (Selected Category) =
VAR TotalDays =
CALCULATE(
COUNTROWS(
CROSSJOIN(
VALUES(Products[ProductKey]),
VALUES('Date'[Date])
)
),
DATESINPERIOD('Date'[Date], TODAY(), -90, DAY)
)
VAR StockoutDays =
CALCULATE(
COUNTROWS(Inventory),
Inventory[UnitsOnHand] = 0,
DATESINPERIOD('Date'[Date], TODAY(), -90, DAY)
)
RETURN
DIVIDE(StockoutDays, TotalDays, 0)
When this measure lives on a card visual on the Category Detail - Drillthrough page, and a user drills through from the Executive Dashboard with Category = "Outdoor Furniture" in context, Power BI applies that category filter before evaluating the measure. VALUES(Products[ProductKey]) in the CROSSJOIN will only return products in Outdoor Furniture. The Stockout Rate will be calculated specifically for that category.
This is filter context propagation working exactly as designed, and it means your destination report visuals are instantly relevant without any conditional logic.
Cross-report drillthrough handles the "I'm looking at X and want to dig into Y" use case. Shared bookmarks handle a different but equally important use case: "I found a meaningful view and want to share it with someone, or navigate back to it programmatically."
A bookmark in Power BI captures the state of a report page — which visuals are visible, what filter state is applied, which slicers are set, and what scroll position the page is at. Bookmark strategies in an enterprise context serve several functions:
In the Executive Sales Dashboard, go to View > Bookmarks pane. You'll see the Bookmarks pane open on the right side of your screen.
Create a scenario:
Click "Add" in the Bookmarks pane. Name this bookmark Northeast - Last Quarter.
Now do the same for Southeast - Last Quarter and West Coast - YTD.
These bookmarks capture the exact filter state. You can now create buttons on the report page that navigate to each bookmark, creating a guided analytical experience. Insert a button (Insert > Buttons > Blank), give it the text "Northeast Q4", and in the Format visual pane, under Action, set the type to "Bookmark" and select Northeast - Last Quarter.
Bookmark groups let you create toggle states — showing and hiding visuals like a tabbed interface. This is particularly useful when you want the same report page to serve multiple analytical perspectives.
Create two bookmarks on the Customer Deep Dive report:
View: Segmentation — Only the customer segmentation treemap is visible; the transaction table is hiddenView: Transaction History — The transaction table is visible; the segmentation treemap is hiddenIn the Bookmarks pane, select both bookmarks, right-click, and choose "Group." Name the group Customer View Toggle.
Now create two buttons — "Segment View" and "Transaction View" — each linked to their respective bookmark. This gives users a clean, app-like navigation experience without the need for additional report pages.
Tip: When you create bookmarks intended for UI toggling, go into the bookmark options (the three dots next to each bookmark) and uncheck "Data." This makes the bookmark capture only the visual display state (visibility, position) and not the current filter/slicer state. That way, toggling between views doesn't reset whatever filter context the user has built up.
Here's where bookmark strategy intersects with cross-report connectivity. When you publish a report to the Power BI service, any named bookmark becomes accessible via URL parameter.
The format is:
https://app.powerbi.com/groups/{workspaceId}/reports/{reportId}/ReportSection{pageId}?bookmarkGuid={bookmarkGuid}
You can find the bookmark GUID by opening the report in the service, navigating to the bookmarked state, and copying the URL from the browser address bar after applying the bookmark.
This URL can then be used as the action target for a button in another report. In the Executive Sales Dashboard, you might have a button labeled "View Customer Segment Analysis" that opens the Customer Deep Dive report at the Segment Overview bookmark state — bypassing the default landing page and taking the user directly to the right analytical starting point.
To implement this as a button action:
A dynamic URL measure is more powerful. Here's an example:
Customer Deepdive URL =
"https://app.powerbi.com/groups/a1b2c3d4-workspace-id/reports/e5f6g7h8-report-id/ReportSectionCustomerOverview?bookmarkGuid=xyz123-bookmark-guid"
If you want to pass a dynamic filter (like the selected region), you can append filter parameters to the URL:
Customer Deepdive URL (Dynamic) =
VAR SelectedRegion = SELECTEDVALUE(Stores[Region], "All")
VAR BaseURL = "https://app.powerbi.com/groups/a1b2c3d4/reports/e5f6g7h8/ReportSectionCustomerOverview"
VAR FilterParam =
IF(
SelectedRegion <> "All",
"?filter=Stores/Region eq '" & SelectedRegion & "'",
""
)
RETURN BaseURL & FilterParam
Warning: URL filter parameters use the OData filter syntax and are case-sensitive. The table name and column name must match exactly as they appear in the dataset. Test each URL construction carefully in an incognito browser window before deploying to production.
Building the technical connections is only half the job. The other half is making sure they don't break when report authors make changes.
As mentioned earlier, cross-report drillthrough only works within the same workspace. This constraint has a meaningful impact on how you organize workspaces.
A common enterprise pattern is to structure workspaces by domain, not by team or department. So instead of:
You'd structure as:
Reports that need to drillthrough to each other must coexist in the same workspace. This might require renegotiating ownership boundaries between teams, but it's the right architectural call.
All reports in your cross-report ecosystem should ideally connect to the same shared certified dataset. In the Power BI service, open the dataset's settings and note which reports are connected to it (visible in the dataset's lineage view).
When the dataset schema changes — a column renamed, a table added — you need to validate all connected reports simultaneously. The Power BI Impact Analysis feature (accessible from the dataset in the workspace view) shows you all dependent reports and dashboards. Before any breaking schema change, run Impact Analysis and notify the owners of each downstream report.
In an interconnected report ecosystem, you can't deploy reports independently without risk. If you update the Category Detail - Drillthrough page in the Product Operations report — renaming it, changing the drillthrough field, or removing the cross-report toggle — the source report's drillthrough link breaks silently. Users don't get an obvious error; the drillthrough option simply disappears.
Use Power BI deployment pipelines (Development > Test > Production) and deploy interconnected reports in the same pipeline batch. Document the drillthrough contracts between reports — what field name is the drillthrough key, what the destination page is named — in a simple shared document or as embedded report descriptions in the service.
Now you're going to put this together from scratch. Use Power BI Desktop with the freely available Contoso dataset, or adapt your organization's own data.
Exercise Goal: Create a connected ecosystem where an executive can drill from a high-level Sales by Category view into operational inventory detail, and also jump to a curated customer analysis view.
Part 1: Destination Report Setup (30 minutes)
Open or create your Product Operations report connected to a shared dataset that includes Sales, Products, Inventory, and Date tables.
Add a new page named Category Ops Drillthrough. In the Drillthrough well, add Products[Category]. Enable the "Cross-report" toggle. Enable "Keep all filters."
On this page, add:
[Total Stockout Days] — create this measure as CALCULATE(COUNTROWS(Inventory), Inventory[UnitsOnHand] = 0)Products[ProductName], [Units In Stock], [Units Sold Last 30 Days]Publish this report to your target workspace.
Part 2: Source Report Configuration (20 minutes)
Open your Executive Sales Dashboard in Desktop.
Go to File > Options > Current file > Report settings. Enable cross-report drillthrough.
On your main KPI page, ensure you have a visual using Products[Category] — a bar chart of [Sales Amount] by Products[Category] works well.
Publish this report to the same workspace as the Product Operations report.
In the Power BI service, open the Executive Sales Dashboard. Right-click on a category bar. Verify that "Drillthrough > Category Ops Drillthrough" appears.
Part 3: Bookmark Navigation (20 minutes)
In the Executive Sales Dashboard (Desktop), open the Bookmarks pane.
Create three bookmarks representing three regions (filter the Region slicer to each, then add a bookmark: Region: Northeast, Region: Southeast, Region: West).
On the report page, add three blank buttons labeled "Northeast", "Southeast", "West". Set each button's action to Bookmark, pointing to the corresponding bookmark.
Create a fourth bookmark called Default View with no filters applied. Add a "Reset" button pointing to this bookmark.
Re-publish and test the navigation flow end-to-end in the service.
Part 4: Validation Checklist
This is the most common issue. Work through this checklist:
Products[Category] and the destination was accidentally configured with Product[Category] (singular), it won't match.The drillthrough is working (navigation is happening), but the visuals are empty. Most likely causes:
Products[Category] can only travel in the direction relationships allow. If the filter needs to go from Products to Inventory but the relationship only filters in the opposite direction, no data will show.If your toggle bookmarks are also resetting slicers unexpectedly, it's because the bookmark captured the full state including data/filter state. Go into each bookmark's options (three-dot menu in the Bookmarks pane) and uncheck "Data." Only "Display" should be checked for pure UI-toggle bookmarks.
The OData filter syntax used in URL parameters is strict. Common issues:
?filter=Stores/Region eq 'Northeast'Stores/Region, not Stores[Region]'North%20East' if the value contains a spaceThe user has access to the source report but not the destination. Cross-report drillthrough respects the destination report's own permission model — the user must have at least "Read" access to the destination report directly. Having workspace access is not sufficient if the report has been shared with specific permissions. Check the sharing settings of the destination report in the service.
You've now covered the full architecture of cross-report drillthrough — from the mechanical reality of how filter context crosses report boundaries, to the workspace governance decisions that make these connections sustainable at enterprise scale. You've also seen how bookmark strategies layer on top of this to give users intuitive navigation paths that feel like a coherent application rather than a collection of disconnected files.
The key mental shift is treating your report collection as an interconnected system, not a set of independent artifacts. Every report is both a potential source and a potential destination for context. Designing with that frame from the beginning — using shared datasets, consistent field naming conventions, and a thoughtful workspace structure — makes the technical implementations straightforward. The hard problems are organizational, not technical.
Deepen your skills with these next topics:
The interconnected report ecosystem you've built in this lesson is not just a UX nicety — it's an architectural pattern that reduces duplication, enforces consistent metrics definitions through shared datasets, and gives your organization a navigation model that scales as your BI footprint grows.