Data Filtering and Interactions

Power BI provides several layers of filtering, ranging from interactive UI controls to model-level security. Understanding each type helps you design reports that are both flexible and secure.

1. Visual-Level Filters

Visual-level filters apply only to a single visual. They are configured in the Filters pane under "Filters on this visual" and are invisible to report consumers unless the pane is exposed. They let you narrow a chart's data independently of what other visuals show — for example, limiting a bar chart to only the top 10 products without affecting a nearby table.

2. Page-Level Filters

Page-level filters apply to every visual on a single report page. Configured under "Filters on this page" in the Filters pane, they are useful when a page has a specific analytical focus — such as a page dedicated to a single region — that should constrain all visuals uniformly.

3. Report-Level Filters

Report-level filters apply across all pages in the report. Found under "Filters on all pages" in the Filters pane, they are appropriate for persistent constraints that the report author wants to enforce everywhere, such as excluding test accounts or limiting data to a specific fiscal year range.

4. Drillthrough Filters

Drillthrough filters are configured on a destination page by placing a field in the page's Drillthrough well. When a report consumer right-clicks a data point in a source visual and selects "Drill through," they are navigated to the destination page with that field's value automatically applied as a filter. This enables detail-on-demand patterns — for example, drilling from a summary sales page to a transaction-level detail page filtered to a specific customer.

5. Slicers

Slicers are on-canvas visual controls that allow report consumers to interactively filter data. Unlike Filters pane filters (which can be hidden or locked), slicers are visible and part of the report's user experience. They support list, dropdown, between (range), relative date, and tile/button styles. Slicers can be synced across multiple pages using the View > Sync slicers panel, so a selection on one page persists as the user navigates. Field parameter slicers (introduced in recent versions) allow consumers to switch which measure or dimension is displayed in a visual.

6. Cross-Filtering and Cross-Highlighting

When a consumer clicks a data point in one visual, Power BI by default applies that selection as a filter or highlight to other visuals on the page. Cross-filtering removes non-matching rows from other visuals; cross-highlighting shows all data but dims non-matching values. Report authors can configure this behavior per visual pair using Format > Edit interactions. Each visual can be set to filter, highlight, or receive no interaction from a selected source visual.

7. DAX-Based Filtering with CALCULATE

Inside DAX measures, filter context can be precisely manipulated using CALCULATE. The FILTER function lets you pass a table expression as a filter argument. ALL and ALLEXCEPT remove existing filters from a table or column, enabling totals and ratio-to-total calculations. REMOVEFILTERS is the modern equivalent of ALL when used solely for filter removal. These functions give measure authors full control over what data a calculation sees, independent of any slicers or Filters pane selections active in the report.

8. Row-Level Security (RLS) and Object-Level Security (OLS)

RLS is a model-level security filter that restricts which rows of data a user can see based on their identity. Static RLS roles use hardcoded DAX filter expressions (for example, [Region] = "West"). Dynamic RLS uses USERNAME() or USERPRINCIPALNAME() to compare the logged-in user against a mapping table, allowing a single role to serve all users without duplicating the report. OLS, available in Premium and Premium Per User capacities, goes further by hiding entire tables or columns from specific roles — users in those roles cannot see those objects at all, even in the field list. Both RLS and OLS are enforced at the semantic model level and cannot be bypassed through the report layer.

Managing data interactions in Power BI means controlling how visuals, pages, and navigation elements respond to user selections. Power BI offers multiple layers of interaction management, from simple cross-filtering to bookmark-driven storytelling.

Cross-Highlighting vs Cross-Filtering

By default, clicking a data point in one visual affects other visuals on the same page. Cross-highlighting shows all data in the affected visual but dims non-matching values, preserving context about the full dataset. Cross-filtering removes non-matching rows entirely, giving a stricter view of only the selected subset. To configure which behavior applies between two specific visuals, select the source visual, go to the Format tab, and click Edit interactions. Each other visual on the page shows icons letting you choose filter, highlight, or none for that pair. This per-pair configuration gives report authors precise control over the interaction graph.

The Three Interaction States

When Edit interactions is active, each visual pair can be set to one of three states:

1. Filter — the target visual is filtered to show only data matching the selection in the source visual.
2. Highlight — the target visual retains all its data but visually distinguishes matching values.
3. None — the target visual is unaffected by selections in the source visual.

Slicers and Sync Slicers

Slicers are on-canvas filter controls that propagate selections as filter context changes to all visuals on a page (unless a specific visual is excluded via Edit interactions). To make a slicer's selection persist as users navigate between pages, use the View > Sync slicers panel. This lets you mark which pages a slicer should apply to and whether the slicer control itself should be visible on each of those pages. Synced slicers avoid the need to duplicate the same slicer on every page and ensure consistent filter state across the report.

