Single versus bidirectional filtering in Power BI

Filter direction determines which way a relationship propagates a filter. In a typical star schema, a dimension filters its related fact table. Turning on both directions allows filters to travel back through that relationship as well, which can change slicers and create additional paths through a larger model.

Choose direction to support a defined analytical requirement. A slicer that does not shrink is not automatically evidence that every relationship should become bidirectional.

Trace a product filter in a small model

Build the retail lab model with single-direction relationships from DimProduct and DimCustomer to FactSales. Add a product-category slicer, a customer-region slicer and the Paid Net Paise measure from the star-schema lesson.

Selecting Software filters FactSales to software lines. The paid measure becomes 39,000 paise. Customer 1 contributes 19,000 and customer 2 contributes 20,000.

Under the ordinary single-direction paths, that filtered fact population does not automatically filter back into DimCustomer. The region slicer can continue offering regions without software activity. This is consistent with the model's filter direction.

Microsoft describes cross-filter direction and cardinality options in its relationship documentation.

Separate slicer presentation from measure correctness

If a reader selects South together with Software, there are no matching software lines for South in this fixture. A blank result can be correct even though both slicer choices were available.

Decide whether the interface should permit that combination, visually indicate no data or restrict slicer items to those with relevant activity. That is a report-design requirement, not proof of a broken sales measure.

For a targeted slicer behaviour, consider a visual-level measure filter appropriate to the intended population before changing model-wide propagation. Test whether it should reflect all transactions or only Paid activity; those choices differ in the fixture because South has a pending support line.

Explore bidirectional propagation in a copy

In a working copy, change the customer relationship to both directions. A product filter can now reach FactSales and then propagate toward DimCustomer through that relationship, subject to the complete model and query context.

Observe the customer slicer and a customer-count measure under Software. Compare them with the single-direction model. Record every relationship setting and visual filter so the result is reproducible.

This is an application experiment, not an executed Power BI result supplied by the lab. Its CSV and SQLite controls establish the eligible fact records; they do not evaluate the semantic model's filter propagation.

Watch for unintended paths

In a larger model with several fact tables sharing dimensions, reverse propagation can let one fact's activity constrain another fact's population through a shared dimension. That may be intended, or it may produce confusing totals and slicer interactions.

Draw the possible filter paths before enabling both directions. If several paths can reach the same table, inspect ambiguity and the engine's relationship rules. A local fix for one visual can affect other pages that use the same semantic model.

Use the narrowest model or measure change that satisfies the requirement, and document why it is needed. Avoid making every relationship bidirectional as a general setup step.

Treat security filtering as a separate review

Ordinary visual filtering is not a substitute for row-level security. Security propagation has its own configuration and permission context. A region slicer that hides values does not prevent an authorized query from accessing them under another view.

When a model uses RLS, review filter-path changes against role tests and real consumer permissions. Do not infer security from the appearance of a report while viewing it as the model author.

Build a regression matrix

Test no selection, one product, one region, combined selections, an empty combination and the explicit Unknown customer member. Verify paid totals and the intended slicer behaviour for each state.

For this fixture, Software totals 39,000 and Software plus North totals 19,000. Software plus South has no matching lines. These fact-level expectations help distinguish a correct empty result from an unintended model filter.

Exercise: add a second fact table of customer support tickets. Describe how a product selection should or should not affect ticket counts, then choose filter paths that implement that requirement without accidental cross-filtering.

NeuraPath's Data Analytics with Generative AI course connects Power BI interactions with model reasoning. A strong report explains where filters travel and proves that a change for one visual does not distort another.

Continue learning

This article is part of the Power BI data models and reporting sequence. Use the neighbouring tasks when you need the prerequisite or the next application.

• Review the prerequisite or neighbouring task in Power BI relationship cardinality with a duplicate-key example.
• Continue with Build a proper date table for business reporting.