When should I use a relationship instead of a join?

Start with a relationship when tables have different levels of detail and you want Tableau to retain each table's grain until a view calls for fields from both. Use a physical join when you need one row-level table and understand how matching, unmatched rows, and duplicate keys will affect it. For example, joining one customer row to three order rows repeats the customer value three times; summing that repeated value would overstate it.

Why does a measure change when I add a dimension to a view?

The new dimension divides the view into smaller groups, and Tableau aggregates the measure within each group. If sales of 20, 30, and 50 belong to two regions, the original total is 100. Adding Region may produce marks of 50 and 50. The source rows have not changed; the level at which Tableau displays their aggregate has.

How do a regular calculation and a quick table calculation differ?

A regular calculated field defines a value from fields and functions. A quick table calculation operates on values already present in the view and depends on its addressing and partitioning. If three displayed monthly sales values are 10, 20, and 30, a running total across Month displays 10, 30, and 60. Changing the calculation's direction or the dimensions in the view can change those results.

Salesforce Tableau Desktop Foundations Study Guide

Start with concept 1 Choose a topic

A useful Tableau view begins with a question about the data: what does one row represent, which fields identify categories, and which values should be aggregated? From there, you choose a connection and data model, build a chart that fits the comparison, and check whether filters or added dimensions change the answer. This guide follows that workflow through connections, relationships and joins, visual analysis, calculations, dashboards, and sharing. Each concept pairs a decision rule with a small worked example so you can trace a result back to its source rows. The focus is Tableau Desktop behavior covered by the Salesforce Certified Tableau Desktop Foundations assessment using Tableau 2022.3.

Connecting to and Preparing Data

1. Connect to files and servers

Start with where the data lives. For a local spreadsheet, choose a file connection, open the workbook, and select the sheet that contains the records you need. For a database, choose the appropriate server connector, supply the required connection details, and select a table or view. The Data Source page is your first check: inspect the table name, field names, detected types, and a few rows before building a worksheet. A sheet named Notes may contain commentary rather than order records, even when it sits beside Orders in the same workbook. Confirm that each row represents the expected kind of record. The official examination guide includes connection choices in the Connecting to and Preparing Data domain.

Worked example: A spreadsheet contains Orders and Notes. Orders has three records and the four fields Order ID, Order Date, Region, and Sales. Connect through the file path, select Orders, and confirm all four fields and three rows in the preview. If those records instead lived in a database, use its server connector and select the Orders table there.

Watch the distinction: Choosing a connector only because the data contains tables misses the key distinction: a spreadsheet is a file, while a database table is reached through its server connection.

Reference: [1]

2. Live connections and extracts

A live connection sends queries to the underlying source when a view needs data, subject to the source's availability and Tableau's query behavior. An extract is a stored snapshot that Tableau queries instead. This distinction determines whether a later change in the source can appear in the view without rebuilding the connection. A new live query may see a newly committed record; an extract cannot include it until the extract is refreshed. Live does not promise that every screen redraw immediately reflects a source edit, since a view may need a fresh query. Extracts can improve portability or query performance in some situations, but they introduce a refresh step and storage. For more ways to check these distinctions, use the Tableau Desktop Foundations practice questions.

Worked example: A view initially counts three orders. The source receives one more order, bringing its count to four. A fresh live query can show four because it reads the source. An extract created when there were three still counts three. After a successful refresh that includes the new order, its count becomes four.

Watch the distinction: Calling an extract a live copy leads to stale conclusions. Its contents reflect the last successful extraction or refresh, even if the underlying database has changed since then.

Reference: [1]

3. Extract scope and refresh

An extract filter defines which source rows qualify for storage in an extract. Refreshing obtains a newer version of that selected data; it does not normally discard the filter. Think of these as two separate questions: which rows are eligible, and when were eligible rows last copied? To diagnose a missing record, first check whether it satisfies the extract filter, then check whether a refresh occurred after the record entered the source. If the filter uses a date condition, inspect its exact meaning rather than assuming it follows a moving calendar window. An extract can also contain fewer rows for other reasons, such as source permissions or an unsuccessful refresh. Compare source and extract counts at the same grain before concluding that data was lost.

Worked example: Suppose an extract filter retains orders dated in 2022. The source initially has two 2022 orders and one 2021 order, so the extract holds two. The source then gains one order from each year. After refresh, the extract holds three 2022 orders and still excludes both 2021 orders. Refresh changed recency, not scope.

Watch the distinction: Refreshing an extract does not automatically widen its selection. A newly added source row that fails the existing extract filter remains absent after a successful refresh.

Reference: [1]

4. Saved data source metadata

A saved Tableau data source can retain connection information and field metadata, such as renamed fields, data types, default formats, and default aggregations. That saves repeated setup when another workbook uses the same source. Treat metadata and data availability separately. A saved source definition may still point to a database that requires access or a file path the recipient cannot reach. A packaged form can carry supported local data, but a plain source definition should not be assumed to contain every underlying record. When reusing a source, inspect its fields and test the connection before trusting a worksheet's values. This is especially useful when a team wants consistent names and display formats across workbooks while the records themselves continue to change at their original location.

Worked example: Rename Revenue to Sales and set its default number format to currency, then save the data source. A second workbook using that saved source can show the Sales name and currency formatting. If the source still points to a local file that has moved, those retained settings do not make the file available; the connection must be repaired.

Watch the distinction: A saved data source is not automatically a self-contained copy of the records. It can preserve useful field settings while still depending on access to its underlying connection.

Reference: [1]

5. Multiple connections

A workbook can use more than one connection when the required fields come from different places, such as orders in a spreadsheet and targets in a database. Before relating or joining them, identify the question's comparison grain and a key shared by both tables. If targets contain one row per Region, regional order sales can be compared with each region's target. Check the key's values and uniqueness: spelling differences create unmatched records, and duplicate target rows can create unexpected totals in a physical join. Start with a small view showing Region, order sales, and target, then verify one known region by hand. Framing the needed comparison before selecting a key is also a core business analysis habit discussed in the certified business analysis professional cbap guide.

Worked example: Orders is a spreadsheet with East sales of 20 and 30 and West sales of 10. Targets is a database table with East 60 and West 15. Connect to both and match Region. East sales are 20 + 30 = 50 against the East target of 60, a shortfall of 10; West is 10 against 15.

Watch the distinction: Matching tables merely because both have a text field can connect unrelated rows. Verify that the key represents the same entity and level of detail in each source.

Reference: [1]

6. Relationships preserve table grain

A relationship links logical tables while allowing Tableau to consider each table's level of detail for the fields used in a view. It is useful when one table describes customers and another records their many orders. The customer credit limit belongs to the customer grain; order sales belong to the order grain. Relate the tables on a customer key and test measures from both tables in a view. With a single customer, the limit should represent that one customer rather than being repeated once per order as it would be in a joined row set. Relationships still need valid matching values, and the view's dimensions matter. If a result looks surprising, inspect table grains, key cardinality, and the exact fields in the view before changing the aggregation.

Worked example: Customers has one East customer, C1, with a credit limit of 100. Orders has two C1 rows with sales of 20 and 30. Relating on Customer ID supports an East view with sales of 20 + 30 = 50 and the one customer's limit of 100. The two measures describe different grains.

Watch the distinction: Do not assume a relationship physically flattens both tables into one permanent row set. Its purpose is to let Tableau query the relevant tables for the view.

Reference: [1]

7. Join duplication

A physical join creates rows from matching pairs. If one customer matches two orders, the customer fields appear in both resulting rows. An order-level measure can still sum correctly when each order appears once, but a customer-level measure is repeated and may be overcounted. Predict this before building the view: count how many matches each key has on either side. A one-to-many join multiplies fields from the one side; a many-to-many join can multiply measures from both sides. The data grid, not just the displayed aggregate, helps reveal the cause. If the intended analysis compares measures at different grains, consider a relationship or aggregate a table to a suitable grain before joining. Changing SUM to another aggregation may hide duplication without fixing the model.

Worked example: Customers has one C1 row with Limit 100. Orders has two C1 rows, Sales 20 and 30. Joining on Customer ID produces two rows: (100, 20) and (100, 30). SUM(Sales) is 20 + 30 = 50, but SUM(Limit) is 100 + 100 = 200. The customer's actual limit remains 100.