Drillthrough

Drillthrough enables context-sensitive navigation from a summary visual to a detail page. On the destination page, drag a field into the Drillthrough well in the Visualizations pane. Source visuals that contain that field then gain a right-click "Drill through" option. When a consumer uses it, they are taken to the destination page with the selected value applied as a filter. A back button is automatically added to the destination page to return the user to their origin. Cross-report drillthrough extends this pattern across separate reports in the same workspace, enabled in each report's settings.

Drill-Down Within a Visual Hierarchy

When a visual's axis or legend contains a hierarchy (such as Year > Quarter > Month), consumers can drill down to expand a single node into its children, or drill up to collapse levels. The visual toolbar shows expand/collapse arrows and a "Go to next level" button. This is a visual-level interaction that does not propagate as a filter to other visuals — it only changes the hierarchy level rendered in that visual.

Bookmarks

Bookmarks capture the complete state of a report at a moment in time: filter context, slicer selections, visual visibility, scroll position, and spotlight/focus state. Authors create bookmarks in the View > Bookmarks panel. They can be used to build curated narrative paths through the data, toggle between different views, or reset a page to a default state. Consumers interact with bookmarks through buttons or the Bookmarks navigator visual.

Buttons and Page Navigation

Buttons can be configured with actions including page navigation, bookmark navigation, drillthrough, Q&A, and URL navigation. Combined with bookmarks, buttons let authors build guided storytelling experiences where consumers follow a logical sequence through the report without needing to understand the full data model. The Selection pane controls visual layering and visibility, which can be toggled by bookmarks to show or hide entire groups of visuals.

Microsoft Fabric Integration

In Microsoft Fabric workspaces, Power BI reports can be embedded alongside Lakehouse, Warehouse, and other Fabric items. Report interactions in this context can propagate into Fabric-native experiences — for example, a filtered report view can inform which data a Fabric notebook or pipeline processes when the workspace is used for end-to-end analytics flows. DirectLake semantic models, which read directly from OneLake without importing data, are particularly sensitive to filter propagation because filters are pushed to the underlying storage layer at query time.

Slicers are one of the most important interactive elements in a Power BI report. They give report consumers visible, on-canvas controls for filtering data, and they play a central role in how filter context flows between visuals.

What Slicers Are

A slicer is a visual filter that applies to all other visuals on a page (or across synced pages). When a consumer makes a selection in a slicer, Power BI propagates that selection as a filter context change to every visual in scope. Unlike Filters pane filters — which can be hidden from consumers or locked by the report author — slicers are visible, interactive elements that are intentionally part of the report user experience and layout.

Slicer Types

Power BI supports several slicer styles, selectable through the visual formatting options:

1. List — displays distinct values as a scrollable list with checkboxes.
2. Dropdown — collapses the values into a compact dropdown control, useful when screen space is limited.
3. Between (range slider) — shows a numeric or date range slider, ideal for filtering by price range, date window, or other continuous values.
4. Relative date / relative time — filters to a rolling window such as "last 7 days" or "this month," dynamically recalculating relative to the current date.
5. Tile / button style — renders each value as a clickable tile or button, useful for a small set of categories like product lines or regions.

Sync Slicers Across Pages

By default, a slicer only filters visuals on the page where it lives. The View > Sync slicers panel lets authors extend a slicer effect to other pages in the report. For each page, you can independently control two settings: whether the slicer filter is applied to that page, and whether the slicer control itself is visible on that page. This means you can have a hidden slicer silently filter a page, or a visible slicer that reflects a selection made on another page. Sync slicers eliminate the need to duplicate slicer visuals across pages and ensure that a consumer selection persists as they navigate.

Single-Select vs Multi-Select

By default, slicers allow consumers to select multiple values simultaneously. Single-select mode (enabled in the slicer formatting options) restricts selection to one value at a time, which is useful when the report logic assumes a single filter value — for example, a parameter-driven title or a measure that references a single selected product. Consumers can also hold Ctrl to multi-select in list slicers when multi-select is enabled.

Slicers vs Filters Pane Filters

Slicers and Filters pane filters both apply filter context to visuals, but they serve different roles:

• Slicers are visible to consumers, part of the report layout, and intended for self-service filtering. They cannot be locked and their selections are always transparent to the user.
• Filters pane filters can be set at the visual, page, or report level. Report authors can lock filters (preventing consumers from changing them) or hide them entirely (preventing consumers from seeing them). This makes them suitable for author-imposed constraints rather than consumer-driven exploration.

