Data reduction behavior in Power BI

Applies to

• Power BI Desktop

• Power BI service

• Reports using Slicerbar or slicer-based custom visuals

Overview

When using SLICERBAR in large Power BI reports, you may encounter the following message:

Not displaying all data. Filter data or choose another field.

Open

This message indicates that Power BI has applied data reduction to the visual. Data reduction is a built-in mechanism used to maintain performance when a visual requests more data points than the platform allows.

This article explains why the message appears and provides recommended best practices for avoiding it when designing scalable Power BI solutions.

Why this message appears

Power BI enforces a data reduction algorithm on visuals to ensure acceptable performance and responsiveness.

Data reduction limit

• Each visual can request a maximum of 30,000 rows at a time.

• When a field used in a Slicerbar exceeds this limit, Power BI does not return all values.

• Instead, Power BI displays a warning indicating that not all data is shown.

This behavior is by design and applies to both built-in visuals and custom visuals, including Slicerbar.

Common scenarios

You are more likely to encounter this message when:

• Using high-cardinality fields (for example, Customer ID, Product ID, or Transaction ID)

• Allowing slicers to load without pre-filtering

• Designing reports for large or enterprise-scale datasets

• Combining multiple high-cardinality filters in a single Slicerbar

Recommended best practices

Create a date picker first when configuring your Slicerbars

Create your Date picker early in the report design process.

At this stage, the Date picker should reflect the complete date span, not a limited subset

Split filters across multiple Slicerbars

Instead of placing all filters into a single Slicerbar, create multiple Slicerbar visuals and distribute filters logically between them.

Example:

• Slicerbar 1: Geography (Region, Country)

• Slicerbar 2: Time (Year, Month)

• Slicerbar 3: Business attributes (Category, Segment)

This approach reduces the number of values each Slicerbar must process and helps ensure each visual remains below the 30,000-row limit.

Reduce data cardinality

Where possible, reduce the number of distinct values exposed to slicers.

Recommended approaches include:

• Using higher-level groupings instead of granular IDs

• Filtering to active or relevant records only

• Creating calculated columns that bucket or group values

• Avoiding free-form date/time fields when not required

Lower cardinality improves both performance and usability.

Use dependent or hierarchical filtering

Design slicers so that one selection reduces the available values of another.

Example workflow:

1. Region

2. Country (filtered by Region)

3. Customer (filtered by Country)

This ensures that high-cardinality fields are only evaluated after upstream filters significantly reduce the dataset.

Avoid transaction-level fields in slicers

Transaction-level fields are not suitable for slicers in large models.

Instead:

• Filter at an aggregated level

• Use drill-through pages for detailed analysis

• Provide search or detail views separate from slicers

What this message does not indicate

• It does not mean the dataset is too large to be loaded

• It does not indicate missing data in the model

• It does not affect calculations or measures outside the visual

The limitation applies only to the data returned to the visual.

Summary

The “Not displaying all data” message in Slicerbar visuals is caused by Power BI’s 30,000-row data reduction limit. This limit is enforced to protect performance and cannot be increased.

To avoid this behavior:

• Distribute filters across multiple Slicerbars

• Reduce the cardinality of slicer fields

• Design slicers to work hierarchically

• Avoid transaction-level fields in slicers

Following these best practices helps ensure Power BI reports remain performant, scalable, and user-friendly as data volumes grow.