Cross-Filter Direction in Power BI: When Bidirectional Helps and When It Hurts

I can tell within the first few weeks of a cohort which students have hit a wall with relationships, because the question is always the same: "I filtered by Region, but this other visual isn't changing — why not?" The honest answer is almost always cross-filter direction, and almost as often, the fix a student reaches for — flipping the relationship to bidirectional — creates a new, harder-to-diagnose problem in its place. This is one of the modeling concepts PL-300 tests precisely because it's easy to get working by accident and hard to get working correctly.

What cross-filter direction controls

Every relationship between two tables in your model has a cross-filter direction, set on the relationship itself (double-click the line in Model view to see it). It answers one question: when a filter is applied on one side of the relationship, does it propagate to the other side?

• Single direction filters flow from the "one" side of a one-to-many relationship down to the "many" side. A filter on Date[Year] propagates to Sales, because Date is on the one side and Sales is on the many side. This is the default Power BI creates automatically, and it's correct for the overwhelming majority of star-schema relationships.
• Bidirectional (also called "both") lets the filter flow the other way too — from the many side back to the one side, and from there out to anything else connected to that dimension.

In a clean star schema — one fact table surrounded by dimension tables, each dimension connected only to the fact — single direction is enough for everything a report normally needs. A slicer on Product[Category] filters Sales just fine with a single-direction relationship, because Category lives on the one side and the filter only needs to travel one hop, downstream to the fact table.

Where single direction "breaks" (and why it's not actually broken)

The situation that confuses people is a snowflaked or multi-fact model. Say you have Sales and Sales[Product] and a separate Reviews table that also relates to Product, and you want a slicer on Reviews[Rating] to filter the Sales visuals. With single-direction relationships, that filter stops at Product — it doesn't continue upstream to Reviews, and it doesn't flow from Reviews through Product into Sales, because Reviews is on the many side relative to Product, and filters don't travel from the many side to the one side by default.

This isn't a bug. It's the model correctly refusing to guess. If Product has many Reviews rows, which rating should "count" when filtering back? Power BI won't invent an answer — it requires you to say explicitly how that ambiguity should resolve, which is exactly what turning the relationship bidirectional does.

What bidirectional actually costs you

Making a relationship bidirectional isn't free, and PL-300 expects you to know the trade-offs, not just the mechanism:

Ambiguity risk. The moment you have more than one path between two tables — which bidirectional relationships create easily in anything beyond a pure star schema — Power BI can refuse to create the relationship at all, or worse, silently pick a filter path you didn't intend. If you've ever seen the error "using this relationship could cause ambiguity," this is why.

Performance. Every additional direction a filter can travel is more work for the formula engine to resolve at query time. On a small model you'll never notice. On a large fact table with several bidirectional relationships feeding into it, this is a common, quiet cause of slow report load — one I've traced more than once in a client audit.

Unexpected results in unrelated visuals. Because a bidirectional relationship filters back through the dimension and out to anything else connected to it, a slicer you added for one visual can silently change totals in a visual that has nothing to do with what you were trying to filter. This is the trap: it "works" for the one case you tested and breaks something else you didn't.

-- Simulating bidirectional behavior deliberately, without
-- changing the relationship itself:
Reviews Affecting Sales =
CALCULATE(
    [Total Sales],
    CROSSFILTER(Sales[ProductKey], Product[ProductKey], BOTH)
)

CROSSFILTER inside CALCULATE is worth knowing precisely because it does this scoped, on purpose, for one measure — instead of making the relationship bidirectional for the whole model. If you only need the reverse-filtering behavior in one specific measure, this is almost always the better tool: it gets you the result without exposing every other visual in the report to the same ambiguity.

The many-to-many case is different

Not every bidirectional relationship is a mistake. A genuine many-to-many relationship — say, Students and Courses linked through an Enrollments bridge table, where a student takes many courses and a course has many students — often needs bidirectional filtering to behave the way the business actually expects: filtering by a course should show you the relevant students, and filtering by a student should show you their courses. Here, bidirectional isn't a workaround, it's the correct model of the real-world relationship. The distinction PL-300 wants you to make isn't "bidirectional bad, single direction good" — it's whether the bidirectional behavior reflects genuine two-way business logic, or whether it's patching around a star schema that was set up single-direction on purpose.

How PL-300 tests this

Expect scenario questions, not definitions. A typical setup describes a report where a slicer isn't affecting a particular visual, gives you the relationship layout, and asks which change fixes it — with "set cross-filter direction to Both" as one option among several (sometimes correct, sometimes a distractor next to a better answer like adding an explicit CROSSFILTER in a single measure, or restructuring the relationship instead of forcing bidirectional filtering across the whole model). You'll also see questions that describe symptoms of an ambiguity problem — an error creating a relationship, or a total that changes unexpectedly when a filter is added elsewhere — and ask you to identify the cause.

A practical rule of thumb

Default to single direction. Only make a relationship bidirectional when you can articulate, in one sentence, the real-world two-way relationship it represents — like the many-to-many enrollment example above. If you can't, and you just need one measure to filter back through a dimension, reach for CROSSFILTER inside that specific CALCULATE instead of changing the relationship for the entire model. That single habit will resolve most of the "why isn't this filtering" questions before they turn into "why did this other visual just change."