Tableau Calculated Fields
Math, logic and table-aware formulas in the viz
Calculated fields are your FLOW: IF/IIF logic, date functions, table calculations and aggregations. They power ratios, bins, segments and dynamic colors.
What you will learn
- Write IF/IIF, CASE and date calculations
- Distinguish row-level vs aggregate/table calculations
- Compose reusable calculated fields in the data source
What is this?
Tableau calculated fields are formulas derived from existing fields: ratios (profit/sales), segments via IF, date diffs, rankings and running totals via table calculations (RANK, RUNNING_SUM), and bucketing via bins. They come in three tiers — row-level calcs evaluated per data row, aggregate calcs over the whole view, and table calculations that run across the visible rows/columns after aggregation.
Why do you need it?
- Real questions are rarely a raw column — they're a derived ratio or segment.
- Table calculations unlock rankings, running totals and moving averages.
- At the data-source level, one calculated field serves every sheet consistently.
- The pattern — row-level calc, aggregate calc, table calc — becomes second nature.
Mental model
A formula column in a spreadsheet
A calculated field
Excel formulas reference cells; Tableau calculated fields reference model fields and (for table calcs) the current view's layout. A spreadsheet formula recalculates per row; a Tableau calc at table level recalculates per partition — same muscle, new dimension.
How it works
- Row-level calcs evaluate per row of a table (e.g., amount - cost).
- Aggregate calcs wrap an aggregation over the view (SUM(amount) / SUM(cost)).
- Table calculations (LOOP, LOOKUP, WINDOW_*, RANK) run after the initial aggregation, across Rows/Columns partitions.
- IIF and IF/THEN/ELSE classify; CASE handles equality dictionaries.
- Bins (in the UI) create fixed-width buckets from a continuous measure.
The three calc layers: row, aggregate, table.
Examples
Three kinds of calculated field
-- Row-levelProfit Margin = (SUM([Profit]) / SUM([Sales])) Segment = IF [Sales] > 1000 THEN 'High' ELSEIF [Sales] > 400 THEN 'Mid' ELSE 'Low' END -- Table calculationRank by Region = RANK(SUM([Sales])) Running Sales = RUNNING_SUM(SUM([Sales]))A ratio, an IF-based segment, and two table calculations (rank and running sum) — the three archetypes in practice.
In production
- A margin tile is a single modeled Profit Margin field shared by 8 sheets.
- A percentile bucket (value-based bin) segments customers into cohorts for a heatmap.
- Ranking by revenue drives a leaderboard that re-sorts as filters change.
Best practices
- Define derived fields at data-source level when multiple sheets need them.
- Prefer IF/ELSEIF over nested IIF for readability.
- Name calculations by business meaning, not formula ('Profit Margin', not 'pm').
- Test with a known row before letting it drive a whole dashboard.
Common mistakes
- Using SUM([Profit])/SUM([Sales]) where a per-row ratio, then avg, is needed.
- Table calculations used on filtered layouts without understanding the partition.
- A field labeled 'Sum' that actually uses a row-level calc — misleading totals.
- Violating aggregation-level: mixing row and aggregate expressions in one calc.
Debugging tips
- Wrong totals → check whether the calc is row-level vs aggregate by the icon placement.
- Ranking looking odd → inspect the partition/address — are Rows and Columns both addressed?
- Calc greyed/swallowed → the field may need a different data-source or field type.
Interview checkpoint
Hands-on lab
- Replicate row-level vs aggregate calcs
- Build a rank and running total analog
- Verify segment logic against the source
Build Segments, Ratios and Rankings in SQL
45 min · intermediate
Quick quiz
Which calculated field runs AFTER the aggregation, across the visible layout?
A data-source-level calculated field is available to all sheets using that source.