Forum Discussion
Relationship between calculated table and Direct Query table not recognized
I have discovered that relationships are broken in some way between Direct Query tables and calculated tables, so I am unable to use the calculated table measure as a slicer to filter Direct Query data in the visuals.
While it is possible that converting or duplicating some of the Direct Query tables to Import mode would solve the broken relationship issue, the underlying problem I was trying to solve was to highlight SKU&Subsidiaries incorrectly marked as not replenishable. Since I am having so much trouble with the slicer, I have decided to focus on the more correct solution to this underlying problem, which is to work with the upstream data support teams to fix the source data.
Hi shadowsong42,
Thanks for the clarification—that makes your goal crystal clear. Since you’re aiming to use a Replenishable field in a slicer, a calculated measure won’t work, as slicers only operate on columns, not dynamic measures. You're absolutely right to pivot toward a solution that gives you a TRUE/FALSE value as a column, while still working within the constraints of your composite model and Direct Query setup.
A reliable way to achieve this is to create a calculated table that builds the Replenishable status based on actual (ProductID, SubsidiaryID) key combinations from your fact table. Instead of relying on concatenated keys or RELATED(), which can cause filter propagation issues in composite models, you can use LOOKUPVALUE() to directly check whether a given combination appears in your filtered set. This ensures compatibility with slicers and avoids the inconsistency you're seeing.
Replenishable =
SUMMARIZE(
ReplenishAll,
ReplenishAll[ProductID],
ReplenishAll[SubsidiaryID],
"Replenish",
IF(
NOT ISBLANK(
LOOKUPVALUE(
ReplenishOnly[ProductID],
ReplenishOnly[ProductID], ReplenishAll[ProductID],
ReplenishOnly[SubsidiaryID], ReplenishAll[SubsidiaryID]
)
),
TRUE,
FALSE
)
)
If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
I was hoping SUMMARIZE instead of SELECTCOLUMNS would solve the problem, since it preserves data lineage, but it's still not working.
Here's the new code for the three tables:
ReplenishOnly =
SUMMARIZE (
FILTER (
'Stores ISP',
'Stores ISP'[Stores Replenish] > 0
&& 'Stores ISP'[SnapshotDate] > TODAY () - 8
),
'Stores ISP'[ProductID],
'Stores ISP'[SubsidiaryID]
)
ReplenishAll =
SUMMARIZE (
'Stores ISP',
'Stores ISP'[ProductID],
'Stores ISP'[SubsidiaryID]
)
Replenishable =
ADDCOLUMNS (
'ReplenishAll',
"Replenishable",
IF (
NOT ISBLANK (
LOOKUPVALUE (
ReplenishOnly[ProductID],
ReplenishOnly[ProductID], ReplenishAll[ProductID],
ReplenishOnly[SubsidiaryID], ReplenishAll[SubsidiaryID]
)
),
TRUE,
FALSE
)
)Then I created a many-to-one relationship between Replenishable & Product and Replenishable & Subsidiary on the corresponding ID columns, and confirmed the relationship was active.
But the Replenishable slicer doesn't filter my results, and when I run NATURALINNERJOIN('Replenishable','Product') in Dax Studio, it tells me there are no common join columns detected.
(I also tried creating the last table using SUMMARIZE instead of ADDCOLUMNS but the results were the same.)
Why is this relationship still not working? Is it because the relationship is many to one, so Replenish can't filter Product?
Hi shadowsong42,
Thanks for the additional clarification and updated code. You're very close—what you’re encountering now stems from how data lineage is handled within your calculated tables. While SUMMARIZE does preserve lineage, using functions like LOOKUPVALUE inside your Replenishable table breaks that lineage. Once lineage is lost, Power BI cannot propagate filters across relationships, which explains why your slicer isn’t filtering visuals based on fields from the Product or Subsidiary tables, and why NATURALINNERJOIN fails to detect join columns
To resolve this while still achieving your goal of having a TRUE/FALSE column usable in a slicer, I suggest a lineage-preserving approach using set-based functions such as INTERSECT. These functions operate on full row context and retain lineage, allowing relationships to work correctly. You can define a variable using INTERSECT to find matching (ProductID, SubsidiaryID) pairs between ReplenishAll and ReplenishOnly, and then use ADDCOLUMNS to mark those as TRUE.
If this post helps, then please give us ‘Kudos’ and consider Accept it as a solution to help the other members find it more quickly.
Thank you.
Can you tell me more about how that would work? I can't find anything that explains how to get from the results of INTERSECT to returning TRUE if this row is in the intersect.
ReplenishOnly is a subset of ReplenishAll, so it seems like using INTERSECT on those tables would just return ReplenishOnly again.Hi shadowsong42,
Could you please provide some sample data so we can offer a solution to your issue?
Thank you