Watch the distinction: A plausible sales total does not prove the join is safe for every measure. Check whether measures from the one side repeat across matched rows.

Reference: [1]

8. Join types and missing matches

Choose a join by deciding which unmatched records your question must retain. An inner join keeps only rows with matches on both sides. A left join keeps every row from the left table and adds matching right-side fields where available; those fields are null when no match exists. A right join reverses that retention, while a full outer join retains unmatched rows from both sides. Place the table whose complete population matters on the retained side. Also check whether the join key is unique where expected, because join type controls unmatched rows but does not prevent multiplication from multiple matches. A null in a joined field often means no matching record, yet it could also be a null value in a matched record, so inspect the key before interpreting it.

Worked example: Orders contains IDs A and B, while Returns contains only ID B. An inner join on ID keeps B only. A left join with Orders on the left keeps A and B; A has a null return field and B has its return information. Use the left join if the analysis must count all two orders.

Watch the distinction: An inner join can silently remove orders with no return record. If those orders matter to the denominator or total, retain them with an appropriate outer join.

Reference: [1]

9. Unions append rows

A union stacks rows from tables with the same kind of records. It is a natural choice when monthly order tables have compatible columns and you want one longer order table. A join instead matches rows across tables using a key and places fields beside one another. Before unioning, compare column meanings and data types, not just names. A Sales field measured in different currencies would need treatment before its values could be summed meaningfully. Tableau aligns compatible fields, and inconsistent names can produce separate columns with nulls in some rows. After the union, check the row count and inspect which source table each row came from when available. This distinguishes expected stacking from accidental duplication or a missing month's data.

Worked example: January contains two orders and February contains three, each with Order ID, Date, and Sales in the same units. Unioning them yields 2 + 3 = 5 order rows. A join would need matching IDs and would place January and February fields side by side, which would not form a five-order history.

Watch the distinction: A union does not match customer or order keys to enrich existing rows. It appends records, so incompatible column meanings can create a misleading combined table.

Reference: [1]

10. Field names and aliases

A field name labels the column or analytical field, while a member is one value within a dimension. Renaming Region_Code to Region changes how the field appears in Tableau's interface and views; it does not recode each source value. An alias changes the displayed label for a particular dimension member, such as showing Northeast where the stored code is NE. This is useful when codes are correct for the source but cryptic to readers. Check whether all intended members have aliases, especially when new codes arrive later. An alias is a display choice, so do not use it as a substitute for cleaning inconsistent source values or defining a durable mapping. When a calculation or join depends on codes, inspect the underlying values and their data types.

Worked example: A source has the field Region_Code with values NE and SW. Rename the field Region, then give NE the alias Northeast. A view can display the header Region and the member Northeast. SW remains SW until separately aliased. The stored NE value has not become the word Northeast in the source file.

Watch the distinction: Renaming a field does not rename its members. If a view still shows NE under a Region header, assign a member alias or correct the underlying data.

Reference: [1]

11. Correct field data types

Imported values must have the right data type for the operation you intend. Numeric text may look like amounts in a preview, but it behaves as strings until Tableau recognizes or converts it as numbers. A date stored as text likewise cannot reliably support chronological grouping and date calculations. Inspect the data type icon and sample values, then change the type or create a conversion calculation when the values are consistently parseable. Look for currency symbols, separators, blanks, and malformed rows before trusting the conversion. Afterward, validate with a small calculation and check whether any records became null. An identifier made of digits, such as a store code, may still belong as a dimension; numeric storage does not make summing it meaningful.

Worked example: A CSV imports Amount values '12' and '8' as text. Convert Amount to a numeric type after confirming both strings represent plain numbers. The values then total 12 + 8 = 20 amount units. If a third entry is 'unknown', investigate it rather than silently treating the resulting null as zero.

Watch the distinction: Seeing digits in a text field is not enough to trust SUM. Confirm the field's type and inspect conversion failures before interpreting a numeric total.

Reference: [1]

12. Geographic roles

A geographic role tells Tableau what kind of place a field represents, such as City, State, or Country. It helps Tableau generate map coordinates, but a place name alone may be ambiguous. A city can share its name with cities elsewhere, and abbreviations can have several meanings. Provide geographic context using additional fields, then inspect unknown or unexpectedly placed locations before drawing conclusions from the map. Assign roles to the correct fields rather than relying on a suggestive field name. Also check whether the geographic unit matches the question: a city-level mark does not locate an individual street address. A map's placement is a derived interpretation of the supplied geography, so verify unusual results against the records and their state or country values.

Worked example: Two records have City = Springfield. One has State = Illinois and the other State = Massachusetts. Give City and State their geographic roles and use both fields for the map. Tableau can then distinguish the two intended city and state combinations instead of treating Springfield as one unqualified location.

Watch the distinction: A mapped point is not proof that an ambiguous name was resolved correctly. Check state or country context when cities share names or appear in surprising places.

Reference: [1]

13. Field defaults

A field default provides a starting behavior when you add that field to a new view. For a measure, you can set a default aggregation such as AVG and a number format such as currency. Those settings reduce repeated formatting work, but the pill in a particular view remains the authority for what that view calculates. Read AVG, SUM, or another aggregation on the pill rather than inferring it from the field's name or currency symbol. Formatting changes presentation, not arithmetic. Also choose an aggregation that fits the measure's meaning: a typical unit price calls for an average more often than a sum, while total sales commonly calls for a sum. If observations represent unequal quantities, a simple average may not answer a weighted-price question.

Worked example: Set Unit Price to currency format and AVG by default. Two rows priced at 10 and 20 currency units display an average of (10 + 20) / 2 = 15 in a new view. If you change that view's pill to SUM, it displays 10 + 20 = 30 currency units instead.

Watch the distinction: A currency format does not specify how values are combined. Check the aggregation on the pill; AVG and SUM answer different questions even when both display currency symbols.

Reference: [1]

14. Data source filters

A data source filter restricts the rows available through that Tableau data source for worksheets using it. A worksheet filter narrows a particular view and can be applied to other selected worksheets when you choose that scope. Locate the filter before diagnosing a missing region: a source-level restriction cannot be undone by removing a filter from one sheet. Conversely, a sheet-level filter does not necessarily explain why another sheet still shows all regions. Filter order and interactions can affect complex views, so test with a simple count or sum in each worksheet. This distinction matters when building dashboards: two views that seem to use the same data may disagree because one has an additional worksheet filter. Keep the intended audience and question in mind when setting scope.

Worked example: The source has East sales of 40 and West sales of 60. A data source filter retaining East makes 40 available to each of two worksheets using that source. Remove the source filter and apply an East worksheet filter only to the first sheet: it shows 40, while the second can still show 40 + 60 = 100.

Watch the distinction: Removing a worksheet filter cannot restore rows excluded by a data source filter. Check the filter's location and application scope before assuming data is missing.

Reference: [1]

Exploring and Analyzing Data

15. Bars and stacked parts

Bars support comparisons across categories because their lengths share a baseline. Add a second categorical field to Color when both each component and the overall category total matter. Stacking then places component segments within each category's bar, making the total visible while showing its composition. Use a consistent color assignment for the same component across bars. Read the total by adding segments, not by reading an individual segment's endpoint as its own value. If the question is mainly about precise component comparisons across categories, side-by-side bars or a table may be easier because stacked segments often lack a common baseline. Check that the measures are additive and share units; stacking percentages or unrelated measures can mislead. A clear title and legend make the grouping understandable.

Worked example: East has Product A sales of 30 and B sales of 20, totaling 50. West has A sales of 35 and B sales of 5, totaling 40. Stacked bars show East ahead by 10 sales units, even though West's A segment exceeds East's by 5. East leads because its B segment is 15 larger.

Watch the distinction: A taller stack does not mean every component is larger. Compare matching colored segments separately, then add them when interpreting each bar's total.

Reference: [1]

16. Lines over time

A line view connects ordered time positions so you can see changes between periods. Put a date field at the intended level, such as month, on the horizontal axis and the measure on the vertical axis. Decide whether months from different years should be combined or remain separate time points. A full month date preserves chronological sequence; a repeating month name can merge Januaries from several years. Keep the vertical scale and aggregation visible when interpreting changes. The slope shows direction and relative rate across displayed intervals, but a line between monthly totals does not reveal what happened on individual days. Check for missing months too: a gap in records is different from a measured zero. State changes in measure units or percentages with a clear denominator.

