A Tableau calculated field is a user-defined computation that extends the data model within a workbook — creating new metrics, transforming string values, performing date arithmetic, and applying conditional logic. This guide explains how calculated fields work, the formula language, and when to use them versus transforming data upstream.
A Tableau calculated field is a user-defined computation that creates a new field from existing data in the workbook's data source. Calculated fields let analysts extend the data model without modifying the underlying database — adding new metrics, transforming existing values, applying conditional logic, and computing aggregations that the source data does not pre-calculate.
Calculated fields are created in Tableau Desktop or Tableau Cloud's web authoring environment and are available in any sheet using the data source they belong to. Unlike filters and parameter controls that change what data is shown, calculated fields add new analytical dimensions and measures to the view.
Calculated Field Types
**Measure calculations** produce aggregated numerical results — new metrics derived from existing measures. Examples:
- Profit ratio: SUM([Profit]) / SUM([Revenue]) — not simply [Profit] / [Revenue], which would divide row-by-row before aggregation; wrapping both in SUM() produces the ratio at the aggregation level of the view
- Year-over-year growth: (SUM([Revenue]) - SUM([Prior Year Revenue])) / ABS(SUM([Prior Year Revenue]))
- Running total using a table calculation: RUNNING_SUM(SUM([Revenue]))
**Dimension calculations** produce string, date, or boolean values that create new categorical fields for grouping or filtering:
- Customer size tier from revenue: IF SUM([Revenue]) > 1000000 THEN "Large" ELSEIF SUM([Revenue]) > 100000 THEN "Medium" ELSE "Small" END
- Abbreviated month-year label: LEFT(DATENAME('month', [Order Date]), 3) + " " + STR(YEAR([Order Date]))
- Days since last order: DATEDIFF('day', [Last Order Date], TODAY())
**Logical calculations** return boolean values useful for conditional coloring, sizing, or filtering:
- Is this month above target: SUM([Revenue]) > [Target Revenue Parameter]
- Is the order late: [Ship Date] > DATEADD('day', [Standard Lead Time], [Order Date])
Row-Level vs Aggregate Calculations
This distinction is one of the most common sources of calculation errors in Tableau:
**Row-level calculations** operate on individual rows of the underlying data before aggregation. [Profit] / [Revenue] at the row level computes profitability for each individual transaction row. When Tableau aggregates this to the view level (e.g., summing by product category), it sums up each row's calculated ratio — which is mathematically incorrect for a ratio metric.
**Aggregate calculations** operate on aggregated values. SUM([Profit]) / SUM([Revenue]) aggregates profit and revenue separately, then divides. This produces the correct category-level profitability ratio.
The rule: for ratio metrics and percentage calculations, always use aggregate calculations (wrap numerator and denominator in SUM(), COUNT(), or other aggregation functions) rather than row-level calculations.
Table Calculations
Table calculations are a special type of calculated field that operate on the values displayed in the view rather than on the underlying data. They have access to the spatial layout of the view — which values are next to each other, which direction is "across" and which is "down" — enabling calculations that depend on position:
- RUNNING_SUM: cumulative sum from left to right or top to bottom
- WINDOW_SUM: sum of all values in the window (useful for percent of total)
- LOOKUP: retrieve a value at a specified offset position (prior period comparison)
- RANK: rank within the view's scope
- FIRST, LAST, INDEX: position-based functions
Table calculations are computed after data is retrieved from the source — they cannot be filtered by dimension filters (which affect data retrieval), only by table calculation-specific filters. This is a common source of confusion: a table calculation producing a running total will not be filtered to a subset if you add a dimension filter after the fact, because the running total was computed on all retrieved data.
Calculated Fields vs Upstream Transformation
A frequent architectural question: should a metric be calculated in Tableau, or should it be pre-calculated in the data warehouse transformation layer (dbt)?
Calculate in Tableau when:
- The metric is specific to this dashboard and unlikely to be reused
- The calculation depends on Tableau-specific functions (LOD expressions, table calculations)
- Quick iteration during development before formalizing in the data model
Calculate in dbt/warehouse when:
- The metric is a defined business KPI used across multiple dashboards
- The calculation is expensive and should be pre-computed
- Consistency across tools is required — the same metric is used in Tableau, Python notebooks, and API queries
- The calculation involves complex joins or window functions better handled in SQL
Metrics that end up in multiple dashboards and require consistent definitions belong in the transformation layer. The semantic layer (dbt Semantic Layer, Looker LookML) is specifically designed for this — defining metrics centrally so every tool that queries them uses the same definition.
Our Tableau consulting services include calculated field design, LOD expression development, and data model architecture for Tableau workbooks. Contact us to discuss your Tableau development requirements.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →