Join us at FabCon Atlanta from March 16 - 20, 2026, for the ultimate Fabric, Power BI, AI and SQL community-led event. Save $200 with code FABCOMM.
Register now!The Power BI Data Visualization World Championships is back! Get ahead of the game and start preparing now! Learn more
Hi, I have a Matrix which displays data from "Availability Sheet", however I want to filter (via slicer) based on values from another table. So since these 2 tables have repeating 'Full Name' values, I have created a lookup table ("FullNames") with unique list of name values from both of these tables. Then I create 1:* relationships from look up table to both of my other tables.
However, when I try to filter my matrix by data from Advanced table, it does not works.
However, as soon as I do FullName to Advanced relationship Bidirectional is immediately works again. What could I be missing here? Or in this scenario since my filtered data flows from Advanced table, I do in fact need bidirectional relationship? I read that it's a good practice to avoid using Bidirectional so I am trying to do that.
Hi @Aliceeee,
Why the slicer does not work with single-direction relationships
Filtered Measure =
CALCULATE(
[Your Existing Measure],
TREATAS(
VALUES('Advanced'[Full Name]),
'Availability Sheet'[Full Name]
)
)
If this response was helpful in any way, I’d gladly accept a 👍much like the joy of seeing a DAX measure work first time without needing another FILTER.
Please mark it as the correct solution. It helps other community members find their way faster (and saves them from another endless loop 🌀.
With *single-direction (1 → ) relationships, filters only flow from the lookup table down to the fact tables, not from one fact table to another. When you put a slicer from Advanced, that filter cannot travel back up to FullNames, and therefore cannot reach Availability. That’s why your matrix doesn’t react.
The recommended pattern is keeping relationships single direction and put slicers on the lookup table, not on fact tables.
If you insist on using a slicer from Advanced table, keep your single relations instead creating bi-directional relations and use a measure four your specific case:
Availability (Filtered) =
VAR SelectedNames =
VALUES ( Advanced[Full Name] )
RETURN
CALCULATE (
[Availability Base Measure],
TREATAS ( SelectedNames, Availability[Full Name] )
)
Bidirectional relationships are risky because they let filters flow both ways, which can create ambiguous filter paths, unexpected results, and harder-to-debug reports. They can also hurt performance, especially in larger models, because Power BI has to resolve more complex filtering logic.
Hii @Aliceeee
With single-direction relationships, filter flow only travels from the lookup (dimension) table to the fact tables, not between fact tables. In your model, the slicer is coming from the Advanced table, so its filter cannot propagate through the FullNames lookup to the Availability Sheet. When you switch to bidirectional, Power BI allows that fact-to-fact filter flow, which is why it works. To keep single direction (best practice), create the slicer from the FullNames lookup table or use a measure with TREATAS() to explicitly pass the filter from Advanced to Availability.
Thanks! The TREATAS option indeed worked. Then slicer from the FullNames lookup table didn't make sense to me as I don't want to filter based on name, but perhaps I misunderstood your idea.
How do I mark answer as solved? I click 3 dots next to your post but such option does not exist.
Hi @Aliceeeee
you can get the option like below , so you can accepte the users response as a solution. If you don’t see it, please try opening it in another browser or in a new window.
The Power BI Data Visualization World Championships is back! Get ahead of the game and start preparing now!