Power BI Relationship Not Working? 9 Checks Before Rewriting DAX

When a Power BI relationship is not working, do not begin by adding
CALCULATE, FILTER, or bidirectional
relationships. First prove whether a dimension filter changes the number
of visible fact rows. Then inspect the key, data type, cardinality,
active path, and direction in that order.

This isolates the model before DAX hides the problem.

Build the smallest
relationship test

Assume a standard model:

Customer (1) → Sales (*)

Create two measures:

Visible Sales Rows =
COUNTROWS ( Sales )

Visible Customers =
COUNTROWS ( VALUES ( Customer[CustomerKey] ) )

Put Customer[CustomerName],
Visible Sales Rows, and Visible Customers in a
table.

• If Sales rows change by customer, the relationship propagates.
• If every customer shows the same Sales row count, the filter is not
  reaching Sales.
• If some customers are blank, their keys may not match the fact
  table.

Use a raw row count before testing a complicated business
measure.

Check 1:
The join columns contain the same kind of key

Open both tables in Data view and inspect the relationship
columns.

Common mismatches include:

• customer ID versus customer name;
• product code versus surrogate product key;
• order date versus ship date;
• an integer key on one side and text on the other;
• leading or trailing spaces;
• different case or normalization rules; and
• Date on one side and Date/Time on the other.

Formatting is not the data type. A column displayed as
2026-04-11 may still contain a time component.

Create temporary table visuals with both key columns and counts. A
key that looks identical in a screenshot can still differ
underneath.

Check 2: The
one-side key is actually unique

The “1” side of a one-to-many relationship must have one row per key.
Duplicates can force a many-to-many relationship or prevent the
relationship you intended.

Compare:

Customer Rows =
COUNTROWS ( Customer )

Distinct Customer Keys =
DISTINCTCOUNT ( Customer[CustomerKey] )

If the counts differ, find the duplicates before changing
cardinality.

A many-to-many relationship can be legitimate, but it should
represent a deliberate model design—often with a bridge table—not a
quick response to dirty dimension data.

Check 3: The relationship is
active

Only one relationship between the same two tables can usually be
active at a time.

A Sales table may contain:

• OrderDateKey
• ShipDateKey
• DueDateKey

The Date-to-OrderDate relationship may be active while
Date-to-ShipDate is inactive. A visual using Date fields will filter
order dates unless the measure activates the other relationship:

Sales by Ship Date =
CALCULATE (
    [Sales Amount],
    USERELATIONSHIP (
        Sales[ShipDateKey],
        'Date'[DateKey]
    )
)

Use USERELATIONSHIP for a deliberate alternate path. The
inactive date
relationship guide shows the full pattern.

Check 4:
The filter direction reaches the fact table

In a star schema, a one-way relationship normally filters from
dimension to fact:

Product (1) → Sales (*)

If you put Product[Category] in a slicer, that filter
should reach Sales.

Do not turn on “Both” merely because a visual is blank. Bidirectional
filters can create ambiguous paths, unexpected intersections, and
harder-to-debug totals.

First ask whether the field is coming from the correct dimension. A
category column stored in a disconnected lookup table cannot filter
Sales without a relationship or an intentional virtual relationship such
as TREATAS.

Check 5: There is no
competing path

Power BI can deactivate or reject a relationship when multiple active
paths would make filter propagation ambiguous.

For example:

Date → Sales
Date → Budget
Sales ↔ Budget

Multiple routes can allow the same Date filter to reach a table in
more than one way.

Prefer a clear star schema:

• dimensions filter facts;
• fact tables do not directly filter each other;
• shared dimensions connect independently to each fact; and
• alternate date roles remain inactive until a measure activates
  them.

Microsoft’s
relationship troubleshooting guidance recommends verifying
relationship properties and filter propagation before solving the
symptom in a visual.

Check 6:
Unmatched keys are creating the blank member

If Sales contains a CustomerKey that does not exist in Customer,
Power BI preserves referential integrity through an unknown or blank
member.

This can appear as:

• a blank customer in a visual;
• totals larger than the sum of named customers;
• a slicer selection that misses some fact rows; or
• measures returning values under (Blank).

Count orphaned fact keys:

Unmatched Customer Keys =
COUNTROWS (
    EXCEPT (
        VALUES ( Sales[CustomerKey] ),
        VALUES ( Customer[CustomerKey] )
    )
)

If the result is greater than zero, repair the source data or add a
deliberate “Unknown” dimension row. Do not hide the blank label before
understanding it.

Check 7: Date values are
aligned

Date relationships fail frequently because the fact column contains
timestamps:

2026-04-11 14:32:18

while the date table contains midnight-only dates:

2026-04-11 00:00:00

Even if both display as April 11, they are not equal.

Create a date-only column during data preparation and relate that to
the date table. Also confirm that:

• the date table spans the full fact range;
• its key is unique;
• it contains no blanks;
• dates are contiguous for classic time intelligence; and
• the visual uses the date-table column, not the fact-table date.

Use the date-table
troubleshooting checklist when the relationship exists but
time-intelligence measures still fail.

Check 8:
The visual uses fields from compatible tables

A measure may be correct while the visual combines unrelated
dimensions.

For example, placing Region[Name] and
Campaign[Name] in one visual requires a model path that
makes their intersection meaningful. If each dimension filters a
different fact table with no shared grain, Power BI cannot invent the
business relationship.

Build a blank-page test:

1. add one dimension field;
2. add Visible Sales Rows;
3. add the second field;
4. watch where rows repeat or disappear; and
5. inspect the model path for that exact combination.

The issue may be visual grain, not the base relationship.

Check
9: The measure does not remove the propagated filter

The relationship can work perfectly while the measure deliberately
clears the dimension:

Sales Ignoring Customer =
CALCULATE (
    [Sales Amount],
    REMOVEFILTERS ( Customer )
)

Test the raw fact-row count beside the measure. If
Visible Sales Rows changes by customer but the business
measure does not, search the measure dependency chain for:

• ALL
• REMOVEFILTERS
• ALLEXCEPT
• CROSSFILTER
• TREATAS
• nested CALCULATE

If a slicer is involved, follow the measure-ignores-slicer
checks.

A relationship
debugging order that saves time

Use this sequence:

1. Count visible fact rows by the dimension.
2. Compare key data types.
3. Prove uniqueness on the one side.
4. Check whether the relationship is active.
5. Confirm direction from dimension to fact.
6. Look for ambiguous competing paths.
7. Count unmatched fact keys.
8. Test date granularity and range.
9. Inspect filter-removal logic in the measure.

Changing one property at a time preserves evidence. Randomly toggling
cardinality and cross-filter direction creates a model that is harder to
reason about.

Frequently asked questions

Why does
my Power BI relationship exist but not filter?

The visual may use a disconnected field, the relationship may be
inactive, the filter direction may not reach the fact table, or the
measure may remove the filter. Test COUNTROWS on the fact
table by the dimension field.

Should
I use a many-to-many relationship to fix duplicate keys?

Not automatically. First determine why the one-side key is
duplicated. Use many-to-many only when it matches the real business
grain, typically with an intentional bridge.

Why do
I get a blank row after creating the relationship?

The fact table probably contains keys that are missing from the
dimension. Count the difference between fact keys and dimension keys,
then repair or explicitly model unknown members.

Where can I verify the
model behavior?

Recreate the smallest dimension-to-fact path in the DAX
playground. Keep the row-count diagnostics visible while you test
the relationship and measure separately.