Why does a Tableau filter action fail to filter a target sheet on a different data source?

## What a filter action actually sends A Tableau filter action does not carry a row identifier or a join. It takes the dimension values on the mark the user interacted with and applies them as a filter on the target sheet's own fields. That is a value-based match, and it is the source of every cross-data-source failure. ## All Fields versus Selected Fields In the action's Target Filters section there are two modes. **All Fields** tells Tableau to match on the fields the source and target have in common. Within a single data source this is convenient and usually right. Across two data sources the field names are rarely identical, so there is nothing to match on and the action appears to do nothing at all — or, worse, matches on one incidental shared name and filters by the wrong thing. **Selected Fields** lets you state the mapping explicitly: source `[Region]` filters target `[Sales Region]`, source `[Order Date]` filters target `[Date]`. For a cross-data-source action this is the mode to use. Note that the target field must exist in the target sheet's data source — it does not need to be on the view's shelves for a filter action, but it must be a real field there. ## Why an explicit mapping still returns nothing Once the mapping is right, the remaining failures are all data problems. - **Different vocabularies.** The CRM extract says `USA`, the finance warehouse says `United States`. Both are correct in their own system and neither will ever match the other. The only real fix is upstream: conform the values, or add a lookup column to one source so a matching field exists. - **Whitespace and case.** A trailing space in one system, or `ACME` against `Acme` in a source whose comparison is case-sensitive, silently yields zero rows. - **Type mismatch.** A customer ID stored as a string on one side and a number on the other will not match; neither will an alias, since the action compares underlying values rather than the display alias. - **Grain mismatch.** This is the most common one with dates. The source view shows a month, the target's field is a timestamp — filtering the target by a month value against timestamps matches nothing. Bring both to the same grain with a calculated field, typically by truncating the timestamp to the same date part. - **Aliases and groups.** If the source dimension is grouped or aliased, the visible label is not necessarily the value that travels. ## A diagnosis routine 1. Build a scratch sheet from the source data source with just the source field on Rows, and another from the target data source with just the target field. Compare the value strings side by side, character for character. This catches vocabulary, case and whitespace mismatches in seconds. 2. Confirm the action uses Selected Fields with a mapping for every field you intend to filter on, and nothing extra. An extra mapped field that does not match narrows the result to nothing even if the others match. 3. Check the data types of both fields. Change one with a calculated field if needed rather than hoping the action coerces them. 4. Temporarily set the target sheet to show the field you are filtering on so you can see what survives. 5. Check the clearing behaviour: an action set to exclude all values looks identical to a broken mapping when nothing is selected. ## When an action is the wrong tool If you find yourself building conversion calculations on both sides so an action can match, the real problem is that the two sources are not conformed. Options in rough order of preference: - Fix it upstream in the warehouse or the transformation layer, so both sources speak the same vocabulary and grain. This is the durable answer and it benefits every other tool reading the same data. - Bring the two together in the data source itself — a relationship, join or blend on a shared key — so the sheets share one source and All Fields works normally. - Keep the action and add mapping calculations, accepting that the mapping now lives in a workbook where nobody else will find it. A filter action across mismatched sources is a presentation-layer patch over a modelling problem, and it will break the next time either system adds a value. ## A related gotcha Even within one data source, a filter action can look broken when the target sheet's aggregate is computed by a FIXED level-of-detail expression, because those are evaluated before dimension filters — the marks change but the number does not. Rule that out before assuming a mapping problem: if the target's row count changes at all, the action is firing and the issue is the calculation, not the mapping.