Change one Tableau KPI without changing the whole workbook: a cwtwb example

You need a Profit version of a Sales KPI. The original Sales view must keep working. That is a small request with a surprisingly important boundary: change the new worksheet's calculation chain, rather than replace a shared measure throughout the workbook.

This was the problem behind my earlier Datacooper post about local KPI replacement. Here is a concrete example from cwtwb, the open-source Python workbook authoring SDK.

Start with an existing workbook

The checked-in example opens 5 KPI Design Ideas (2).twb, copies the worksheet 1. KPI to 1. KPI Profit, and applies the mapping Sales -> Profit to the copy. It then makes the copied worksheet visible and saves a separate output workbook.

editor = TWBEditor.open_existing(SOURCE)
if TARGET_WORKSHEET not in editor.list_worksheets():
    editor.clone_worksheet("1. KPI", TARGET_WORKSHEET)
    editor.apply_worksheet_refactor(TARGET_WORKSHEET, {"Sales": "Profit"})
editor.set_worksheet_hidden(TARGET_WORKSHEET, hidden=False)
editor.save(OUTPUT)

This is an excerpt from the real example script, not a complete standalone program. The image reproduces the same source code; it is not a Tableau rendering or a test-results screenshot.

Why copying the view is only the first step

A KPI can depend on calculated fields, not just the measure visible on a shelf. The local refactor needs to account for that calculation chain. The example documentation also describes normalization of generic Calculation_* identities to Profit-based names, so the copied view does not retain misleading Sales labels.

For an agent, the useful sequence is to inspect the source worksheet, clone it, preview the refactor, apply the bounded change and review the saved artifact. cwtwb exposes preview_worksheet_refactor alongside the apply operation, so the proposed changes can be inspected before committing them.

What the repository checks, and what you still need to check

The repository's worksheet-refactor test checks that the original worksheet retains Sales formulas while the clone contains Profit formulas. It also checks renamed calculation identities and the saved workbook's worksheet XML. These are assertions in the test source; this article does not claim a new test run or a new Tableau render.

That scope matters. XML checks alone do not establish correct business definitions, correct rendered labels, or every dashboard interaction. Before using the output in production, open it in Tableau, review the KPI values and labels, exercise relevant filters and dates, and compare the unaffected views with the original workbook. Sales and Profit also have different business meanings: preserving a formula's structure does not establish that its interpretation remains appropriate.

This example is about a single worksheet. It is not a claim that every multi-sheet KPI module or arbitrary workbook can be migrated without review, and it makes no timing guarantee.

At Datacooper, I am building toward workflows that make those boundaries visible: clear inputs, inspectable changes, editable workbooks and evidence of the result. A paid MCP remains planned; the public SDK example is available now.

Sources:

• Original Datacooper post
• Actual example script
• Worksheet-refactor test source

Explore cwtwb on GitHub and Datacooper.