Worked example: Monthly sales are January 10, February 15, and March 12 sales units. The line rises by 15 - 10 = 5 from January to February, then falls by 12 - 15 = -3 from February to March. March remains 12 - 10 = 2 units above January despite the latest decline.

Watch the distinction: A line between monthly marks does not prove sales changed smoothly during each month. It connects period summaries, so inspect finer dates before describing daily behavior.

Reference: [1]

17. Scatterplots for paired measures

A scatterplot places one measure on each axis and uses a mark for each entity you want to compare. Add Store, Customer, or another identifier to Detail so Tableau produces one mark per entity instead of aggregating all records into one point. Decide how repeated records for an entity should be summarized before plotting; SUM of advertising and SUM of sales might suit store totals, while averages answer another question. The pattern can suggest association, clusters, or unusual cases. Read both axis units and inspect exceptions rather than treating a general upward tendency as universal. A scatterplot alone does not establish that one measure causes the other. If marks overlap, tooltips or labels can help identify the entities behind apparent clusters.

Worked example: Three stores have advertising and sales pairs, in the same currency units: Store A (10, 40), B (20, 60), and C (30, 35). Put advertising on the horizontal axis, sales on the vertical, and Store on Detail. B exceeds A in sales by 20, but C spends 10 more than B and sells 25 less.

Watch the distinction: Without an entity field on Detail, Tableau may aggregate three stores into one mark. Check the mark count before interpreting a relationship between measures.

Reference: [1]

18. Symbol maps

A symbol map places marks at geographic locations and can encode a measure through mark size or color. Set the appropriate geographic roles first, then choose the geographic grain: one mark per city requires a city identifier and enough context to resolve it. Size helps compare magnitudes, though people judge area less precisely than bar length. Color can show categories or a numeric scale, but its legend must state which. Check whether multiple records for a city are aggregated into one mark and which aggregation is used. A large symbol may reflect total sales, not more stores or more observations. Inspect overlapping marks and unfamiliar placements before interpreting regional patterns. For precise ranking or small differences, pair the map with a table or bar view.

Worked example: City A has sales of 10, City B 30, and City C 20 sales units. Plot one symbol per city and size by SUM(Sales). B should have the largest symbol, C the middle size, and A the smallest. B's sales are 30 - 10 = 20 units above A's, which a tooltip can state precisely.

Watch the distinction: A symbol's position describes location; its size describes the chosen measure. Do not read a larger sales symbol as a larger geographic area or higher record count.

Reference: [1]

19. Density maps

A density map emphasizes where many geographic marks cluster. Each underlying point contributes to a continuous visual concentration, so overlapping points become easier to see than they would as identical symbols piled on top of one another. Choose it when the question concerns spatial concentration, such as where deliveries are frequent. Check whether marks represent individual events or aggregated locations: ten orders at one recorded coordinate and ten distinct nearby stops can look similar but describe different data collection. Density color and intensity should be read through the legend and the map's scale. This view is less suited to reading exact values for a specific point or ranking a few cities. When individual identities matter, inspect a symbol map or a detailed table alongside it.

Worked example: Suppose ten deliveries have distinct coordinates within a small downtown area, while two deliveries are far apart outside it. A density map shows its strongest concentration downtown, reflecting ten nearby points versus the isolated pair. It does not mean either remote delivery has zero activity. A symbol map better identifies the two individual remote locations.

Watch the distinction: A dense patch is not an exact count or automatically the largest sales total. It indicates concentration according to the marks and weighting used in the view.

Reference: [1]

20. Text and highlight tables

A text table puts a value in each intersection of the displayed dimensions, making exact lookup straightforward. A highlight table keeps that grid and adds color so high, low, or unusual cells stand out faster. Set the rows and columns to the intended categories, put the measure on Text, and use Color when you want a pattern cue. Inspect the aggregation and color legend: the darkest cell may be the largest sum, but that could reflect more underlying records rather than a higher typical value. Make missing combinations distinguishable from measured zeros. For a small matrix, retain readable numbers even when color is added; color alone makes close values hard to judge and may be inaccessible to some readers. Use a consistent color scale when comparing separate views.

Worked example: A Region by Product grid has East A = 5, East B = 8, West A = 12, and West B = 3 sales units. A text table lets you read all four values. A highlight table colors the 12 cell most strongly on an increasing scale. West A exceeds East A by 12 - 5 = 7 units.

Watch the distinction: The strongest color does not replace the number or explain why it is high. Check the legend, aggregation, and cell value before drawing a conclusion.

Reference: [1]

21. Combined axes

When two measures use the same units, a shared axis lets you compare their positions directly. In Tableau, place the measures in Measure Values and use Measure Names to distinguish them by color or another mark property. Check that both measures refer to the same period and level of detail before reading the gap. A monthly sales total and a monthly target can share a scale; a daily sales value beside a monthly target would invite a false comparison. Keep the axis units and zero point visible when bar lengths carry the comparison. If the measures have very different ranges, the smaller series may be hard to see, but changing to separate axes changes how the viewer must read the chart. The official Tableau Desktop Foundations examination guide includes combined axes among its visualization topics.

Worked example: Suppose Sales is 40 units and Target is 50 units for April, with both measured at the monthly level. Place both on one axis marked in units. Their positions show a shortfall of 50 − 40 = 10 units. Sales reached 40 ÷ 50 = 80% of target, if target is the intended denominator.

Watch the distinction: A shared axis does not make unlike measures comparable. If one pill is dollars and another is a percentage, the distance between their marks has no common unit.

Reference: [1]

22. Dual axes

A dual-axis view gives each measure its own scale while placing their marks in the same plotting area. It can reveal whether two trends rise and fall together when their units or magnitudes differ. Read the left and right axis titles before interpreting either line: the same vertical height can represent entirely different values. In Tableau, each axis has a separate Marks card, so one measure can be a bar and the other a line. Synchronizing axes is useful only when the measures have compatible units and the shared scale answers the question. Otherwise, retain clear separate labels and avoid describing the distance between marks as a numeric difference. A dual-axis chart also deserves a check for misleading visual alignment, since changing an axis range can make unrelated movements appear to coincide.

Worked example: For April, Sales is 1,000 dollars and Margin is 20%. Put Sales on a dollar axis and Margin on a percentage axis. A sales mark at 1,000 and margin mark at 20% may appear at similar heights, but subtracting 20 from 1,000 is meaningless. Across months, compare each series with its own prior values.

Watch the distinction: Matching heights on two axes do not mean matching quantities. Check each axis title and range before claiming that the measures are equal or differ by a visible gap.

Reference: [1]

23. Groups combine members

A group combines selected members of a dimension into a named category. Build one when the analysis needs a broader label while keeping the original field available for detailed views. Tableau assigns each selected member to the group; other members may remain separate or be placed in an Other category, depending on how the group is configured. Aggregated measures then roll up across the records assigned to each displayed group. Check whether the grouped members are mutually appropriate for the business question: a convenient selection on screen does not establish that the categories are conceptually equivalent. Groups can also help clean inconsistent labels, though aliases may be simpler when two labels are merely alternate names for one member. The result is a categorical field, so it changes which marks appear and how their underlying records are summed or averaged.

Worked example: North has sales of 20 units, South has 30, and West has 15. Select North and South and create a group called Domestic. With SUM(Sales) in the view, Domestic is 20 + 30 = 50 units, while West remains 15. The group changes the displayed category, not the three underlying sales values.

Watch the distinction: A group does not simply recolor members or create an in/out test. It creates a category that can aggregate the records of several original dimension members.

Reference: [1]

24. Sets define membership

A set identifies members of a dimension as In or Out. It is useful when a question asks which members qualify, such as stores whose aggregate sales exceed a chosen amount. A fixed set records selected members; a condition-based set evaluates a rule, so its membership can change when the underlying values change. Decide what the condition is measured over, including its aggregation and any relevant filters, before interpreting membership. A group instead creates named categories from members, which is suitable for a label such as Domestic. A set can drive a filter, color distinction, or calculation while retaining the in/out distinction. For a threshold example, specify whether “sales above 50” means each transaction or SUM(Sales) per store; the latter determines store membership from totals, not individual rows.

