Tableau Desktop Specialist common mistakes
Tableau Desktop Specialist · Understand the traps and how to avoid them.
Reads the colour of a pill on a shelf as its data role - calls a green pill a 'measure' and a blue pill a 'dimension' when explaining what a view is doing.
Blue and green are the most visually loud cues on a worksheet, so candidates memorise 'blue = dimension, green = measure' and stop there, never separating the role in the Data pane from the discretely/continuously placed field on a shelf.
What to do instead
State the two axes separately: discrete (blue) vs continuous (green) describes how the field is placed on a shelf; dimension vs measure describes the field's role in the data source. Then rehearse the cross-cases: a date dragged as a continuous dimension is green, and a numeric field converted to a dimension can still be placed continuously.
Treats a relationship between two logical tables exactly like a physical join, then reports inflated sums when the 'many' side has multiple matching rows.
Both live under the same Data Source canvas and both use the same field names, so candidates assume the behaviour is identical and never check whether the tables were joined or related.
What to do instead
Check the canvas layer: a join sits inside a logical table (row-level combination, duplicates preserved); a relationship sits between logical tables and is evaluated at the level of detail of the view. When a total looks doubled, count records with and without the second table to confirm which construct is in play, and switch to a join only when you deliberately need row-level combination.
Adds a dimension filter to a worksheet that uses a table calculation or a Top N set, then is surprised when the calculation still runs against rows the filter supposedly removed.
Filters are read top-to-bottom and the default dimension filter is applied late in the pipeline, after table calculations have been computed - an ordering rule that is easy to read once and forget under time pressure.
What to do instead
Memorise the order: extract filter, data source filter, context filter, dimension filter, measure filter, then table calculation. When a calculation must see filtered data, right-click the filter and choose Add to Context, or rewrite the logic as a FIXED level-of-detail calculation.
Tries to place an unaggregated dimension alongside an aggregated measure on the same shelf and gets the 'cannot mix aggregate and non-aggregate arguments' error, then guesses at random workarounds.
The error names the symptom but not the cause: the field has been disaggregated (or is a row-level calculation) while the surrounding view is aggregated.
What to do instead
Decide which level the view should answer at. Wrap the field in ATTR() if one value per partition is acceptable, wrap it in an aggregation such as MIN() or COUNTD() if not, move it to Detail if it should only split marks, or write an LOD expression to fix the level of detail explicitly.
Filters a dimension out of a view using Exclude when the intent was to keep the marks out of sight but retain them in the underlying calculation, or vice versa.
Hide, Exclude and Filter all make rows disappear from the sheet, so the three get collapsed into one mental model, and only one of them affects what calculations and grand totals can see.
What to do instead
Assign a distinct purpose to each: Filter removes members before aggregation; Hide removes marks and headers from the view while the data still participates; Exclude is a filter that omits members and is useful for 'percent of total excluding X'. Test the choice by watching a grand total change or hold steady.
Builds a histogram by dropping a continuous measure onto Rows as a bar chart, or creates bins and never sets the bin size, producing a chart that looks like a histogram but bins by nothing.
Bar charts and histograms look similar in thumbnails, and the bin-size dialog only appears once, at creation time, so its importance is easy to miss.
What to do instead
Create bins from the measure (Create > Bins), set an explicit bin size from the Edit Bins dialog, then place the bin field on Columns and a count or Number of Records on Rows. Convert bin size to a parameter when the exam scenario implies adjustable granularity.
Publishes a workbook to a server or Tableau Public without checking where the data lives, then cannot explain why viewers see an error or a blank view.
The workbook connects locally to a file path or an extract on the author's machine, and publishing a .twb keeps that reference intact rather than shipping the data.
What to do instead
Before publishing, decide the delivery mechanism: save as a packaged workbook (.twbx) to bundle extracts, local files and images; publish the data source separately and set authentication (embedded credentials, or prompt viewers, or Kerberos/SSO); and confirm the published data source has a refresh schedule if it is an extract.
Assumes a numeric-looking field such as a ZIP code, store number or year is ready to use, then finds it aggregating into a measure or failing to plot on a map.
Tableau infers data type and role from the source at connection time, and numeric strings or codes get classified as measures with a number type, which is correct for storage but wrong for analysis.
What to do instead
After connecting, audit the Data pane: change the data type to String where leading zeros matter, right-click the field and set a geographic role (ZIP Code/Postcode, State, Country) so it plots, and convert numeric identifiers to dimensions so they are never summed.
Adds an extract filter or data source filter, changes the underlying source, and expects the worksheet to reflect new rows without refreshing the extract.
Extracts are snapshots; the difference between a live connection, a data source filter and an extract filter is conceptual rather than visible on the sheet, so the refresh step gets skipped.
What to do instead
Treat the extract as a saved copy: after any source change, refresh from the Data menu or set a refresh schedule on the published source. Remember that data source filters apply to all sheets using the source, and extract filters physically limit the rows in the .hyper file.
Sorts a view by clicking the sort icon on a dimension header without checking what the sort is measuring, so an alphabetised axis is reported as a ranking.
The toolbar sort icons are adjacent and apply to whichever field is selected, and manual reordering by dragging marks also produces a non-computed order that looks deliberate.
What to do instead
Always name the sort basis out loud (field, aggregation, descending) before accepting it: sort the measure directly, or right-click the header and choose Sort and specify Field Name, Aggregation and Order. For a defensible ranking, add a Top N filter or a RANK() calculation rather than a manual drag.