Project content

Waterfall charts are easy to demonstrate and surprisingly easy to break. My first version looked correct with a small dataset, but checkpoint totals, region and fiscal-year filters, and colour introduced calculation problems.

I rebuilt the chart around a single-axis Gantt bar. Unlike a regular bar chart, a Gantt mark lets me control both where a bar begins and how far it extends. That extra control allows each movement to connect to the running balance without a dual axis or a large set of helper columns.

This project documents the final approach, the calculation chain behind it, the issue I encountered when colour was added, and the assumptions that must remain visible for the chart to stay reliable.

Explore the interactive dashboard

Use the fiscal-year and region controls to see how the same calculation chain responds to a different slice of the data.

Open the dashboard directly in Tableau Public

Project at a glance

The problem

A regular bar chart controls height. A waterfall chart needs two independent values:

• the starting position of each bar;
• the length and direction of the movement.

Checkpoint totals add another complication. The initial total starts the calculation, but later totals should display the current balance without being added to the running total again.

The chart also became unstable when I added a dimension to Colour. In Tableau, adding a field to the Marks card can change how table calculations are partitioned or addressed. The chart therefore needed separate fields for structural logic and visual classification.

Data design

I kept the demonstration dataset intentionally small:

There are no helper columns and no source-level Type field. For this version, Tableau classifies the named checkpoint segments through calculated fields.

That makes the CSV easy to inspect, although it also means the checkpoint names are hard-coded.

Calculation architecture

The calculations follow two connected paths.

1. Classify totals and movements

wf_bar_type identifies the three checkpoint bars used in this dataset.

CASE [Waterfall Segment]
WHEN 'Initial Pipeline' THEN 'Total'
WHEN 'Mid-Year Forecast' THEN 'Total'
WHEN 'Final Commit' THEN 'Total'
ELSE 'Delta'
END

2. Assign presentation colours

wf_bar_color keeps the colour logic separate from the field controlling the chart structure.

IF ATTR([wf_bar_type]) = 'Total' THEN 'Total'
ELSEIF SUM([Value]) > 0 THEN 'Increase'
ELSE 'Decrease'
END

Using an aggregate-compatible calculation here avoids placing the raw classification dimension directly into the table-calculation view.

3. Control what enters the running total

The initial checkpoint starts the waterfall. Later checkpoints are displayed but are not added again.

CASE [Waterfall Segment]
WHEN 'Initial Pipeline' THEN [Value]
WHEN 'Mid-Year Forecast' THEN 0
WHEN 'Final Commit' THEN 0
ELSE [Value]
END

4. Calculate the cumulative balance

RUNNING_SUM(SUM([wf_value_to_sum]))

This value represents the balance after each step.

5. Set the starting position

Totals begin at zero. Movement bars begin at the current running position.

IF ATTR([wf_bar_type]) = 'Total' THEN 0
ELSE [wf_running_total]
END

6. Set bar size and direction

Totals draw the full cumulative value. Deltas use the inverse of the movement so the Gantt bar connects the previous and current balances.

IF ATTR([wf_bar_type]) = 'Total' THEN [wf_running_total]
ELSE -SUM([Value])
END

7. Create the label

[wf_running_total]

The label shows the resulting balance after every step instead of only the size of the individual movement.

Building the view

I first created a basic bar chart to verify the raw data structure:

• Waterfall Segment on Columns;
• Value on Rows;
• segments sorted by Step Order ascending.

I then converted the view:

1. Change the Marks type to Gantt Bar.
2. Replace the field on Rows with wf_position_fixed.
3. Place wf_size_fixed on Size.
4. Place wf_bar_color on Colour.
5. Place wf_label on Label.
6. Set the table calculation to compute using Waterfall Segment.
7. Confirm that the visual order still follows Step Order.

Final presentation cleanup

The calculation can be correct while the worksheet still looks unfinished. Before publishing the dashboard, I would apply a final presentation pass:

• replace Sheet 1 with a descriptive dashboard title or hide the worksheet title;
• hide the technical wf_position_fixed axis title;
• rename or hide the wf_bar_color legend heading;
• use one consistent number format for labels and the axis;
• give long segment names enough space so they do not truncate;
• keep checkpoint totals neutral while using distinct increase and decrease colours.

Why adding colour broke the chart

The chart initially worked until colour was added. The first implementation reused a structural dimension on the Colour shelf, which changed the level at which Tableau evaluated the marks and table calculations.

The fix was to separate the concerns:

• wf_bar_type decides whether a mark behaves as a total or a delta;
• wf_bar_color decides how the mark is presented;
• ATTR() keeps the colour calculation compatible with the aggregated fields already used in the view.

This was the most important debugging lesson from the project. A visual field can change calculation behaviour even when it appears to be only formatting.

Validation

Before treating the view as complete, I check the following:

• exactly one Fiscal Year is selected;
• exactly one Region is selected;
• the segments are ordered by Step Order;
• all table calculations compute using Waterfall Segment;
• the opening total matches the source value;
• each increase and decrease lands on the expected cumulative balance;
• the mid-year and final checkpoints equal the manually calculated running total;
• changing a filter does not combine multiple independent waterfalls.

4,120,000 - 487,000 + 345,000 + 148,000 = 4,126,000
4,126,000 + 578,000 - 194,000 + 184,000 - 106,000 = 4,588,000

Trade-offs and limitations

This version is intentionally small and explainable, but it is not completely generic.

• The total segments are identified by exact names. Renaming or adding checkpoints requires updating wf_bar_type and wf_value_to_sum.
• The view assumes one Fiscal Year and one Region at a time. Supporting multiple independent waterfalls in one view requires explicit partitioning.
• Later checkpoint bars display the calculated balance. Their raw source values are not added to the running total.
• The table calculations depend on visual order. A sort change can produce a technically valid calculation with the wrong business meaning.

Result

The finished chart uses one axis, a five-field source dataset, and a small calculation chain. It supports region and fiscal-year filtering while keeping totals, increases, and decreases visually distinct.

More importantly, the implementation is explainable. Each field has one responsibility, the assumptions are visible, and the chart can be validated with straightforward arithmetic.

Project resources

• Open the interactive Tableau dashboard
• Download the demonstration dataset