Worked example: Assume one sales total per store: A has 40 units, B has 60, and C has 80. A set conditioned on SUM(Sales) > 50 puts B and C In and A Out. If A's total later rises from 40 to 55 units and the condition is reevaluated, all three stores are In.

Watch the distinction: Do not treat a conditional set as a permanently handpicked list. Its members can change when data changes, and its threshold applies at the specified member aggregation.

Reference: [1]

25. Hierarchies support drill-down

A hierarchy arranges dimensions from a broad level to a more detailed one, such as Region followed by City. Expanding a member adds the next dimension to the view, so the measure is partitioned into finer groups. Collapsing it restores the broader summary. The levels should describe a sensible path: each city should belong to the appropriate region in the data, or the expanded view may produce confusing repeated names. A hierarchy does not repair incorrect geographic assignments or add missing rows. Check the measure's aggregation as you drill. SUM(Sales) at the region level should equal the sum of its city totals when the cities partition the same records, while averages need to be recomputed from the underlying observations. Use the plus and minus controls to navigate detail while keeping the same analytical question in view.

Worked example: East contains City A sales of 20 units and City B sales of 50 units. At Region level, SUM(Sales) for East is 20 + 50 = 70 units. Expanding East in a Region-to-City hierarchy displays A at 20 and B at 50. Their sum checks the original East total.

Watch the distinction: Drilling down does not create additional sales. It redistributes the same records among more marks, provided the hierarchy levels and data relationships are defined correctly.

Reference: [1]

26. Dimension and measure filters

A dimension filter selects categorical members or records before the view displays its aggregates. A measure filter can instead test an aggregate such as SUM(Sales) for each displayed group. Read the aggregation shown in the filter dialog and the dimensions in the view to understand which totals are tested. Filtering Region to East explicitly excludes West. Filtering SUM(Sales) above 40 in a view grouped by Region evaluates each region's sales total and keeps only qualifying regions. Those two operations can produce the same visible marks for one dataset, yet respond differently to new records or changed thresholds. A measure filter on individual order values would be a different question again. When a result seems surprising, inspect the filter type, its selected values or range, and the view's level of detail before assuming Tableau changed the source data.

Worked example: East has orders of 20 and 30 units; West has one order of 10. A Region dimension filter set to East leaves East's SUM(Sales) at 50. Without that filter, a SUM(Sales) measure filter above 40 tests East at 50 and West at 10, retaining East alone. Both display 50 here, for different reasons.

Watch the distinction: A SUM(Sales) filter above 40 does not necessarily remove orders below 40. In this region view, it tests each region's aggregate, so East's 20-unit order still contributes.

Reference: [1]

27. Date filters

Date filtering requires deciding whether calendar position or a specific span of time matters. A date-part filter on Month can select March across every year represented in the data. A date range uses full date values, so its start and end can isolate March in one particular year. Relative date filters answer another kind of question, such as a moving period, and change their selected dates as the reference time moves. Inspect the date pill and filter options before choosing: a label that says March may hide records from several years. For a fixed comparison, state whether boundary dates are included and check the source field's date or datetime type. With timestamps, a date-only end boundary may need careful interpretation. The useful diagnostic is simple: if the year matters, preserve it in the filter rather than selecting only a repeating month name.

Worked example: Suppose two orders occurred on 2021-03-10 and 2022-03-10, worth 10 and 20 units. Selecting the March month part keeps both, for 30 units total. Selecting the full date range from 2022-03-01 through 2022-03-31 keeps only the 2022 order, for 20 units.

Watch the distinction: Choosing March from a month-part list does not mean March of the latest year. Month parts repeat annually, so earlier March records can remain in the view.

Reference: [1]

28. Manual and computed sorts

A sort controls the displayed order of dimension members. Choose a measure sort when ranking by performance, and specify both the measure and aggregation used. Descending SUM(Sales) orders categories by their sales totals, which may change as data or filters change. A manual sort preserves a deliberate sequence, such as stages in a workflow or a familiar business order, regardless of current measure values. Alphabetical order is another possibility, but it does not communicate a quantitative ranking. Before reading a sorted chart, look for the sort direction and whether the ranking is global or repeated within panes. Ties may need a secondary rule if their order matters. When comparing several charts, consistent member order can reduce the effort needed to trace a category across views, even if one chart's local measure would suggest a different ranking.

Worked example: Categories A, B, and C have SUM(Sales) of 10, 30, and 20 units. Descending sales order is B, C, A because 30 > 20 > 10. A manual sequence A, B, C instead follows the chosen business order. If C later reaches 35, a computed descending sort moves C first; the manual sequence remains A, B, C.

Watch the distinction: A manually arranged chart is not necessarily ranked by its bar values. Read the sort setting before interpreting first position as best performance.

Reference: [1]

29. Reference lines

A reference line places a benchmark across an axis, making each mark's position relative to that benchmark easy to see. Tableau can calculate a line from a measure, such as an average, or use a specified constant. Its scope matters: a line for the entire table can differ from a separate line within each pane or cell. Choose scope based on the comparison you want. An overall average supports comparison among all regions; pane averages support comparison within separate partitions. Also check what is being averaged. The mean of displayed region totals gives each region equal weight, while the average of underlying transactions gives each transaction equal weight. They can differ when regions have different record counts. Label the line with its value and meaning, then inspect values near it rather than calling a small visual difference significant without supporting analysis.

Worked example: Three region totals are 40, 50, and 60 units. An average of these displayed totals is (40 + 50 + 60) ÷ 3 = 50 units. Put a table-scope reference line at 50: the first region is 10 below, the second is on the line, and the third is 10 above.

Watch the distinction: A reference line labeled Average is not automatically an average of all source rows. Its aggregation and scope determine which values contribute and how they are weighted.

Reference: [1]

30. Quick table calculations

Quick table calculations operate on values in the view after they have been aggregated. Percent of total divides each displayed value by the total over the calculation's partition. Running total adds displayed values in an order, so a month field must run chronologically if the result is meant to accumulate through time. Tableau's addressing and partitioning settings decide which marks the calculation traverses and where it restarts. A calculation across months within each region differs from one across all marks in the table. Check the selected Compute Using direction and any filters that alter the displayed marks. For percent of total, verify that the percentages add to about 100% within the intended partition, allowing for rounding. The Tableau Desktop Foundations practice questions can be used to rehearse identifying that calculation direction from a small view.

Worked example: Monthly sales are January 10, February 20, and March 30 units, totaling 60. Percent of total is 10 ÷ 60 = 16.7%, 20 ÷ 60 = 33.3%, and 30 ÷ 60 = 50.0%, rounded. Running total across Month is 10, then 10 + 20 = 30, then 30 + 30 = 60 units.

Watch the distinction: A running total is not an inherent property of a sales field. Reverse the table calculation's direction or restart it by region, and the displayed sequence changes.

Reference: [1]

31. Histograms and bins

A histogram turns a numeric measure into intervals called bins and counts observations in each interval. It answers how frequently values occur, rather than showing each observation's exact value. Select a bin width and origin that make boundaries understandable, then check how observations on a boundary are assigned. With half-open intervals such as 10 ≤ x < 20, an amount of 20 belongs in the next bin. Small bins can reveal detail but also make a sparse, noisy chart; broad bins can conceal clusters or gaps. A histogram of order amounts usually counts orders, so verify that one underlying row represents one order or use the appropriate distinct count. Filtering the source observations changes the distribution and its counts. When comparing groups, keep bin definitions consistent so differences in bar height reflect data rather than changed interval widths.

Worked example: Four orders have amounts of 12, 18, 21, and 39 dollars. Use bins [10,20), [20,30), and [30,40), each 10 dollars wide. The counts are 2, 1, and 1 orders: 12 and 18 enter the first, 21 the second, and 39 the third. The bar heights sum to four orders.

Watch the distinction: A histogram bar's height is a count of observations in its interval, not the sum of their amounts. The first bar is two orders, although their amounts total 30 dollars.

Reference: [1]

32. Arithmetic calculated fields

