# Tableau Data Blending to Power BI: Converting Blends into Model Relationships

> How Tableau blends become Power BI relationships: linking fields, cardinality, why limited relationships change totals, and when to use TREATAS instead.

- Canonical: https://getantares.io/tableau-blending-to-power-bi-relationships/
- Published: 2026-02-18
- Updated: 2026-07-28

---

Tableau states the difference in one sentence: a join combines the data and then aggregates, while a blend aggregates and then combines. Blends never merge the data at all. They query each source independently, aggregate each result to the level of the view, and present the results together. Power BI has nothing shaped like that. Its model relationships propagate filters between tables and the aggregation happens afterwards, so converting a blend is a modelling decision about what the blend was standing in for.

## Blending concepts in Power BI

| Tableau | Power BI equivalent | Notes |
| --- | --- | --- |
| Primary data source | The table filters propagate from | Usually the dimension side of the relationship |
| Secondary data source | The related table | Filtered by the primary, never the reverse by default |
| Linking field | The relationship column | Both columns should have the same data type |
| Several linking fields | One relationship on a combined key | A relationship relates one column to one column |
| Secondary values must be aggregated | Measures over the related table | The same discipline, enforced by the engine |
| Asterisk for multiple values | An explicit aggregation, or a blank | No equivalent placeholder |
| Blend across databases | One model, or a composite model | Source groups matter, see below |
| Blended sources cannot be published | The semantic model is published once and reused | A real gain from the migration |
| Blend used to avoid duplicating rows | Star schema with a fact and dimensions | Often the honest answer |

## Cardinality and filter direction are the actual work

A blend has no cardinality setting. A [Power BI relationship](https://learn.microsoft.com/en-us/power-bi/transform-model/desktop-relationships-understand) has four options, one-to-many, many-to-one, one-to-one and many-to-many, and a cross filter direction of single or both. Power BI detects cardinality when the relationship is created, and it can get it wrong when tables are not yet loaded or when a column happens to hold unique values today.

Take the defaults seriously. One-to-many with a single filter direction is the fastest and the least ambiguous, and it is what a blend from a dimension to a fact usually means. Bi-directional filtering is tempting for reproducing a blend that seemed to work in both directions, but it costs performance and can produce ambiguous filter paths that Power BI resolves by its own priority rules or refuses outright. Where a Tableau workbook linked one dimension to a fact in more than one role, the equivalent is one active relationship plus inactive ones activated per calculation with `USERELATIONSHIP`.

| Cardinality | Cross filter options | Evaluated as |
| --- | --- | --- |
| One-to-many, many-to-one | Single or Both | Regular, within one source group |
| One-to-one | Both only | Regular, within one source group |
| Many-to-many | Single either way, or Both | Always limited |
| Anything across source groups | As above | Always limited |

## The trap: regular versus limited relationships

This is the part that changes numbers after a migration, and it is not a setting you choose. Power BI classifies each relationship as regular or limited, inferred from cardinality and source. A relationship is limited when it uses many-to-many cardinality, or when it crosses source groups in a composite model.

The difference is join semantics. Regular relationships expand tables using outer-join semantics, and a "many" side row with no match on the "one" side still appears, against a blank. Limited relationships join with inner-join semantics, so unmatched rows are dropped, no blank row is added, and `RELATED` cannot reach the other side. A blend tolerates unmatched members quietly, showing nulls in the view. Rebuild it as a many-to-many or cross-source relationship and those rows can disappear from totals instead. Reconcile counts against the Tableau view before anyone signs off.

## When there should be no relationship at all

Some blends exist precisely because a join would be wrong: the sources are at different grains, the keys are ragged, or a physical relationship would create ambiguity elsewhere in the model. For those, [TREATAS](https://learn.microsoft.com/en-us/dax/treatas-function-dax) applies the result of a table expression as a filter on an unrelated table, giving you a virtual relationship that exists only while that measure is evaluated. It is the closest DAX gets to the spirit of a blend: two independent queries, brought together at the point of display.

The related option is `CROSSFILTER`, which changes or disables filter propagation for one calculation without altering the model. Between them, the pattern is the same as the physical one: keep the model simple and single-directional, and handle the exceptions inside the measures that need them.

## What Antares does with blends

The Analyzer records which worksheets rely on blends and which data sources they combine, because each one is a decision about the model rather than a chart to convert. That distinction is what keeps an estimate honest: fifty blended worksheets sitting on one primary-to-secondary link are a single relationship plus fifty conversions, while five blends across five unrelated sources are five modelling problems.

Blends are also the clearest example of why the metadata comes first. The blend itself never appears in a formula, so any count based on reading calculations misses it entirely. [Run the free Analyzer](https://try.getantares.io) to see where blends sit in your own workbooks.

Related reading: [data sources to Power BI datasets](/tableau-data-sources-to-power-bi-datasets/) and [custom SQL to Power BI](/tableau-custom-sql-to-power-bi/). Primary sources: Tableau's [data blending documentation](https://help.tableau.com/current/pro/desktop/en-us/multiple_connections.htm) and Microsoft's guidance on [many-to-many relationships](https://learn.microsoft.com/en-us/power-bi/guidance/relationships-many-to-many) and the [USERELATIONSHIP function](https://learn.microsoft.com/en-us/dax/userelationship-function-dax).

## Related resources

- [Tableau to Power BI Migration Guide](/tableau-to-power-bi-migration/)
- [Data Sources to Power BI Datasets](/tableau-data-sources-to-power-bi-datasets/)
- [Custom SQL to Power BI](/tableau-custom-sql-to-power-bi/)
- [LOD Expressions to DAX](/tableau-lod-expressions-to-dax/)

## FAQ

### What is the Power BI equivalent of Tableau data blending?

A model relationship, in most cases. Tableau blends query each source separately, aggregate each result, then present them together. Power BI relationships propagate filters between tables and aggregate afterwards, so the linking field becomes a relationship column and secondary values become measures.

### Why do totals change after converting a blend to a relationship?

Usually because the new relationship is limited rather than regular. Many-to-many relationships and relationships crossing source groups join with inner-join semantics, so rows with no match are dropped instead of showing against a blank. A blend tolerates unmatched members quietly; the relationship does not.

### Can Power BI blend on several linking fields?

Not directly. A relationship relates one column to one column, so several linking fields become a single combined key column, built in Power Query or with COMBINEVALUES for DirectQuery models. Both columns should carry the same data type.

### When should a blend not become a relationship?

When the sources are at different grains, the keys are ragged, or a physical relationship would create ambiguous filter paths. TREATAS applies a table expression as a filter on an unrelated table, giving a virtual relationship that exists only while that measure is evaluated.