Understanding Cardinality and Cross-Filter Direction

When creating relationships, Power BI asks you to configure properties that determine how records are associated and how filters travel between tables.

What Is Cardinality?

Cardinality describes the matching pattern between values in two related columns.

Power BI supports several relationship cardinalities.

1. One-to-Many (1:*)

Each value on the one side corresponds to zero, one, or multiple matching records on the many side.

For example, one product can appear in many sales transactions.

This is a common relationship pattern in analytical models.

2. One-to-One (1:1)

Each value on one side corresponds to at most one matching value on the other side.

This can be useful when information about the same entity is separated into two tables, although combining the tables may sometimes be simpler.

3. Many-to-Many (:)

Multiple records on both sides can share the same relationship value.

For example, employees may belong to multiple projects, and each project may contain multiple employees.

Many-to-many relationships require careful design because they can introduce ambiguity or unexpected filtering behavior.

What Is Cross-Filter Direction?

Cross-filter direction determines how filters propagate between related tables.

Single-direction filtering allows filters to travel in one configured direction. In a common star schema, filters flow from dimension tables toward fact tables.

For example, selecting the category "Electronics" in a Products table filters the related sales transactions.

Both-direction filtering allows filters to propagate in both directions across the relationship.

Although bidirectional filtering can be useful in specific scenarios, excessive use can introduce ambiguous filter paths and make calculations harder to understand.

Choosing the Right Relationship Settings

For many reporting models, a one-to-many relationship with single-direction filtering is a good starting point.

Before choosing another configuration, verify:

• Whether the relationship columns contain the expected values.
• Whether the one-side column is unique.
• Whether the relationship should be active.
• Whether filters need to propagate in both directions.
• Whether the model contains multiple paths between related tables.

The goal is to create predictable filtering behavior rather than simply making all tables connect.