A row-level arithmetic calculation evaluates an expression for each source row. For Profit, `[Sales] - [Cost]` produces a value on every record, which Tableau can then aggregate in a view. If each record uses the same units and represents comparable transactions, SUM(Profit) is the combined profit. An aggregate calculation instead operates on already summarized fields, such as `SUM([Sales]) - SUM([Cost])`. For subtraction, these approaches agree over the same records because addition and subtraction distribute. That agreement does not extend to every expression: averaging row margins generally differs from dividing total profit by total sales. Keep aggregation levels consistent within a Tableau calculation and check the level at which a result is needed. A row profit is useful for finding loss-making transactions; total profit answers how a displayed group performed overall.

Worked example: Two orders have Sales and Cost of (20, 12) and (30, 18) dollars. The row calculation gives Profit = 20 − 12 = 8 dollars and 30 − 18 = 12 dollars. SUM(Profit) is 8 + 12 = 20 dollars. Checking aggregates gives SUM(Sales) − SUM(Cost) = 50 − 30 = 20 dollars.

Watch the distinction: Do not assume every formula gives the same answer before and after aggregation. Profit subtraction does here; a row-level percentage averaged across unequal orders can differ from the overall percentage.

Reference: [1]

33. String calculated fields

String calculations transform text according to its characters and position. `LEFT([Order ID], 4)` takes the first four characters of each ID, so it can extract a consistent prefix used as a category. Before grouping on the result, inspect several values, including short IDs, inconsistent case, spaces, and formats that do not follow the pattern. A prefix is only a trustworthy region code if the source's ID convention actually assigns it that meaning. Tableau treats the output as text; a code that looks numeric may still be an identifier rather than a measure to sum. If the source contains several patterns, a fixed four-character extraction can produce misleading categories and may need a different expression or data cleanup. Compare extracted values with known records, then use the new field as a dimension to group marks or filter records.

Worked example: Order IDs WEST-101 and WEST-102 follow a rule in which the first four characters identify region. `LEFT([Order ID], 4)` returns WEST for each. If their sales are 15 and 25 units, placing the extracted code in the view and summing sales gives one WEST mark of 15 + 25 = 40 units.

Watch the distinction: A substring is not automatically a valid business category. If one ID begins with `WEST` and another with a space before `WEST`, the same four-character expression returns different codes.

Reference: [1]

34. Date calculated fields

A date calculation can extract a calendar component for grouping. `DATEPART('quarter', [Order Date])` returns a quarter number from 1 through 4 for each date. This is useful when comparing seasonal positions, but it drops the year from the result: first-quarter records from different years can combine. Preserve Year as another field when the analysis needs each year's quarter separately. Check that the source field is a true date or datetime, because text that merely resembles a date may require conversion before date functions behave as intended. Date components also differ from continuous date values, which preserve chronological placement. For a trend across years, a full month or quarter date value gives each period its own point; a quarter number gives at most four recurring categories. Choose the form that matches the question before interpreting totals.

Worked example: Orders dated 2022-02-10 and 2022-05-10 have sales of 12 and 18 units. `DATEPART('quarter', [Order Date])` returns 1 and 2, respectively, so a quarter view shows Q1 at 12 and Q2 at 18. The Q2 total exceeds Q1 by 18 − 12 = 6 units for these two orders.

Watch the distinction: Quarter 1 by itself does not mean the first quarter of 2022. Without Year in the grouping or filter, first-quarter records from other years can join it.

Reference: [1]

35. Parameters control a value

A parameter stores a selected value that calculations, filters, or reference lines can use. Creating a parameter alone leaves the view unchanged; something in the workbook must read its value. Define its data type and allowed values, then write a calculation such as `[Sales] >= [Minimum Sales]`. Place that result in the view or use it as a filter, depending on whether you want to label or exclude records. Unlike a field filter, a parameter is a single workbook value rather than a list of existing members from one field. Its effect depends on the formula: changing a threshold can alter a boolean flag, a selected measure, or a benchmark line. Check whether the formula compares row values or aggregates, since `[Sales] >= [Minimum Sales]` and `SUM([Sales]) >= [Minimum Sales]` answer different questions.

Worked example: Set Minimum Sales to 50 units and calculate `[Sales] >= [Minimum Sales]` for two records worth 40 and 60 units. The results are false and true. Change the parameter to 35 units: 40 ≥ 35 and 60 ≥ 35 are both true. The rows did not change; only the comparison value did.

Watch the distinction: Showing a parameter control does not automatically filter the data. It needs a calculation or other workbook element that reads the selected value and applies it.

Reference: [1]

36. Totals and subtotals

Totals and subtotals must be read in the context of the measure's aggregation. A subtotal for SUM(Sales) adds the contributing sales records within a group. An AVG(Sales) grand total should represent the average of the underlying contributing records, which may differ from the simple average of the displayed group averages. The difference appears when groups contain unequal numbers of records. Before interpreting a total, identify whether the measure pill says SUM, AVG, COUNT, or another aggregation, and inspect any filters that limit the contributing rows. If the business question requires each region to have equal weight regardless of order count, that is a separate calculation from the average order value across all regions. Subtotals can help navigate a hierarchy, but a single grand total label cannot tell the reader what was weighted. State the unit and denominator in your interpretation.

Worked example: East has two sales records of 10 and 20 dollars, so its AVG(Sales) is (10 + 20) ÷ 2 = 15 dollars per record. West has one record of 90 dollars, so its average is 90. The grand average over all three records is (10 + 20 + 90) ÷ 3 = 40 dollars, not (15 + 90) ÷ 2 = 52.5.

Watch the distinction: A grand average is not necessarily the midpoint of displayed subgroup averages. That shortcut gives each subgroup equal weight, even when their underlying record counts differ.

Reference: [1]

Sharing Insights

37. Color and legends

Color can encode categories or a numeric measure. Discrete categories such as East and West receive separate colors, and the legend maps each color to a member. A continuous measure such as Profit uses a gradient, with positions along the legend representing numeric values. Decide which distinction the reader needs: separate hues help identify a small number of groups, while an ordered light-to-dark scale can reveal magnitude. Check the legend's endpoints and any midpoint, especially if negative and positive values share a diverging palette. Colors can imply order even when categories have none, so avoid a numeric-looking gradient for unrelated names. Keep enough contrast for marks and labels, and do not rely on color alone when exact values or accessibility matter. A label or tooltip can supply a number that the color scale only approximates.

Worked example: In one view, East and West are region categories, so assign each a distinct color and identify them in a categorical legend. In another, two marks have Profit of 10 and 30 dollars. On a continuous profit legend from 0 to 40 dollars, 30 lies farther toward the high end than 10; color conveys order, not an exact reading.

Watch the distinction: A darker mark is not always a larger value. First check whether color represents a continuous measure, a discrete category, or a palette whose direction has been reversed.

Reference: [1]

38. Labels and typography

A chart title should name the subject and measure, while axes, labels, and legends supply the units and categories needed to decode individual marks. Add mark labels when exact values matter and the view has room for them; too many overlapping labels can make a dense chart less readable. Text size and contrast should establish a clear order of attention, with the main finding or chart title easy to locate and supporting detail legible. Avoid letting formatting substitute for missing context. A bar at 60 might be dollars, orders, or a percent unless the measure and unit are identified. When several views appear together, consistent typography helps readers recognize titles and controls across the dashboard. Candidates who also study financial presentation through the FP&A study guide will recognize the same need to state the measure, period, and unit before drawing a comparison.

Worked example: A bar chart contains East at 40 and West at 60, with values measured in thousands of dollars. Title it “Regional Sales, April” and label the axis “Sales ($ thousands).” Labels of 40 and 60 let the reader calculate West's lead as 60 − 40 = 20 thousand dollars, or $20,000.

Watch the distinction: Two visible bar lengths do not tell the reader what was measured. Without a period and unit, even a correct 20-unit difference can be interpreted incorrectly.

Reference: [1]

39. Shape and mark size

Shape is a categorical cue: a circle and square can identify different stores, but neither shape is inherently larger in business value. Size is an ordered cue and can show a numeric measure, provided the legend states what controls it. Use only a small number of distinct shapes, since many similar symbols become difficult to distinguish. For sized marks, check whether the encoding uses area and how overlapping marks may hide one another. A visually larger symbol shows a higher encoded value, but readers should use labels or tooltips for exact comparisons. Combining shape and size can answer two questions at once, such as which store a mark represents and how much it sold. Keep the encodings independent: if store identity already appears in a label, shape may be redundant, while size can still add a quick magnitude cue.

