Salesforce Tableau Data Analyst common mistakes
Salesforce Tableau Data Analyst · Understand the traps and how to avoid them.
Building a join, seeing the row count climb, and proceeding to build the chart anyway without comparing row counts before and after the join.
Candidates treat a join as a lookup that 'adds columns' and forget that a one-to-many or many-to-many join multiplies rows, which silently inflates SUM and COUNT and deflates AVG.
What to do instead
Before joining, note the row count of the left table; after joining, check the data source's row count indicator and the 'Number of rows' in the data grid. If it changed, right-click the join and check the join clause cardinality, or add a uniqueness check by dragging the join key to Rows and counting distinct values.
Answering a relationship question as though the relationship were a physical join, e.g. expecting a relationship between Orders and Returns to drop orders with no returns.
Candidates learn joins first and assume every multi-table setup filters rows the same way. Relationships keep all rows from the logical table and only bring in related rows at the level of detail of the viz, so unmatched rows are retained, not removed.
What to do instead
Memorise the distinction: relationships = logical layer, no row duplication, aggregation happens after; joins = physical layer, row-level and can duplicate. If the question wants row elimination, the answer is a join (or a filter); if it wants no duplication across tables at different granularities, the answer is a relationship.
Unioning several monthly CSVs whose columns are named slightly differently and assuming Tableau will line up the fields correctly.
Candidates assume union is positional like an append in a spreadsheet. Tableau unions by field name by default, so mismatched names produce extra null-heavy columns rather than merged ones.
What to do instead
Inspect the union step and confirm column names match across files; use the union's 'by name' behaviour deliberately and rename fields in the physical layer if the source names vary. Test by dragging the date field to Rows and checking that all months appear under one column rather than under separate null-filled columns.
Placing a dimension filter on the Filters shelf and expecting a FIXED level-of-detail calculation in the same view to respect that filter.
Candidates reason top-down from the order they build the view rather than from Tableau's order of operations, and forget that FIXED is computed before dimension filters are applied.
What to do instead
Learn the order of operations as a sequence: extract filters, data source filters, context filters, FIXED, table calculations, dimension filters, INCLUDE/EXCLUDE, measure filters. If the filter must affect a FIXED calc, add it to Context (or make it a data source filter).
Building an average-of-averages by dragging a pre-aggregated rate or an AVG measure into the view and trusting the number, or switching aggregation to SUM/AVG at random to 'make it look right'.
Candidates don't separate row-level data from the aggregate that Tableau computes at the viz level of detail, so they don't notice that the denominator is the number of marks, not the number of underlying rows.
What to do instead
Ask 'what is the denominator?' before choosing the aggregation. Compute the ratio explicitly as SUM(numerator)/SUM(denominator) rather than AVG(rate), and if the required denominator differs from the viz granularity, use an LOD expression to fix the denominator and divide by it.
Accepting the default 'Compute Using' on a table calculation and reporting a percent-of-total or running total that is computed across the wrong direction.
Candidates build the crosstab and add the calculation without checking which pill Tableau chose as the addressing field, so the result silently addresses Table Across when the question demands Table Down (or a specific dimension).
What to do instead
After adding any table calculation, right-click the pill, open Edit Table Calculation, and explicitly set Compute Using to the specific dimension required, or switch to Specific Dimensions and tick the field. Sanity-check that the values in the first column/row equal the expected baseline.
Dragging a date field to Columns and getting a single continuous axis when the question asks for separate year or quarter headers, then trying to fix it with formatting or sorting.
Candidates treat the date pill's blue/green colour as cosmetic and don't connect discrete versus continuous to whether the field produces headers or an axis.
What to do instead
Check the pill colour and shape: discrete date parts are blue and produce headers (one column per year/quarter); continuous date values are green and produce a single axis. Right-click the pill and choose the exact date level (Year, Quarter, Month) and Discrete/Continuous to match the requested layout.
Stacking two measures on one axis and choosing Dual Axis when the requirement is a combined axis (or vice versa), then forcing a secondary axis to match by eyeballing the ranges.
Candidates reach for Dual Axis because it looks more powerful, but dual axis creates two independent scales that mislead comparisons unless synchronised, which is a different visual claim than a shared axis.
What to do instead
Decide the intent first: same units and directly comparable = single combined axis (drag the second measure onto the existing axis, or use Measure Names/Measure Values); different units intentionally = dual axis with right-click > Synchronise Axis and matching mark types set separately.
Publishing a workbook to a project and assuming the project's permissions automatically apply to it, or assuming a workbook's permissions can be looser than the project's.
Candidates think of permissions as purely inherited downward and forget the project permission model has both a capability setting and an 'Allow/Deny' plus locking behaviour, so they mispredict what a viewer in a group can actually do.
What to do instead
Trace the chain explicitly: group membership → project permissions (and whether they are locked) → workbook-level permissions. Remember a workbook cannot grant more than the project allows while project permissions are locked, and use 'Permissions' on the workbook to verify the effective capability for a specific user rather than reasoning from role names.
Choosing 'Embed password' versus 'Prompt user' at publish time without considering who will refresh the extract, and expecting a scheduled extract refresh to work after the publisher leaves.
Candidates treat the credential choice as a one-time publish detail rather than a governance decision that determines whether background refreshes and subscriptions can authenticate to the source.
What to do instead
Decide based on refresh ownership: embedded credentials let Tableau Server refresh on schedule without the publisher present; prompt-user ties refresh to stored per-user credentials. Also remember subscriptions run with the permissions of the subscription owner, so verify the owner still has access to the underlying data before scheduling.