- What additional configuration is needed to satisfy the full requirement?
Answer: Add a filter action from the territory sheet to the destination sheet using the territory field.
Whenever you see a question about dashboard interactivity in Tableau, separate the concepts of navigation and filtering — they are distinct mechanisms that must be configured independently. A Go to Sheet action handles movement between dashboards; it does not automatically carry data context along for the ride.
The scenario requires two things: (1) navigate to the detail dashboard, and (2) display only records for the selected territory. The Go to Sheet action already handles requirement one. To satisfy requirement two, you need a filter action that sends the selected territory's value to the destination sheet, restricting what data appears there. Adding a filter action from the territory sheet to the detail dashboard using the territory field accomplishes exactly this — making D the correct answer.
A is wrong because Go to Sheet actions have no aggregation configuration; aggregation is a property of the view itself, not the action. This option invents functionality that doesn't exist in Tableau.
B is wrong because URL actions are designed to open external web pages, not to pass filter context between Tableau dashboards. Swapping navigation type doesn't solve the filtering problem, and URL actions aren't the right tool here at all.
C is wrong because highlight actions emphasize matching marks visually without removing non-matching records — they don't filter data. A highlight on the destination would still show all territories, just with some visually accented.
As a study tip, remember this pattern: navigation ≠ filtering. On the Tableau exam, questions about dashboard actions frequently test whether you understand that Go to Sheet, Filter, Highlight, and URL actions each do one specific job — and accomplishing a full interactive requirement often means combining more than one.
- What should the workbook author expect from this configuration?
Answer: The parameter remains 0.10 because multiple differing marks do not provide one unaggregated value.
When a parameter action's aggregation is set to None, Tableau requires a single, unambiguous value to update the parameter — it cannot resolve competing values from multiple selected marks. This question tests whether you understand that constraint and its consequences.
With aggregation set to None, Tableau interprets the source field at the row level. If every selected mark shares the same discount value, the parameter updates cleanly. But when selected marks carry different discount values, Tableau has no rule for choosing among them, so it simply leaves the parameter unchanged — still 0.10 in this case. That makes A correct: the parameter holds its current value because the selection produces an ambiguous, multi-valued result.
B is wrong because Tableau does not silently fall back to AVG when aggregation is set to None. The None setting explicitly means no aggregation will be applied — Tableau won't override your choice with a default. C fails for the same reason: MAX is not a fallback resolution strategy. Tableau never quietly applies MAX behind the scenes when None is selected. D misunderstands how the action fires. A selection event triggers the action once for the entire selection, not once per mark — so there's no cycling behavior.
A good study tip: whenever you see a parameter action question, immediately ask yourself two things — what aggregation is set? and how many marks are selected? The combination of None + multiple differing values is Tableau's "no-update" condition, and it's a favorite exam trap. - Which set action assignment behavior should the author choose?
Answer: Toggle values, because each selected product reverses membership while other members remain unchanged.
When a question describes a "toggle" or "reverse membership" behavior for a set action, you're being tested on Tableau's four set action assignment modes and what each one does to existing set membership.
The scenario is the key: selecting a product that's already in the set should remove it, selecting one that's outside the set should add it, and untouched products stay exactly as they were. That precise flip-for-each-selected-mark behavior is the definition of Toggle values — making D the correct answer. Toggle acts independently on each selected mark based on its current state, which is exactly what "reversing membership" means.
A is wrong because "Assign values to set" replaces the entire set with whatever is currently selected. That wipes out previous members entirely rather than toggling individual ones — the opposite of what the scenario requires.
B is a tempting trap. "Add values to set" only ever adds marks; it never removes them. Selecting an existing member does not automatically remove it — that's a misconception. The set would grow indefinitely, never shrinking.
C has the same logic flaw in reverse. "Remove values from set" only ever removes marks; nonmembers are not automatically added during the same action. The set would shrink indefinitely, never growing.
A helpful memory anchor: Toggle = two-way switch. Every other mode is one-directional (add only, remove only, or full replace). Whenever you see language like "reverse," "flip," or "alternate" membership on a per-mark basis, Toggle is always the right choice.
- Which result should occur?
Answer: Trend and Details are filtered, while Category Summary remains a selected source view.
When you see a question about dashboard filter actions in Tableau, focus on one key mechanic: source sheets and target sheets play distinct, separate roles. A filter action reads user interaction from the source and sends filtered context to the targets — these are not the same thing.
When the user selects Furniture in Category Summary, the action fires and passes that selection as a filter to whichever sheets are listed as targets. Since only Trend and Details are configured as targets, those two worksheets update to show only Furniture data. Meanwhile, Category Summary simply reflects the user's selection visually — it is not filtered by its own action. This is exactly what C describes, making it the correct answer.
A is wrong because there is no "implicit target" rule in Tableau. The source sheet is never automatically added as a target — only sheets you explicitly check in the action's target configuration are affected. B inverts the logic entirely: the source sheet is where the action originates, not where the filter lands. Claiming the source filters itself first is a fabricated rule. D is the most tempting distractor — it sounds cautious and procedural — but it's false. The action works perfectly fine without the source sheet being listed as a target; that's actually the default and most common configuration.
Your study tip: when reviewing filter actions, always ask yourself "where does the action read from, and where does it write to?" Source = trigger, target = recipient. They are independent, and conflating them is the most common trap on action-related questions.
- Which setting should be selected under Clearing the selection will?
Answer: Leave the filter, so the existing regional filter remains applied to the target worksheets.
When working with dashboard filter actions in Tableau, one of the most important configuration decisions is what happens when a user clears a selection — for example, by clicking a blank area. This behavior is controlled by the "Clearing the selection will" setting, and understanding each option is essential for building dashboards that behave predictably.
The scenario requires that target worksheets retain the most recently selected region even after the selection is cleared. The correct setting to achieve this is C) Leave the filter. This option keeps the filter that was applied by the action in place on the target sheets, even after the selection is deselected. The filter doesn't reset or disappear — it simply stops being actively driven by a new click, but the last applied value persists until the user makes a new selection.
A) Show all values is incorrect because it removes the filter entirely when the selection is cleared, causing both target worksheets to display all regions — the opposite of what the scenario requires. B) Exclude all values is a trap: rather than keeping the last region visible, it actually hides everything by applying an exclusion filter, leaving the target worksheets blank or empty. D) Keep current value sounds appealing but is a fabricated distractor — this is not a real option in Tableau's filter action settings, and filter actions don't interact with parameters this way by default.
As a study tip, memorize all three real "Clearing the selection will" options — Show all values, Exclude all values, and Leave the filter — and map each one to its real-world dashboard behavior. Tableau exam questions frequently test whether you know the consequences of each setting, not just the names.
- Which dashboard action best satisfies the requirement?
Answer: Create a highlight action targeting the transaction view and match on product category.
When a dashboard requirement says selected items should be emphasized while everything else stays visible, that's your signal to think about highlight actions — not filter actions. The key distinction is this: filters remove non-matching rows from view, while highlights dim them, keeping the full dataset visible for comparison.
That makes B the right answer. A highlight action targeting the transaction view, matched on product category, will visually emphasize the selected category's transactions while leaving all other rows on screen in a muted state. This perfectly satisfies the requirement: the user sees the selected category pop against the full population.
Here's why the other options fall short. A is a common trap — filter actions do narrow results, and "Show all values on clearing" only restores unfiltered data after the selection is cleared, not during it. While the selection is active, other categories disappear entirely, which breaks the comparison requirement. C uses a parameter action, which can drive conditional logic, but parameters alone don't emphasize rows visually — you'd need additional calculated fields and formatting work, and even then it mimics a filter behavior rather than a highlight. It's overengineered and still doesn't satisfy the "remain visible" requirement cleanly. D is a go-to-sheet action, which navigates the user to a different sheet or dashboard entirely — it doesn't emphasize anything in the current view and is simply the wrong action type for this use case.
A good study rule: whenever a question mentions keeping non-matching records visible for comparison, the answer almost always involves a highlight action, not a filter.
- Which configuration will allow selecting a customer mark to update the parameter reliably?
Answer: Create INT([Customer ID]), add it to the mark detail, and use it as the source field.
Whenever you see a question about parameter actions in Tableau, focus on two requirements that must both be satisfied: the source field must be on the mark (so Tableau can read it on click), and the data type must match the parameter's type exactly — Tableau will not coerce types automatically across a parameter action.
Here, [Customer ID] is stored as a string, but the parameter is an integer. Creating INT([Customer ID]) converts the field to the correct type at the field level, and adding it to the mark's Detail shelf makes it available for the action to read. That's exactly what C does, which is why it works reliably.
A is tempting but wrong. Parameter actions do not perform implicit type conversion — passing a string field into an integer parameter will either fail silently or produce errors, depending on the Tableau version. You cannot rely on this behavior.
B inverts the solution. Changing the parameter to string just to avoid conversion breaks all downstream calculations that depend on the field being an integer. You'd be sacrificing the whole purpose of the parameter to sidestep the real fix.
D misunderstands aggregation in this context. ATTR returns a value only when all marks in a selection share the same value — it's fragile for parameter actions and still doesn't resolve the type mismatch between a string field and an integer parameter.
As a study habit, always verify type alignment and mark availability as a two-item checklist when troubleshooting parameter actions. If either condition fails, the action won't work as expected.
- What happens when a user selects a region mark in
Detail? Answer: Chosen Region does not update because Detail is not configured as a source sheet for this action.
When working with parameter actions in Tableau, the most important configuration detail to understand is source sheet specificity — parameter actions only fire when a user interacts with the sheets explicitly listed as sources in the action's setup. This question tests whether you understand that the source field alone doesn't determine which sheets can trigger the action.
In this scenario, the action is configured with only Summary as the source sheet. Even though Detail contains marks with [Region] — the same field designated as the source field — that field membership is irrelevant. Tableau evaluates the action based on where the interaction occurs, not what fields the sheet happens to contain. Since the user is selecting a mark in Detail, and Detail is not listed as a source sheet, the action simply doesn't fire and Chosen Region remains unchanged. Answer A is correct.
Answer B is the most tempting distractor because it sounds logical — if the field matches, why wouldn't it work? But Tableau doesn't scan all sheets for matching fields; it only listens for interactions on explicitly configured source sheets. Answer C introduces a completely fabricated rule — whether the parameter is referenced in a calculation on Detail has no bearing on whether the action triggers. Answer D is also incorrect; Tableau doesn't reset or null out a parameter simply because a user interacts with a non-source sheet. The parameter retains its last value until a valid action updates it.
As a study tip, remember: in Tableau actions, source sheets are a whitelist. If a sheet isn't on the list, interacting with it is invisible to that action — regardless of what fields it contains.
- What is the final value of
Selected Profit? Answer: It is 45 because the sum is retained after the selection is cleared.
When a parameter action fires on Select, Tableau passes the aggregated source field value from all currently selected marks into the parameter — not individual values one at a time. So when a user selects three marks with profits of 10, 15, and 20, the action evaluates SUM([Profit]) across that entire selection: 10+15+20=45. The parameter is immediately updated to 45.
The critical second step is what happens when the user clicks a blank area, clearing the selection. This behavior is controlled by the action's clear selection setting. Because this action is configured to Keep current value, the parameter simply holds whatever value it last received — in this case, 45. No rollback occurs, and no null is introduced. The correct answer is B.
A is wrong because Tableau doesn't feed marks into the parameter sequentially and land on the "last" one. The aggregation runs across all selected marks simultaneously, producing a single value.
C reflects a common misconception — that "Keep current value" means Tableau preserves the pre-action value of 100. In reality, "Keep current value" refers to what happens when the selection is cleared, not when it fires. The parameter was already updated to $45 when the marks were selected; clearing the selection just stops it from being reset.
D would be the behavior if the action were set to Clear value on deselection, which would push a null into the parameter — but that's not the configured behavior here.
Study tip: Always track two separate moments for parameter actions — when the action fires (on select/hover/menu) and what happens when the selection is cleared. Exam questions often test both in the same scenario. - How should the dashboard filter action be configured?
Answer: Use Selected Fields and map [State Code] to [Return State] explicitly in the action dialog.
When a dashboard filter action needs to connect two worksheets that draw from different data sources, Tableau cannot automatically match fields unless they share the exact same name. This is a common scenario on the Tableau exam, and the key question to ask yourself is: "Do my source and target fields have matching names?" If they don't, you must configure the mapping manually.
That's exactly why B is correct. In the filter action dialog, choosing Selected Fields lets you explicitly map [State Code] (the source field in Orders) to [Return State] (the target field in Returns). Tableau then knows to pass the selected value across data sources correctly, even though the field names differ. The fields work here because they share the same data type and contain the same values — but shared values alone aren't enough; you still need to tell Tableau which fields to pair.
A is wrong because Tableau does not match fields by value when names differ — it matches by field name when using All Fields. Mismatched names with All Fields will simply produce no filtering. C is tempting but unnecessary; renaming fields is a workaround, not a requirement, and modifying your data model just to enable a filter action is poor practice when Selected Fields already solves the problem cleanly. D is flatly incorrect — filter actions work perfectly across multiple data sources; a shared single source is not a requirement.
Study tip: Whenever you see cross-data-source filter actions with different field names, immediately think "Selected Fields + explicit mapping." That pairing is the reliable solution Tableau tests repeatedly.