Worked example: Store A has sales of 20 units and Store B has 50. Give A a circle and B a square, then size both marks by Sales. B's mark should be larger because 50 > 20, and the sales difference is 50 − 20 = 30 units. The square identifies B; it does not mean “high sales” by itself.

Watch the distinction: A shape legend is not a numeric scale. If the mark sizes are equal, a square for Store B provides no evidence that B sold more than Store A.

Reference: [1]

40. Animation across states

Animation helps readers follow marks as a view changes between states, such as when a filter, sort, or displayed period changes. In Tableau, animated transitions can make the movement of persistent marks easier to track, but they do not change the values being calculated. Decide what should remain stable across states: a fixed axis lets positions retain the same numeric meaning, while an automatically changing range can make a modest change appear dramatic or hide a substantial one. Use clear period labels so viewers know which state they are seeing, and provide values when the precise difference matters. A static comparison may be easier if the audience needs to inspect two periods side by side. Animation is most useful when it reveals continuity, such as one category moving through successive positions, without obscuring the scale or identity of the marks.

Worked example: Suppose a category has Sales of 20 units in Period 1 and 30 units in Period 2. On a fixed axis from 0 to 40, its mark moves from the midpoint to three-quarters of the axis span. The increase is 30 − 20 = 10 units, or 10 ÷ 20 = 50% relative to Period 1.

Watch the distinction: A moving mark does not prove a large change if the axis range also changes. Read the scale and period labels before judging the magnitude of motion.

Reference: [1]

41. Assemble a dashboard

A dashboard puts worksheets in one viewing space so a reader can move from an overview to supporting detail. Start with the question the dashboard must answer. Give the main comparison the most space, then place a smaller view beside or below it to explain the differences. A text object can supply a concise title or definition; a legend belongs near the marks it explains. Check that the worksheets use compatible filters and measure definitions. If one chart shows gross sales while another shows net sales, their numbers may disagree for a legitimate reason that the dashboard should make clear. Use containers to keep related objects aligned as the dashboard changes size. The official Tableau Desktop Foundations examination guide includes dashboard assembly within the sharing domain.

Worked example: A bar chart shows East sales of 50 and West sales of 40 units. Beside it, a product table shows East products at 20 and 30, and West products at 15 and 25. The table totals are 20 + 30 = 50 and 15 + 25 = 40, so it explains both bars and confirms that East leads by 10 units.

Watch the distinction: Adding several worksheets does not automatically make a useful dashboard. If their measures, time periods, or filters differ, apparent comparisons can mislead even when each worksheet is correct.

Reference: [1]

42. Dashboard filter controls

A filter control lets the viewer choose which values a worksheet includes. On a dashboard, first add the relevant field as a filter in a worksheet and show its control. Then decide which worksheets the control should affect. Applying it to selected worksheets is useful when a summary and detail view must respond together, while an unrelated benchmark should remain fixed. Check field compatibility across data sources; two fields both named Region are not necessarily linked automatically. After setting the scope, test each choice and compare totals with the unfiltered views. A single selection can change both marks and aggregates because excluded records no longer contribute to those worksheets. The displayed filter should have a clear title, especially when several controls appear together. A control that changes only one worksheet may be valid, but its scope must match the question.

Worked example: A dashboard starts with a sales chart showing East 50 and West 40 units, plus a returns table showing East 2 and West 3 returns. Apply the Region filter to both worksheets and select East. The chart now shows 50 sales units, and the table shows 2 returns. Their shared region is clear; West is excluded from both.

Watch the distinction: Showing a Region filter on the dashboard does not prove that every worksheet uses it. Check its target worksheets before treating the displayed views as the same regional slice.

Reference: [1]

43. Tooltips and highlighting

A tooltip reveals details when the viewer hovers over a mark. It can show the mark's dimensions, aggregated measures, and a short explanation without crowding the chart with permanent labels. Check the aggregation in the tooltip: SUM(Sales) for a region describes the contributing records, not one underlying order. Highlighting serves a different purpose. It emphasizes matching marks, often across worksheets, while leaving other marks visible for context. Use a shared field such as Region or Product to define what counts as a match. Test a highlighted mark in every target view, because a mismatched field can make the interaction seem broken. Tooltips are best for exact detail on demand; highlighting is best for finding a selected category within a broader pattern. For practice reading interactions, the Tableau Desktop Foundations practice questions provide a related study path.

Worked example: An East bar represents two orders of 20 and 30 units. Its tooltip displays SUM(Sales) = 50 units, since 20 + 30 = 50. Highlighting East also emphasizes East marks in a product view. West marks remain visible but less prominent, so the viewer can still compare East with West while inspecting the exact East total.

Watch the distinction: A tooltip value is not necessarily a single record. Read its aggregation and the mark's dimensions before interpreting it; highlighting, meanwhile, does not remove the unselected records.

Reference: [1]

44. Filter actions

A filter action uses a selection in one worksheet to restrict another worksheet. Define the source sheet, the target sheet, the event that triggers the action, and the fields used to match records. Selecting a Region mark can pass its Region value to a product table, which then recomputes its aggregates from matching rows. Decide what happens when the selection clears: the target can show all values, show none, or keep the last selection. That choice affects whether a dashboard appears empty or returns to its overview. Test the action with at least two source marks and compare target totals with the source. If the target uses a different data source, verify that the matching fields represent the same values. A filter action changes which target records contribute; it is useful for drilling from summary to detail.

Worked example: The source chart has East at 50 units and West at 40. The target product table initially lists both regions. Select East and pass Region to the target: only East rows of 20 and 30 remain. Their sum is 50 units, matching the East bar. Clearing the selection with the show-all setting restores both regions.

Watch the distinction: Selecting a mark does not filter every dashboard view automatically. The action needs a defined target and matching field, and its clearing behavior should fit the intended analysis.

Reference: [1]

45. Highlight actions

A highlight action connects marks that share a chosen value without excluding the remaining data. Configure the source worksheet, target worksheets, triggering event, and field used for matching. For example, selecting Product A in one view can emphasize Product A in every region of another view. The other products remain present but fade, preserving their positions and totals for comparison. This makes highlighting useful when the question is where a category appears, rather than what the view looks like after filtering to that category. Consider what happens when the selection clears and check that the matched field has the same meaning in each worksheet. A legend can also provide highlighting for a color category. Because all records remain in the view, reference lines and axes usually retain the same context while emphasis shifts.

Worked example: A regional chart shows Product A at 20 units in East and 30 in West, alongside Product B at 10 and 15. Select Product A in the source view. The 20 and 30 unit marks brighten in the target; Product B's 10 and 15 unit marks remain visible but fade. The full 75 unit comparison remains available.

Watch the distinction: Faded marks are still part of the view. Do not read a highlight action as a filtered total or conclude that the other products have been removed.

Reference: [1]

46. Parameter actions

A parameter stores one value that calculations, reference lines, or other supported controls can read. A parameter action updates that value when a viewer interacts with a mark. Set the action's source, trigger, source field, and target parameter; make sure the field and parameter data types are compatible. Then build a calculation that uses the parameter. Without that calculation or another consumer, changing the parameter produces no visible analysis. A selected mark might set a sales threshold, after which a Boolean calculation identifies marks meeting it. Decide how multiple selected marks should supply one parameter value, and test what value remains when the selection clears. Parameters differ from filters: the selected value can drive a comparison or formula while all records stay in the view. This makes the resulting decision rule visible.

Worked example: A target worksheet contains marks at 40 and 50 sales units. Selecting a benchmark mark with value 45 sets the Threshold parameter to 45. The calculation [Sales] >= [Threshold] evaluates 40 >= 45 as false and 50 >= 45 as true. Both marks can remain visible, with color showing which reaches the selected benchmark.

Watch the distinction: Creating a parameter action alone does not filter or recolor marks. A calculation or other view element must read the updated value, and its field type must match.

Reference: [1]

47. URL actions

A URL action opens a destination built from a fixed address and, when needed, values from the selected mark. Define the source worksheet, trigger, and URL template. Insert a field such as Store ID where the destination expects it, then test selections with different IDs. A mark must represent the intended single store; an aggregate mark covering many stores cannot supply an unambiguous store page. If field values can contain spaces or special characters, ensure the resulting URL is encoded appropriately. The link should have a descriptive action name so the viewer knows what will open. A URL action directs the viewer to external detail; it does not change Tableau's source records or compute a new measure. Check the finished address, since a valid link can still lead to the wrong entity when the inserted field is incorrect.