Slicer Interactions with Other Visuals

A slicer selection propagates as a filter — not a highlight — to other visuals on the page. You can use Format > Edit interactions to exclude specific visuals from a slicer effect. For example, you might want a KPI card showing total company revenue to remain unfiltered while a chart below it responds to a region slicer.

Field Parameter Slicers

Field parameters, introduced in recent Power BI Desktop versions, allow report authors to create a parameter table where each row represents a measure or dimension. A slicer built on a field parameter lets consumers switch which measure (for example, Revenue vs Profit) or which dimension (for example, Category vs Sub-category) is shown on a visual axis or legend. This gives consumers a way to reshape the report analytical perspective without the author needing to build separate pages for each combination.

Complex filtering requirements in Power BI go beyond simple slicer selections. They involve DAX-level logic, security enforcement, cross-source model behavior, and dynamic user-driven analysis. The following techniques address these scenarios.

1. DAX Filter Context Manipulation with CALCULATE

CALCULATE is the primary function for overriding filter context inside a measure. It evaluates an expression in a modified filter context defined by its filter arguments. Key companion functions include:

• FILTER — passes a table expression as a filter, allowing row-by-row conditions that reference multiple columns.
• ALL — removes all filters from a table or specific columns, useful for computing grand totals or ratios.
• ALLEXCEPT — removes all filters from a table except for specified columns, preserving certain slicing dimensions while ignoring others.
• REMOVEFILTERS — the preferred modern function for clearing filters without a calculation side effect, equivalent to using ALL purely for filter removal.

These functions let measure authors precisely define what data a calculation sees, independent of what slicers or Filters pane selections are active in the report.

2. Row-Level Security (RLS)

RLS restricts which rows of data each user can see at the semantic model level. Two patterns are common:

• Static RLS — roles are defined with hardcoded DAX filter expressions such as [Region] = "West". Each role is assigned to specific users or groups in the Power BI service. Simple to set up but requires a separate role per distinct filter value.
• Dynamic RLS — a single role uses USERNAME() or USERPRINCIPALNAME() to compare the logged-in user against a mapping table in the model. The DAX expression might look like [Email] = USERPRINCIPALNAME(). This scales to any number of users without creating additional roles, and user access is managed by updating the mapping table rather than the role definitions.

RLS is enforced at query time on the Power BI service and cannot be bypassed through the report layer or by exporting data through standard report exports.

3. Object-Level Security (OLS)

OLS, available in Premium and Premium Per User (PPU) capacities, extends security to the schema level. With OLS, entire tables or individual columns can be hidden from specific roles. Users in those roles cannot see the hidden objects in field lists, cannot reference them in Q&A, and receive an error if a report visual tries to query them. OLS is configured in Tabular Editor or via the XMLA endpoint and is appropriate for sensitive columns such as salary, social security numbers, or proprietary cost data.

4. Composite Model Filtering

Composite models combine tables with different storage modes — Import (data cached in the model) and DirectQuery (queries sent to the source at runtime) — in a single semantic model. Filter propagation across storage mode boundaries requires care:

• By default, relationships between Import and DirectQuery tables use single-direction filtering to avoid ambiguity and performance issues.
• Bidirectional relationships in composite models can cause fan traps and incorrect aggregations; they should be used deliberately and tested carefully.
• When a slicer or visual filters an Import table that has a relationship to a DirectQuery table, Power BI must generate a query to the DirectQuery source, which affects performance and requires the source to support the filter pattern.
• DirectLake tables in Microsoft Fabric semantic models add a third storage mode that reads directly from OneLake delta tables, and filter propagation to DirectLake tables follows similar considerations as DirectQuery.

5. Drillthrough and Cross-Report Drillthrough

Drillthrough allows context-sensitive navigation from a summary visual to a detail page, passing the selected value as a filter. Cross-report drillthrough extends this across separate reports in the same workspace, enabled in each report settings. Both patterns are effective for handling requirements where a high-level report needs to surface transaction-level or record-level detail without embedding that detail on the summary page.

6. Field Parameters for Dynamic Axis and Measure Switching

Field parameters create a user-selectable list of measures or dimensions. A slicer built on a field parameter lets consumers switch what a visual is measuring or how it is sliced without the author building separate pages. This handles requirements where stakeholders want to compare multiple metrics or groupings in the same chart layout.

7. What-If Parameters for Scenario Analysis

