Tableau Blending vs Joining: Why Your Metrics Look Wrong and How to Fix It

May 25, 2026 7 min read 82 views

Tableau Blending vs Joining: Why Your Metrics Look Wrong and How to Fix It

Every Tableau developer has stared at a number that shouldn't exist. The revenue is off by a factor of three. The customer count doubled overnight. The culprit is almost always the same silent offender β€” a blend masquerading as a join.

What You'll Learn

  • The mechanical difference between a join and a blend in Tableau
  • Why blends produce aggregated results that can inflate or suppress your metrics
  • How to spot which relationship type is active in your workbook
  • When to use each approach deliberately
  • Concrete steps to fix a dashboard that's showing the wrong numbers

The Problem Nobody Warns You About

Tableau is unusually forgiving when you connect multiple data sources. Drag a field from a second source onto your canvas and the software quietly decides how to stitch the data together on your behalf. Most of the time this feels magical. Occasionally, it silently destroys your numbers.

The mechanism behind that magic β€” data blending β€” is one of the most misunderstood features in Tableau. It is not a join. It does not behave like a join. And if you treat it like one, your aggregations will be wrong in ways that are difficult to spot without knowing exactly what to look for.

Part 1 β€” How Joins Actually Work

A join happens at the data source level, before any aggregation. Tableau (or the database it is querying) takes two tables, matches rows according to a key, and returns a new flat table. Every row in the result corresponds to a matched pair of rows from the originals.

Consider a simple example. Your Orders table has four rows β€” two for East (sales of 4,200 and 1,800) and two for West (sales of 3,100 and 2,500). Your Targets table has one row per region: East target 5,000 and West target 4,500.

After a left join on Region, the result has four rows. The target value is repeated for each matching order row β€” 5,000 appears against both East rows, and 4,500 appears against both West rows. This is correct behaviour at the row level. The join was faithful: every row and every value came through exactly as the database held them.

The implication is important: if you later compute SUM(Target) filtered to East, Tableau sums those two repeated 5,000 values and returns 10,000. That may or may not be what you intended β€” but it is a downstream aggregation-design decision, not a join problem. The join itself did exactly what it was told.

Part 2 β€” How Blends Actually Work

A blend is fundamentally different. It does not merge tables before aggregation. Instead, Tableau queries each data source independently, aggregates each result separately, and then stitches the aggregated outputs together in the presentation layer. The link happens after the numbers are computed, not before.

Using the same example: Tableau first queries Orders and aggregates to the Region level β€” East 6,000, West 5,600. It then queries Targets and aggregates separately β€” East 5,000, West 4,500. Finally it links those two aggregated results on Region and displays them side by side.

The blended view gives you correct-looking numbers at the region level. The problem surfaces when you change the view's level of detail. If your visualisation drills down to sub-region or individual order, the secondary source cannot follow β€” it was already aggregated at region level. Tableau will either display asterisks, show null values, or silently hold the region-level aggregate against every row beneath it.

The Silent Inflation Problem: If your primary source has more granularity than your blend link field, the secondary value can appear duplicated. A dashboard filtered to a single city shows the entire region's target against that city's sales β€” and there is no warning in the view to tell you this happened.

Part 3 β€” Spotting Which Mode Is Active

Tableau signals the relationship type in several places. Knowing where to look saves hours of debugging.

Check 1 β€” Data source tab icons

In the data pane, your primary data source has a blue checkmark icon. Secondary sources have an orange chain-link icon. Any field from a secondary source that is being used as a blend link has a small link indicator. If you see the chain-link, you are blending.

Check 2 β€” The data source edit screen

Double-click your data source tab at the bottom of the screen. If you see a canvas with joined tables and a Venn diagram icon between them, you configured a join. If each source has its own canvas and you connect between worksheets, you are blending.

Check 3 β€” Field pill colouring