Worked example: A store view has one mark for Store ID 101 and another for 102. The action uses `https://example.com/stores/` followed by the selected ID. Selecting 101 opens `https://example.com/stores/101`; selecting 102 opens the corresponding `/102` page. The changing final segment identifies which store's detail page the viewer requested.

Watch the distinction: A URL action is only as specific as its source mark. If the mark combines several stores, inserting a single Store ID cannot reliably identify the intended store.

Reference: [1]

48. Device layouts

Device layouts let one dashboard present its objects differently on screens of different sizes. Begin with the information hierarchy: the main finding should appear first, followed by supporting detail and controls. A wide desktop can show a chart and table side by side, but a narrow phone often needs a vertical arrangement. In a phone layout, inspect titles, axis labels, legends, and filter controls at the actual small size; simply shrinking the desktop layout can make them unreadable. Preserve the same analytical meaning when rearranging objects. If a chart is hidden or shortened, make sure the remaining view still answers the stated question. Test interactions after changing the layout, including whether a filter or tooltip can be reached. Layout design changes presentation, while worksheet calculations and underlying data remain governed by their own settings.

Worked example: A desktop dashboard places regional sales beside a product table. On a phone, stack the sales chart above the table and keep the Region control near the top. Selecting East still limits both views. The viewer first sees East's 50 unit total, then scrolls to product values of 20 and 30 units, which sum to 50.

Watch the distinction: A smaller canvas does not automatically produce a useful phone view. Check reading order and control access; a correct chart is ineffective if its labels or filter cannot be used.

Reference: [1]

49. Stories and story points

A Tableau story is a sequence of story points, each showing a worksheet or dashboard state with a caption. Plan the sequence around findings, not around every available chart. The opening point establishes the broad result; later points narrow the question or reveal an explanation. Give each point a caption that states its specific claim and check that the displayed filters and numbers support it. A later point may use a different view or a different state of the same dashboard. Because readers move between points, keep measure definitions and time periods consistent unless the change is clearly stated. The sequence should let a reader answer how a conclusion follows from earlier evidence. This is related to the evidence sequence used in business analysis: each step should resolve a clear question raised by the preceding one.

Worked example: Point one shows total sales of 100 units. Point two shows East contributing 60 units, so East supplies 60 / 100 = 60% of the total. Point three breaks East into Product A at 40 and other products at 20. Product A supplies 40 / 60 = 66.7% of East sales, explaining much of East's contribution.

Watch the distinction: Three screenshots do not form a persuasive story merely because they are ordered. Each point needs a distinct finding, and its caption must agree with the displayed numbers.

Reference: [1]

50. Workbooks and packaged workbooks

A Tableau workbook stores sheets, dashboards, stories, calculations, and connection details. A standard workbook file can still depend on a data file at a path the recipient cannot reach. A packaged workbook bundles the workbook with eligible supporting local files or extracts, making a self-contained handoff more practical. The package is a snapshot of the included data, so later changes to the sender's CSV do not automatically appear in the recipient's copy. Check the data source type before choosing the file: a live server connection may still require network access and credentials. Also consider whether the recipient needs editable analysis or only a fixed visual. File packaging solves a portability problem for local dependencies; it does not replace access control for remote sources or guarantee that every external connection works on another computer.

Worked example: A workbook reads `orders.csv` from a local folder and shows three order rows. Sending only the workbook may leave the recipient with a broken file path. A packaged workbook can include that CSV, allowing the three-row analysis to open elsewhere. If a fourth order is later added to the sender's CSV, the already-sent package still contains its earlier three-row snapshot.

Watch the distinction: A packaged workbook is not a live copy of every source. Included local data can become stale, while server connections may still require the recipient's own access.

Reference: [1]

51. Share views and data

Choose a sharing method by asking what the recipient must do. A static image, PDF, or PowerPoint export preserves an appearance suitable for a report or slide; it does not provide the same exploration as an interactive workbook. Publishing a view to an available Tableau server environment can give authorized viewers interactive access, subject to the publication and access settings. If a recipient needs records behind a mark, use View Data or an appropriate data export, checking whether the request is for summarized values or underlying rows. These can differ: one regional mark may summarize many orders. Before exporting, verify filters and selections, because they determine which marks or data the recipient receives. Also check that the recipient understands the measure's units and aggregation. The choice is about the needed interaction and data detail, not just the file extension.

Worked example: A manager needs a fixed slide showing East sales of 50 units, so export the view as a PowerPoint slide or image. An analyst needs the contributing East orders of 20 and 30 units, so inspect or export the underlying rows. Publishing the view serves a third need: authorized viewers can select regions and inspect updated marks interactively.

Watch the distinction: Exporting the visible chart does not necessarily provide its contributing rows. Match the export to the recipient's need for a picture, an interactive view, or underlying data.

Reference: [1]

Understanding Tableau Concepts

52. Dimensions and measures

Dimensions divide data into meaningful groups, while measures supply values Tableau can aggregate for those groups. A field's storage type alone does not settle its role. A numeric Store ID identifies an entity, so summing IDs would be meaningless; treating it as a dimension lets the view create one group per store. Sales is usually a measure because totaling or averaging its values answers a quantitative question. Tableau's initial classification is a starting point that you can change. Ask what each value represents, then inspect the pill in the view to see how it is used. A dimension can be placed on Rows, Columns, Color, or Detail to split marks. A measure can be placed on an axis or Label and is generally aggregated at the view's current level of detail. This classification drives the question the view answers.

Worked example: Two records have Store IDs 101 and 102 and Sales of 20 and 30 units. Store ID as a dimension produces two store groups. SUM(Sales) gives 20 and 30 units for those groups, or 50 units overall. SUM(Store ID) would produce 203, but 203 is neither a store nor a useful business total.

Watch the distinction: A number is not automatically a measure. Postal codes, product codes, and IDs may be stored numerically yet function as categories; summing them has no meaningful interpretation.

Reference: [1]

53. Discrete and continuous fields

Discrete fields create separate headers for distinct values; continuous fields create an axis or continuous scale on which values have positions. Tableau commonly shows discrete pills in blue and continuous pills in green, but the key distinction is how the view is structured. A discrete category such as Low or High is suited to separate columns or rows. A continuous Sales measure can show where 40 lies between 0 and 100 and can support reading numeric distance. Dates can also be represented either way: discrete month names create headers, while a continuous timeline preserves spacing through time. Choose the representation that matches the question. If you need to compare named groups, separate headers help. If you need magnitude or progression, an axis often helps. Changing this setting can alter headers, axes, and aggregation layout without changing the underlying records.

Worked example: Suppose two sales bands are Low and High. As a discrete field, they create two headers, one for each band. A continuous Sales axis spanning 0 to 100 units places a 40 unit mark at 40% of that scale's numeric span. The band labels classify observations; the axis locates a measured value.

Watch the distinction: Blue and green pills do not mean text versus numbers. The colors indicate discrete versus continuous treatment, which controls headers or axes even for dates and numeric fields.

Reference: [1]

54. Date parts and date values

A date part extracts a recurring calendar component, such as month name or quarter, from a date. Selecting the discrete Month part can group all Januaries together regardless of year. A date value retains a position in time, such as January 2021 or January 2022, and can keep those periods separate on a timeline. Before building a date view, decide whether the question compares seasons across years or tracks change from one period to the next. If year must matter, include it or use a date value that preserves it. Check the pill's displayed date level and whether it is discrete or continuous; the same source date can support several views. This distinction also affects filters: choosing the month part March can include multiple years, while choosing a bounded date range can isolate one March.

Worked example: One order occurs in January 2021 with sales of 10 units; another occurs in January 2022 with sales of 20 units. Grouping by the January month part produces one January mark totaling 30 units. Using month date values gives two marks, 10 and 20 units, at distinct positions one year apart.

Watch the distinction: A month label alone does not identify a year. If separate years matter, use a date value or include Year; otherwise, the view can combine periods unintentionally.

Reference: [1]

55. Temporal level of detail