What-if parameters create a numeric slicer and a corresponding DAX measure that returns the selected value. Measures can then reference that value to model scenarios — for example, calculating projected revenue at different discount rates or headcount growth assumptions. This is a lightweight alternative to embedding scenario logic directly in the data model.

8. XMLA Endpoint Queries for Complex Filter Scenarios

The XMLA endpoint exposes Premium and Fabric semantic models as an Analysis Services endpoint, allowing external tools such as DAX Studio, Tabular Editor, and custom applications to query the model using DAX or MDX. This is useful for diagnosing complex filter behavior — for example, using DAX Studio to run EVALUATE queries with specific filter contexts to verify that RLS, OLS, and measure logic interact as expected. It is also used by data engineering teams to programmatically manage model metadata, push data, and script complex partition refresh logic.

Setting up interactions between visuals is a core report authoring skill in Power BI. The platform provides a layered system that ranges from automatic default behavior to precisely configured per-visual interaction rules.

1. Default Behavior: Cross-Filter and Cross-Highlight

When a report consumer clicks a data point in any visual, Power BI automatically applies that selection to all other visuals on the page. Charts typically receive cross-highlighting by default — all data remains visible but non-matching values are dimmed. Tables and matrix visuals typically receive cross-filtering — non-matching rows are removed. This default behavior requires no configuration and works as soon as visuals share related fields through the model relationships.

2. Edit Interactions Mode

To customize how specific visual pairs interact, select a source visual (the one the consumer will click), then go to the Format tab in the ribbon and click Edit interactions. While Edit interactions is active, every other visual on the page displays a set of small icons in its upper-right corner. These icons let you set the interaction type for that specific pair. Changes are saved per visual pair and persist in the report.

3. The Three Interaction States

For each visual pair, you can choose one of three states:

1. Filter — the target visual is filtered to show only rows matching the selection in the source visual. Non-matching data is removed entirely.
2. Highlight — the target visual shows all of its data but visually distinguishes matching values (typically by dimming non-matching portions). This is the default for most chart types.
3. None — the target visual is completely unaffected by selections in the source visual. Use this to preserve a KPI card or reference visual that should always show the full dataset regardless of what the consumer clicks.

4. How Slicers Interact

Slicers always apply a filter interaction — they do not support highlight mode. When a consumer selects a value in a slicer, all visuals on the page are filtered by default. To exclude a specific visual from a slicer effect, select the slicer, enter Edit interactions mode, and set the interaction for that visual to None. This is commonly used to keep a totals card or a reference benchmark visual showing unfiltered data while the rest of the page responds to the slicer.

5. Sync Slicers Across Pages

A slicer only affects the page it lives on by default. To extend its effect to other pages, open the View > Sync slicers panel. For each page in the report, you can independently toggle whether the slicer filter is applied to that page and whether the slicer control itself is visible on that page. Syncing a slicer without showing it on a page creates a hidden filter — the page is filtered but the consumer does not see the slicer control there. Sync slicers ensure that a selection made on one page is honored as the consumer navigates to other pages.

6. Drillthrough Setup

Drillthrough creates a navigation path from a summary visual to a detail page, carrying filter context. To set it up:

1. Create a destination page intended for detail-level analysis.
2. In the Visualizations pane on that page, drag the field you want to drill on into the Drillthrough well.
3. Power BI automatically adds a back button to the destination page.
4. On any source page, visuals that contain the drillthrough field gain a right-click "Drill through" option. The consumer right-clicks a data point and selects the destination page name to navigate with that value applied as a filter.

The destination page can have its own visuals, filters, and layout — it only needs the drillthrough field in its Drillthrough well to receive the context.

7. Cross-Report Drillthrough

Cross-report drillthrough lets a consumer navigate from a visual in one report to a detail page in a different report within the same workspace. To enable it, go to File > Options and settings > Options > Current file > Report settings and enable "Allow visuals in this report to use drillthrough targets from other reports." The destination report must also have this setting enabled, and its drillthrough page must be configured with the same field in the Drillthrough well. This pattern is useful when detail data is managed in a separate report from summary data for governance or performance reasons.

8. Bookmarks and Buttons for Guided Interactions

Bookmarks capture the full state of a report at a moment in time, including filter context, slicer selections, visual visibility, and spotlight state. Authors create bookmarks in the View > Bookmarks panel. Buttons can be configured with a bookmark action so that clicking the button restores that captured state. Combined with the Selection pane (which controls which visuals are visible), bookmarks and buttons enable guided storytelling: authors can build flows where consumers step through curated views of the data, toggle between different chart configurations, or reset the page to a clean default state — all without needing to understand the underlying data model.