How do relationships work in Power BI, and what problems do bidirectional relationships cause?

Relationships connect tables so filtering one filters the other. Each has a cardinality and a cross-filter direction.

Cardinality:

• One-to-many — the standard and desirable case, from a dimension to a fact.
• Many-to-one — the same thing described from the other side.
• One-to-one — usually a sign two tables should be merged.
• Many-to-many — supported, but it creates ambiguity and is often a modelling smell. The cleaner solution is usually a bridge table.

Cross-filter direction is single by default: the one side filters the many side. That is normally what you want — Product filters Sales, not the reverse.

Why bidirectional relationships are dangerous:

• Ambiguity. With several tables and bidirectional filters, more than one filter path can exist between two tables, and the engine either refuses the model or picks a path you did not intend.
• Wrong totals that look plausible — the worst kind of error, because nobody notices.
• Performance cost, since the engine must propagate filters both ways.

The better approach: keep relationships single-direction and use CROSSFILTER inside a specific measure when you genuinely need bidirectional behaviour. That confines the effect to one calculation instead of the whole model.

Note: Only one relationship between two tables can be active. Use USERELATIONSHIP inside CALCULATE to activate an alternative — the standard pattern for a fact table with both an order date and a ship date.