Temporal level of detail determines how many date groups a view creates. At day level, records on different days make separate groups. At month level, days within the same month combine, and Tableau aggregates their measure values for that month. At year level, months within the year combine again. Choose the level that matches the variation you need to see. Daily detail can expose short spikes but make a long chart crowded; monthly aggregation can reveal a trend while hiding a single-day event. Always read the date pill and axis or headers before interpreting a mark, because the displayed value may summarize many rows. Also check whether the date representation preserves the year. A month-of-year part across several years can combine records that a month-by-month timeline would keep separate.

Worked example: Sales are 10 units on January 2 and 20 units on January 20 of the same year. A day view has two marks, at 10 and 20 units. A month view has one January mark with SUM(Sales) = 10 + 20 = 30 units. The monthly mark represents both records, not a new transaction.

Watch the distinction: Changing from days to months does not merely relabel the axis. It changes which records contribute to each aggregate mark and can conceal daily variation.

Reference: [1]

56. Default measure aggregation

A measure pill displays the aggregation Tableau is applying, such as SUM(Price) or AVG(Price). Numeric measures commonly begin with a default aggregation, and a field can have a configured default, but the view can override it. Read the pill rather than assuming what the label means. SUM adds contributing values and suits quantities such as sales when those values are additive. AVG divides their sum by the count of nonnull values, which can answer a typical per-record question. Other choices, including minimum, maximum, or count, answer different questions. Before changing an aggregation, identify the unit of each row and the grain of the view. For example, averaging line-item prices is a per-line average, which may differ from a per-product or per-order average. The aggregation is part of the measure's meaning, not just display formatting.

Worked example: Two records list prices of 10 and 20 currency units. SUM(Price) = 10 + 20 = 30 currency units, while AVG(Price) = 30 / 2 = 15 currency units per record. If the question asks for typical listed price across these two records, AVG gives 15. If it asks for their combined amount, SUM gives 30.

Watch the distinction: A field named Price does not tell you whether its displayed number is a sum or average. Inspect the pill and confirm that its aggregation matches the question.

Reference: [1]

57. Additive and nonadditive values

An additive measure can be summed across the relevant records without changing its basic meaning. Order counts and sales amounts often work this way when records do not overlap. A rate is different: its numerator and denominator must be combined before the overall rate is calculated. Summing group percentages is usually meaningless, and averaging them without weights can also mislead when group sizes differ. Store or calculate the components, then use an aggregate expression such as SUM(Returns) / SUM(Orders) for the displayed group, with suitable handling for a zero denominator. Examine what each row represents before using SUM: a repeated customer balance across orders would overcount even though the balance is numeric. The decision sequence is to identify the quantity, its unit and grain, and whether aggregation preserves the intended interpretation.

Worked example: Group A has 1 return among 10 orders, so its rate is 1 / 10 = 10%. Group B has 9 returns among 90 orders, also 9 / 90 = 10%. Together there are 1 + 9 = 10 returns and 10 + 90 = 100 orders. The combined rate is 10 / 100 = 10%, while adding the group rates would incorrectly give 20%.

Watch the distinction: Percentages from separate groups are not quantities to add. Recompute the rate from combined numerators and denominators, and check that those components count distinct relevant events.

Reference: [1]

58. Dimensions set view grain

The dimensions in a view define the groups at which Tableau aggregates measures. With no dimension, a measure can appear as one aggregate for all included records. Adding Region partitions those records into regional groups; adding Product splits each region into smaller region-product groups. The measure calculation is repeated at the new view grain. This is why a total can stay the same while the number of marks increases. Before adding a field to Color, Detail, Rows, or Columns, predict whether it will divide existing marks. Then check whether the resulting values add back to the earlier total when the measure is additive. Filters and missing values can affect that check. Understanding view grain helps diagnose unexpected marks and prevents reading one category's aggregate as an individual record. It also clarifies why changing the dimensions can change an average or count.

Worked example: Two East orders have Sales of 20 and 30 units, for an overall SUM(Sales) of 50. Adding Region yields one East mark at 50 because both records share East. If the orders belong to Products A and B, adding Product yields East-A at 20 and East-B at 30. Their sum remains 50 units.

Watch the distinction: An extra mark does not imply an extra underlying row. A newly added dimension may simply partition existing records into more groups; inspect the field and grain.

Reference: [1]

59. Marks versus records

A mark is one displayed result for a combination of dimensions in the view. A record is an underlying data row that may contribute to that result. Several records can produce one mark when their measure values are aggregated, while a detailed view can produce many marks. Use the view's dimensions to predict the number of groups, then inspect View Data when you need to see the contributing rows. A tooltip with SUM(Sales) may describe a mark's aggregate; it does not reveal how many rows contributed unless you add an appropriate count. Conversely, a count of marks says little about the number of underlying records. This distinction matters when interpreting charts, exporting data, and diagnosing apparent duplication. If a join has multiplied rows, the underlying record count and aggregate may change even if the view still displays the same number of marks.

Worked example: Four order rows have regions East, East, West, and West, with sales of 10, 20, 15, and 25 units. A view containing Region and SUM(Sales) has two marks: East at 10 + 20 = 30 and West at 15 + 25 = 40. The two marks summarize four rows and 70 units overall.

Watch the distinction: Do not infer that two marks mean two orders. Marks count displayed groups; underlying records count contributing rows, which may be many per mark.

Reference: [1]

60. Row calculations and aggregate calculations

A row calculation evaluates an expression for each record before the view aggregates its results. An aggregate calculation first summarizes the contributing records, then combines those summaries. The two routes can answer different questions. A row margin, Profit / Sales, describes each row's profitability. AVG of those row margins gives every row equal weight. SUM(Profit) / SUM(Sales) gives a combined margin weighted by each row's sales, which is usually the relevant overall rate. Check denominators for zero or null values and decide whether rows represent comparable units before using either calculation. Tableau also requires aggregation levels within an expression to be consistent, so an aggregate numerator should pair with an aggregate denominator. When a displayed percentage seems surprising, identify its numerator, denominator, and calculation grain before changing its formatting.

Worked example: Two rows have Profit and Sales of (5, 10) and (5, 90) currency units. Their row margins are 5 / 10 = 50% and 5 / 90 ≈ 5.6%; their simple average is about 27.8%. Overall profit is 5 + 5 = 10 and sales are 10 + 90 = 100, so the combined margin is 10 / 100 = 10%.

Watch the distinction: Averaging row percentages can overemphasize small rows. For an overall margin, divide total profit by total sales after confirming that both totals cover the same records.

Reference: [1]

Official references and further reading

Official Salesforce Tableau Desktop Foundations examination guide

All study guides

Connecting to and Preparing Data

1. Connect to files and servers

2. Live connections and extracts

3. Extract scope and refresh

4. Saved data source metadata

5. Multiple connections

6. Relationships preserve table grain

7. Join duplication

8. Join types and missing matches

9. Unions append rows

10. Field names and aliases

11. Correct field data types

12. Geographic roles

13. Field defaults

14. Data source filters

Exploring and Analyzing Data

15. Bars and stacked parts

16. Lines over time

17. Scatterplots for paired measures

18. Symbol maps

19. Density maps

20. Text and highlight tables

21. Combined axes

22. Dual axes

23. Groups combine members

24. Sets define membership

25. Hierarchies support drill-down

26. Dimension and measure filters

27. Date filters

28. Manual and computed sorts

29. Reference lines

30. Quick table calculations

31. Histograms and bins

32. Arithmetic calculated fields

33. String calculated fields

34. Date calculated fields

35. Parameters control a value

36. Totals and subtotals

Sharing Insights

37. Color and legends

38. Labels and typography

39. Shape and mark size

40. Animation across states

41. Assemble a dashboard

42. Dashboard filter controls

43. Tooltips and highlighting

44. Filter actions

45. Highlight actions

46. Parameter actions

47. URL actions

48. Device layouts

49. Stories and story points

50. Workbooks and packaged workbooks

51. Share views and data

Understanding Tableau Concepts

52. Dimensions and measures

53. Discrete and continuous fields

54. Date parts and date values

55. Temporal level of detail

56. Default measure aggregation

57. Additive and nonadditive values

58. Dimensions set view grain

59. Marks versus records

60. Row calculations and aggregate calculations

Official references and further reading

Frequently Asked Questions

Related Study Guides

Certified Anti-Money Laundering Specialist (CAMS)

Certified Financial Crime Specialist (CFCS)

Certified Global Sanctions Specialist (CGSS)