- What must a dashboard user do to run this action for a particular customer mark?
Answer: Display the mark's tooltip and click the Highlight Customer History command provided in that tooltip.
When you see a question about dashboard actions in Tableau, focus on the three trigger options — Hover, Select, and Menu — and what each one requires from the user. Menu is the most "manual" of the three, meaning the user must take a deliberate, specific step to fire the action rather than simply mousing over or clicking a mark.
When a dashboard action is set to Menu, Tableau surfaces that action as a clickable link inside the mark's tooltip. So to run the Highlight Customer History action, the user must first hover over or click a customer mark to reveal its tooltip, then click the named action link — Highlight Customer History — that appears within that tooltip. That's exactly what A describes, making it the correct answer.
B is wrong because double-clicking a mark does not automatically execute Menu actions; double-clicking typically performs other functions like drilling into data or entering edit mode. C is wrong because Menu actions appear inside the mark's tooltip, not in a right-click context menu on the target worksheet — that's a common mix-up. D is wrong because hovering and waiting does not trigger a Menu action; that behavior describes Hover actions, which fire automatically when your cursor rests on a mark.
A helpful memory device: think of Menu = tooltip menu. Any time you see "Menu" as the run trigger, picture a user opening the tooltip and clicking a link inside it. On the Tableau exam, questions about action triggers frequently test whether you can match the trigger type to the precise user gesture required.
- What is the most appropriate correction?
Answer: Choose Selected Fields and explicitly map Customer Name in the source to Client Name in the target.
When Tableau executes a highlight action using All Fields, it matches values by looking for fields with identical names across the source and target worksheets. If the field names differ — even when the underlying values are the same — Tableau cannot make the connection automatically. This is exactly the scenario described: Customer Name and Client Name hold equivalent data, but their names don't match, so the All Fields option silently fails.
The fix is to switch from All Fields to Selected Fields, which lets you explicitly pair Customer Name (source) with Client Name (target). Tableau then knows to use those two fields as a matched pair regardless of the name difference. That's why D is correct — it directly addresses the root cause by mapping the mismatched field names to each other.
A is wrong because renaming the worksheet titles has no effect on field name matching. Highlight actions care about field names within the data, not the names of the sheets themselves. B is a misconception — placing a field on Color encodes it visually, but Tableau doesn't use Color shelf assignments to infer that two differently named fields represent the same dimension for action purposes. C is incorrect on two counts: filter actions have nothing to do with resolving this issue, and the premise is false — highlight actions can operate across worksheets with different field names, provided you use Selected Fields mapping.
As a study tip, remember this distinction: All Fields = automatic name-based matching, Selected Fields = manual cross-field mapping. Any time a question describes mismatched field names between action source and target, Selected Fields is almost certainly the right tool.
- How should the highlight action be modified?
Answer: Use Selected Fields and retain only the Region-to-Region mapping in the highlight action.
Highlight actions in Tableau let you control which fields drive the emphasis on target sheets. The key insight is that every field you include in a highlight action's "Selected Fields" mapping acts as an additional filter — marks must match on all listed fields to be highlighted. So when you want to broaden a highlight (not narrow it), you remove fields rather than add them.
In this scenario, the current action maps both Region and Category. When a user clicks East–Furniture, Tableau highlights only marks where Region = East and Category = Furniture — exactly the behavior the requirement wants to eliminate. The fix is straightforward: keep only the Region-to-Region mapping and remove Category. Now clicking any East mark highlights every East mark in the target sheet, regardless of category. That's option C, and it's the correct answer.
Option A is wrong because the trigger (Select vs. Hover) controls when the action fires, not which fields are matched. Switching to Hover changes the interaction model but leaves both field mappings intact, so the scope of highlighting doesn't change. Option B is a trap — "All Fields" tells Tableau to use every shared dimension between the worksheets, which would actually add more constraints rather than loosen them, making the match potentially even more restrictive. Option D is pure misdirection; reversing a mapping isn't a real configuration option, and the goal is to include all categories, not exclude a specific one.
A useful rule of thumb: fewer fields in a highlight action = broader highlighting. Whenever a requirement asks you to widen the scope of emphasis, look for fields to remove from the mapping, not options to add or change.
- What is the expected state of the sales chart after the pointer moves away?
Answer: The chart remains filtered to East, while the temporary hover highlighting ends when the pointer leaves.
When Tableau dashboard actions coexist, each action type operates independently according to its own trigger — hover and select are separate events with separate lifecycles, so you must track them individually rather than treating them as a single interaction.
Here's what happens step by step: the highlight action fires on Hover, illuminating East in the sales chart. When you click East, the filter action fires on Select, narrowing the chart to East's data. When the pointer moves away, the hover event ends — so the highlight clears — but the click selection is still active. The filter action persists because Select remains engaged until you explicitly clear it (clicking elsewhere or using the "X" on the filter). The result is a chart filtered to East with no hover highlight applied, which is exactly what D describes.
A is wrong because it claims East stays highlighted after the pointer leaves. Hover highlights are temporary by definition — they end when the hover ends, regardless of whether a selection is also active. B gets the filter behavior completely backwards: moving the pointer away clears the highlight, not the filter selection. Selections persist independently of hover state, so the chart would not show all regions. C correctly identifies that the filter persists, but claims the hover highlight becomes "permanently applied" — hover highlights are never permanent; they always clear when the pointer leaves the source mark.
A useful mental model for the exam: think of hover actions as a flashlight (on only while you're holding the button) and select actions as a light switch (stays on until toggled off). When both are active simultaneously, turning off the flashlight doesn't flip the switch.
- Which target marks will be highlighted?
Answer: All target marks from East or West, because Region is the only field used for matching.
When a highlight action is configured in Tableau, the selected fields determine the matching logic between source and target marks. This question tests whether you understand that Tableau uses only the mapped fields — not the full combination of all dimensions — when determining which target marks to highlight.
Since Region is the only field mapped in the highlight action, Tableau extracts just the Region values from the multi-selection: East (from East–Furniture) and West (from West–Office). It then highlights every target mark where Region is either East or West — regardless of what sub-category or other dimension those marks carry. That makes C the correct answer: all target marks from East or West get highlighted.
A is tempting because it sounds precise, but it misunderstands how field mapping works. Tableau doesn't preserve the full source combination (East+Furniture, West+Office) when only Region is mapped — the sub-category dimension is simply ignored in matching. D makes the opposite mistake, treating the multi-selection as an intersection rather than a union; Tableau highlights marks that match any of the selected values, not only those satisfying all conditions simultaneously. B invents a "first region" priority rule that doesn't exist in Tableau — multi-selections don't have a hierarchy, and both selected Region values are used equally.
A good rule of thumb: the mapped fields in a highlight action act like a filter on those fields only. Whatever other dimensions exist in the source selection are dropped. When you see a question about highlight or filter actions, immediately ask yourself, "Which fields are mapped, and what values do those fields take in the selection?" That's all Tableau cares about.
- What should the user expect in the target worksheet?
Answer: No target mark is highlighted because the target filter has already excluded every West mark.
Whenever you see a question about Tableau actions, ask yourself: does this action override the view's existing filters, or does it only work within the already-filtered data? That distinction is everything here.
Highlight actions in Tableau are purely visual — they illuminate matching marks without touching filters or modifying what data is shown. Crucially, highlight actions can only highlight marks that are already visible in the target view. If a mark has been filtered out, it simply doesn't exist in the rendered view for the highlight action to find. Since the target worksheet is filtered to show only East and Central, West marks are completely absent from that view. When you hover over West in the source, Tableau looks for West marks in the target to highlight — and finds none. The result is that nothing gets highlighted in the target, which makes A correct.
Choice B describes a behavior that would require the highlight action to temporarily remove a filter and redraw the view — that's not how highlight actions work. They never alter filter state. Choice C introduces a logical inversion that Tableau doesn't support; highlighting the "alternatives" to a hovered value has no basis in how highlight actions function. Choice D imagines the action dynamically expanding the filter scope, which would only be possible with a filter action set to "Show only relevant values" — and even then, not in this directional way.
A good rule of thumb: highlight actions respect filters; they do not override them. If a mark is filtered out, no action can highlight it without first changing that filter separately.
- Which dashboard configuration best satisfies the requirement?
Answer: Add a hover highlight action from the map to the bar chart and map State between the two worksheets.
When a question asks you to "emphasize" related marks while keeping all data visible, that's your signal to think about highlight actions rather than filter actions. Filters remove data from view; highlights dim non-matching marks while leaving them present — which is exactly what "preserving every bar and its original percent-of-total calculation" demands.
B is correct because a hover highlight action from the map to the bar chart does precisely this: hovering over a state visually emphasizes the related sub-category bars without removing any records. Mapping the State field between the two sheets tells Tableau which marks to highlight — the action needs a shared field to know what "related" means across different levels of detail.
A falls into the classic filter-vs-highlight trap. A filter action, even with "Show All Values" on hover end, would still remove bars during the hover itself, temporarily distorting the percent-of-total values. The calculation would not be preserved in the moment the user is hovering.
C reverses the direction of the action — it goes from the bar chart to the map, not from the map to the bar chart. The requirement is that hovering a state drives behavior in the bar chart, not the other way around. Direction matters.
D uses a set action, which ultimately filters the bar chart to only the records in the set. Like A, this removes marks rather than dimming them, breaking the percent-of-total calculation for all remaining bars.
The study tip to carry forward: whenever a requirement says "preserve all values" or "keep all marks visible," highlight actions are almost always the right tool — filter and set actions both reduce what's displayed.
- What happens when a user hovers over a region mark in KPI Summary?
Answer: No action runs because KPI Summary is not configured as a source worksheet for the action.
When working with Tableau actions, the most important concept to internalize is that source worksheets trigger actions; target worksheets receive them. The direction of data flow is strictly one-way based on how the action is configured — hovering or selecting in a source sends a signal to the targets, never the reverse.
In this scenario, the hover highlight action has Sales Map as its sole source and KPI Summary and Monthly Trend as its targets. This means only hovering over a mark in Sales Map will fire the action. When a user hovers over KPI Summary, they are interacting with a target sheet — and target sheets have no triggering power in this action. So D is correct: no action runs because KPI Summary isn't a source.
Answer A is tempting because KPI Summary and Monthly Trend share the same action, but being a co-target doesn't give a sheet any triggering ability. Targets only receive highlights; they don't propagate them. Answer B describes a fictional "reverse trigger" concept — Tableau actions don't bounce back from targets to sources. There's no bidirectional behavior unless you explicitly configure a separate action with the source and target roles swapped. Answer C misunderstands the role of the Region field mapping. Mapping Region across worksheets simply defines what gets highlighted when the action fires — it does nothing to define who can fire the action.
A reliable study tip: whenever a Tableau action question describes a user interacting with a specific sheet, your first move should be to check whether that sheet is listed as a source. If it isn't, the action simply won't fire.
- Which statement best describes the effect of disabling the tooltips?
Answer: The Hover action can still run, but users cannot access the Menu action's command through the disabled tooltip.
When a question involves tooltips and dashboard actions, you need to think carefully about how each action type gets triggered — and specifically, which ones depend on the tooltip UI to function.
In Tableau, the Menu action trigger works by placing a clickable command link inside the tooltip popup. This means if tooltips are disabled on the source worksheet, that popup never appears, and there's simply nowhere for the Menu action's link to live. The user has no way to invoke it. The Hover action, by contrast, fires automatically when the user mouses over a mark — it doesn't require the tooltip to display anything, just the hover gesture itself. So disabling the tooltip removes the visual popup but leaves the hover gesture intact, meaning the Hover highlight action still executes. This makes C the correct answer.
A is tempting because it sounds logical — actions do have independent configurations — but it ignores the critical dependency that Menu actions have on the tooltip container to surface their link. They aren't truly independent in practice.
B overstates the impact. Tableau doesn't need to display a tooltip to "identify" a mark; mark selection and hover detection happen at the rendering layer, not the tooltip layer. Disabling tooltips doesn't blind Tableau to which mark you're interacting with.
D gets things exactly backwards. It's the Menu action that loses its trigger mechanism when tooltips are disabled, not the Hover action.
A useful rule of thumb: Menu actions live inside tooltips; Hover actions live on the mark itself. If the tooltip is gone, Menu has no home — but Hover still works.
- Which approach is most likely to produce reliable highlighting?
Answer: Create a string-typed calculated field from Client ID in the target data source, then use Selected Fields to explicitly map Account ID to that calculated field.
When working with highlight actions across multiple data sources in Tableau, the critical concept to understand is data type matching. Tableau's action mappings are strict about types — a string field and an integer field will not reliably match each other, even if their values look identical (e.g., "123" vs. 123). The solution is to ensure the fields being mapped share the same data type before the action compares them.
That's exactly why B is correct. By creating a calculated field in the target data source that converts Client ID (integer) to a string — using something like STR([Client ID]) — you produce a field whose type matches Account ID. When you then use Selected Fields to explicitly map Account ID → that calculated field, Tableau has a clean, type-consistent comparison to work with, producing reliable highlighting.
A is tempting because "numerically equivalent" values seem like they should match, but Tableau does not automatically coerce types in action field mappings. This is a common misconception — the engine won't silently cast "123" (string) to 123 (integer) for you during the highlight comparison.
C is wrong on two counts: All Fields doesn't apply any type conversion, and Tableau doesn't dynamically convert target fields to match source types during highlight evaluation. All Fields simply tries to match fields by name across sources, type mismatches and all.
D is a fabricated behavior. The action trigger (Hover, Select, Menu) controls when the action fires — it has no effect on the matching algorithm or type tolerance used during field comparison.
Study tip: Whenever a question involves cross-source actions with mixed data types, your first instinct should be to normalize types using a calculated field before mapping — don't rely on Tableau to resolve type mismatches automatically.
