Tableau / Intermediate: calculation and interaction scope / Lesson 11
Parameters, sets and controlled scenarios
Use typed workbook inputs and membership sets deliberately, distinguishing a parameter value from an actual filter or authorization rule.
On this page
Lesson goals
- Explain parameter type, domain and calculation use.
- Distinguish parameters from sets and filter selections.
- Define action, clearing and multi-selection behavior.
Define the workbook input
A parameter holds a workbook value such as a number, date or string and can replace a constant in a calculation, filter rule or reference line. Merely showing its control does not make data change. Define type, allowed values, default and every dependent expression. A threshold parameter needs a documented row or aggregate comparison, not an unexplained number. A metric selector can choose Sales or Profit while preserving the same source population. Treat these as controlled analytical inputs rather than credentials or security boundaries; a user-selected parameter must not decide which private data they are authorized to see.
Read a metric selector
The first expression assumes a string parameter named Metric with allowed values Sales and Profit. It returns the corresponding aggregate and is intended to show 60 or 24 for the fixture. This is a calculated-field fragment, not a parameter created by code. The view title, axis and tooltip must also explain the selected unit and business definition. Choosing a percentage in another branch would need compatible formatting and aggregation semantics; a selector that silently changes units can mislead even when each branch is mathematically correct. Define fallback behavior for unexpected parameter values.
CASE [Metric]
WHEN "Sales" THEN SUM([Sales])
WHEN "Profit" THEN SUM([Profit])
END
Assume the Metric parameter and source fields exist. Intended 60/24 results are derived from the synthetic fixture; no parameter or calculation is executed.
Distinguish set membership
A set represents membership of dimension members under its definition, which can be used for in/out comparisons. It is not the same as one scalar parameter value or a list of currently visible marks. Set actions and parameter actions have different target and update semantics. Choose them from the interaction question and review supported behavior in the selected product/version. A top-product set can change when its population changes, so preserve the ranking and filter contract. Do not assume a saved set definition is a frozen historical snapshot unless the design explicitly guarantees that meaning.
Trace selection and validation
The second program selects an approved metric from a tiny dictionary and rejects an unexpected name with an explicit message. It models a domain check, not Tableau parameter validation or action execution. Parameter actions need a source field or aggregation and defined behavior for multiple selected marks and clearing. If several selected products supply different values, choose a documented aggregation or prevent the ambiguous interaction. Dynamic parameter features also have update timing and source considerations; do not promise that a domain always refreshes immediately after every source change without checking the supported configuration.
metrics = {"Sales": 60, "Profit": 24}
for selection in ("Sales", "Margin"):
if selection in metrics:
print(metrics[selection])
else:
print("unsupported metric")
60
unsupported metric
Sales returns 60 and unknown Margin is rejected. No workbook input or user identity is read.
Review the complete input contract
Test defaults, each allowed value, an invalid value, multi-selection and clearing where actions are involved. Check all sheets using the parameter, because a workbook-level input can affect more than the visible chart. Verify labels and units along with results. This course creates no parameter, set or action and accesses no GUI. Its dictionary program proves a small selection rule only. A complete handoff names domain, update timing, dependent expressions and reader-visible state, keeping controlled scenario exploration separate from real data modification or an authorization mechanism.
Common errors and fixes
Showing a parameter control is expected to filter data
- Why it happens
- No dependent calculation or filter rule uses the value.
- How to fix it
- Define the intended dependency and apply it at the correct grain.
- Prevent it next time
- Trace parameter value to every affected field.
A metric selector changes units without updating labels
- Why it happens
- Presentation retained the previous metric contract.
- How to fix it
- Align titles, axes, formatting and tooltip definitions with selection.
- Prevent it next time
- Review every branch as a complete analytical state.
Multiple marks supply an ambiguous parameter action value
- Why it happens
- Source aggregation and clearing behavior were not designed.
- How to fix it
- Choose a documented single value or constrain the interaction.
- Prevent it next time
- Include multi-select and clear cases in acceptance.
Check your understanding
1. Why does a parameter named Threshold not filter rows by itself?
Show worked solution
It stores a value. A calculation, filter rule or other supported element must consume it. Define whether the comparison applies to each line or an aggregate mark and where the result is used. The control alone cannot establish scope or security.
2. What should change visibly when a selector switches Sales 60 to Profit 24?
Show worked solution
The displayed definition, title, axis unit and tooltip should identify Profit and its approved calculation. Keep the same population unless the contract says otherwise. A changed number with a stale Sales label can be analytically wrong for the reader even when the underlying branch computes 24 correctly.
Key takeaways
- Parameters need explicit consumers and allowed domains.
- Actions and sets require membership, update and clearing contracts.