Fields from the primary source render as blue pills in the view. Fields from a secondary source render in orange. Orange pills on your rows or columns shelf are a strong signal that a blend is active and you should verify the level-of-detail assumptions.

Check 4 β€” The asterisk in your view

When Tableau cannot match a secondary source value at the current level of detail, it displays an asterisk (*). This is not an error state β€” it is a warning that the blend failed at that granularity. If you see asterisks, your blend link fields do not resolve cleanly at the view's detail level.

Part 4 β€” When to Use Each Approach Deliberately

ScenarioBest approachWhy
Both sources live in the same databaseJoinThe database engine handles the merge efficiently at row level; no aggregation lock-in.
Sources are in different databases (e.g. SQL + Excel)BlendJoins cannot cross data source boundaries; blending is the only in-Tableau option.
Secondary source is summary-level data (monthly targets, regional budgets)BlendThe secondary source was already designed at aggregate granularity; blending matches that intent.
You need row-level calculations combining both sourcesJoinBlends cannot create row-level calculated fields across sources; joins can.
Secondary source has one row per dimension memberEitherWhen granularity matches, both produce the same result; prefer join for clarity.
You cannot modify the live databaseBlendBlending requires no schema changes; joins on live sources may require view permissions.

Part 5 β€” Five Concrete Steps to Fix a Broken Dashboard

You have a dashboard. The numbers are wrong. Here is the systematic path out.

  1. Identify the data source structure. Open each sheet in the workbook. Look at the data pane for orange chain-link icons. Note which sources are primary (blue checkmark) and which are secondary (orange). Write this down β€” a workbook with four sheets can have four different primary sources.
  2. Compare granularity across sources. Ask: what is the lowest level of detail in each source? If your primary source has individual transaction rows and your secondary source has one row per month, any blend at transaction level will multiply or suppress values from the secondary source.
  3. Check the blend link fields. In Data > Edit Blend Relationships, confirm which fields are linked. Unlinked fields allow the secondary source to return a single aggregate for all rows β€” a common cause of inflated totals. Add link fields until the granularity of both sources matches the view's level of detail.
  4. Test with a row-count sanity check. Add COUNT([Order ID]) and, separately, pull in a record count from your secondary source. If the primary count changes when you bring in secondary fields, a join fanout is inflating rows. If the secondary count stays constant across dimension values, the blend is not resolving at the right level.
  5. Consider migrating to a Relationship or extract join. If sources can be unified, rebuild the connection using Tableau's Relationships model (the default since version 2020.2) or a cross-database join in an extract. Relationships apply join conditions lazily and avoid the fanout problem that plagues traditional joins β€” they are almost always the right choice for new builds.

The Relationship Alternative: Since Tableau 2020.2, Relationships sit between joins and blends in the data model. They are defined at the logical layer, join lazily at the appropriate level of detail, and do not replicate rows the way physical joins do. For most multi-source scenarios, Relationships are the safest default. Only fall back to explicit joins or blends when you have a specific reason.

The Pattern to Remember

A join is a recipe given to the kitchen before cooking starts. Every ingredient is combined at raw weight, and you measure the result after cooking.

A blend is ordering from two separate restaurants, receiving two already-plated dishes, and then combining them on your own plate. Each kitchen only knows about its own dish. If the portions do not match, you discover it at the table, not during preparation.

When your metrics look wrong, the first question is always: at what point in the pipeline were these numbers combined? If the answer is "before aggregation," you have a join (or relationship). If the answer is "after aggregation," you have a blend β€” and the mismatch is almost certainly a granularity problem between your two sources.

Fix the granularity mismatch and the numbers will follow.

πŸ“€ Share this article

Sign in to save

Comments (0)

No comments yet. Be the first!

Leave a Comment

Sign in to comment with your profile.

πŸ“¬ Weekly Newsletter

Stay ahead of the curve

Get the best programming tutorials, data analytics tips, and tool reviews delivered to your inbox every week.

No spam. Unsubscribe anytime.