DEV Community: Datacooper

Clone a Tableau KPI from the browser: inputs and checks for Datacooper's web tool

Datacooper — Mon, 12 Oct 2026 01:07:24 +0000

A request such as “make a Quantity version of this Sales KPI” needs more than a new label. The copied worksheet needs the right field references, calculations and formatting, and the original worksheet still needs to work.

Datacooper's Tableau KPI Cloner offers a browser form for this focused task. This article documents the current interface and a practical review checklist. The image is the original Datacooper brand logo.

What to prepare

The current form accepts a TWB or TWBX workbook and asks for a source worksheet, a target worksheet, the metric to replace, its replacement and an output filename.

For example, you might specify an existing Sales KPI worksheet, a new Quantity KPI worksheet, Sales as the source metric and Quantity as the replacement. These are illustrative inputs: use the exact names in your own workbook and confirm that the destination field exists.

Upload only a workbook you are authorized to process. The page states that the form uses a server-side executor. Treat file submission as a separate decision from reading the page; this article makes no data-retention guarantee.

What the tool is intended to return

The page describes a downloadable workbook containing a copied KPI worksheet with the requested core metric replacement. This puts a focused workbook-editing operation behind a web form, so the analyst does not have to begin by writing a Python script.

The form's source component submits a clone_kpi_card job with the workbook and field names. I inspected that component and the live page for this article. I did not submit a workbook or execute a new cloning or Tableau rendering test, so this update establishes the interface, not successful processing of an arbitrary file.

Review the workbook before using it

Open the returned workbook in Tableau Desktop and check the copied worksheet against your intended metric. In particular:

Confirm the new sheet and its field references.
Inspect dependent calculations, filters and table calculations.
Check number formats: a quantity should not inherit currency formatting unnoticed.
Compare the original worksheet and other affected views with the input workbook.
Confirm whether a dashboard needs an explicit change to display the new sheet; copying a worksheet is not the same as migrating a dashboard.

The current tool page explicitly limits the task to KPI worksheet copying. It does not promise arbitrary dashboard migration or automatic correction of every dependency. A plausible-looking result still needs a check of the business values.

Where this fits in Datacooper

The original post introduced the web tool as a way to lower the barrier between programmatic workbook editing and everyday analyst work. The current interface preserves that focused input-and-output approach.

cwtwb is the open-source workbook engineering foundation. Datacooper is the website entry point for tools and project context. The planned paid MCP is a future service direction; this article does not describe it as an available paid product or promise a processing time or success rate.

Explore the Tableau KPI Cloner and review its limits before processing your own workbook.

Sources and project links

Original Datacooper post, retained as historical source attribution.
Published demo video, referenced by the existing source article; not replayed or validated for this update.
cwtwb on GitHub.
Case reconstruction repository.
Datacooper.
MCP early access: in preparation.

Reuse the Tableau layout, then rebuild the analysis: a Datacooper workflow

Datacooper — Sun, 11 Oct 2026 01:04:58 +0000

A dashboard's arrangement can be worth keeping even when its data and business question change. Rebuilding nested containers, spacing and text from scratch adds work before you have begun the new analysis.

Datacooper's Tableau Layout Extractor is designed for that narrower task: take a workbook and produce a reusable structural starting point. The image above is a real screenshot of the current tool page, captured on October 11, 2026. It shows the input, output and limits; it is not a screenshot of a completed extraction or a validated Tableau rendering.

What goes in and what comes out

The current form accepts a TWB or TWBX workbook. You can optionally specify dashboard names and choose filenames for the layout JSON and layout-only TWB output.

The intended output contains containers, blank objects and text objects. Charts, data sources and worksheet content are outside that layout-only output. This distinction is useful when you want to keep the arrangement while replacing the analysis.

For example, suppose a team likes the hierarchy of an existing executive dashboard: a title, a KPI row and two detail panels. A layout skeleton gives the next project a place to start. The new project still needs its own data connections, worksheet definitions, calculations and interactions.

Keep structure separate from meaning

A layout JSON file makes the arrangement inspectable. A layout-only workbook gives a Tableau developer an artifact to review and extend. Neither establishes that the new dashboard answers the right question.

Before treating the output as a reusable template, review it in Tableau Desktop:

Check container nesting, dimensions, spacing and retained text.
Replace text that belongs to the old business context.
Bind new worksheets to the appropriate data and metric definitions.
Check filters, actions and relevant dashboard states after adding the analysis.

These are recommended checks, not a claim that I ran a new extraction or completed those checks for this article. Today's verification covers the live tool page and its form implementation. The frontend sends the tableau_file_to_layout action with objects_only restoration mode to the existing server-side executor.

What the historical post does not establish today

My original post described this layout-reuse direction and mentioned tiled layouts. I am not extending that historical note into a current floating-layout compatibility promise. Review the particular workbook you intend to reuse.

I am also not repeating the old blanket claim that no uploaded data is stored. The current page identifies a server-side executor. Submit only files you are authorized to process and establish suitable handling requirements before using sensitive workbooks.

The open-source cwtwb repository is the broader workbook engineering context. Datacooper's planned paid MCP is a separate product direction: help carry a BI task through clearer inputs, construction and review. Access is not open yet; this article does not announce a paid service launch.

Try the focused Tableau Layout Extractor, and review its output before incorporating it into a new dashboard.

Sources and project links

Original historical post — retained as a source only.
Current tool description, inputs and limits.
cwtwb on GitHub.
Public workbook replication cases.
Datacooper and planned MCP early access.

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

Datacooper — Sat, 10 Oct 2026 01:07:07 +0000

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:

Explore cwtwb on GitHub and Datacooper.

Screenshot to layout JSON to TWB: a cwtwb dashboard skeleton experiment

Datacooper — Sun, 04 Oct 2026 11:18:50 +0000

Nested Tableau containers can consume a surprising amount of dashboard-building time. In this experiment, I asked an AI to infer a layout from a screenshot, save layout JSON and use cwtwb to generate a workbook.

The output deliberately used text placeholders. I explicitly allowed mocked calculations because this test was about layout construction.

The prompt's important boundary

Generate the layout JSON and save it locally, then use this JSON
to generate the final dashboard. I don't need you to perfectly
replicate the calculations; you can just mock up a few.

This is an excerpt from the original prompt, rather than a runnable SDK example.

Why the intermediate JSON helps

The workflow has three inspectable stages:

Reference screenshot -> layout JSON -> Tableau workbook (.twb)

A screenshot communicates arrangement. The layout description makes horizontal and vertical nesting explicit. The workbook turns that description into an artifact that can be opened and edited in Tableau.

The generated skeleton looked unfinished because its job was to expose structure, not to impersonate a verified production dashboard. The container hierarchy was the focus of the original review.

What still needs to happen

This demonstration does not establish pixel-perfect replication or calculation correctness. Real data bindings, calculations, styles and interactions need their own implementation and checks.

That distinction is central to cwtwb's development: build from public SDK operations, then verify the artifact against a concrete case. Datacooper's planned paid MCP should help carry that workflow further toward finished BI work, with reviewable intermediate results.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

From raw data to a dashboard blueprint: testing a Tableau design Skill

Datacooper — Sun, 04 Oct 2026 11:13:31 +0000

Before generating a workbook, an agent needs to decide what the dashboard is for. I tested Adam Mico's open-source Tableau Dashboard Blueprint Skill with the Antigravity CLI to explore that step.

The experiment produced a technical specification and an interactive HTML prototype. It was a design test, not proof of a completed Tableau workbook.

What the Skill helped make explicit

The design identified a sales-manager audience, a short review window, KPI hierarchy and a restrained filter set. It also described the layout and the charts that would answer the intended questions.

The technical specification included container hierarchy and calculation definitions. The HTML prototype made the proposed arrangement easier to review before implementation. In the original experiment, simulated regional filtering updated the prototype KPIs.

Those are different outputs with different purposes: the specification tells a builder what to implement; the prototype lets someone inspect the proposed experience.

Where cwtwb fits

My next-step proposal in the original post was to connect the design workflow to cwtwb. That was a plan at the time, and I am preserving that distinction here.

A useful future workflow would take an agreed specification, construct a Tableau workbook through the SDK and compare the result with the intended design. It would still need to check the real data and calculations separately from the prototype.

For Datacooper, this suggests a practical product direction: help users move from a business question to an inspectable build specification and an editable artifact. The paid MCP is planned around that broader task.

Credit and references:

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

What a Tableau MCP source-code experiment taught me about workbook authoring

Datacooper — Sun, 04 Oct 2026 11:13:12 +0000

When I explored the official tableau-mcp source in an earlier experiment, one area caught my attention: workbook tools under src/tools/desktop/workbook/.

The screenshot and original LinkedIn post record that historical observation. This article describes the design idea I took from it; it does not assert that those tools are currently available to every developer.

Three names that made the workflow interesting

The tool names recorded in my original analysis were:

get-workbook-xml
batch-create-and-cache-sheets
apply-workbook

Read together, they suggest an authoring workflow with separate steps: inspect the existing workbook, prepare new sheets, then apply changes. That is a useful design distinction for an agent: reading, creating and committing changes are different operations.

This is my interpretation of the names and the historical source observation. It is not proof of public access to a Desktop Agent API, and I am not claiming I successfully executed that internal workflow.

Why it matters for cwtwb

There are several ways to approach AI-assisted BI. One works with an active application. Another generates a workbook artifact programmatically. cwtwb focuses on the latter through a Python SDK and MCP-facing capabilities.

Both approaches raise the same practical questions: what did the agent change, can we inspect the result, and is the calculation correct?

An official project exploring workbook authoring is relevant technical context. It is not an endorsement of Datacooper or evidence of market leadership.

My work at Datacooper is to turn that authoring direction into repeatable examples and checked artifacts. A future paid MCP should earn its value by helping users complete BI tasks, not merely by exposing more tool names.

Project context: Tableau MCP repository.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

An AI semi-donut experiment: who checks the visualization logic?

Datacooper — Sun, 04 Oct 2026 11:02:41 +0000

A semi-donut chart looks small on a dashboard. Building it can involve considerably more work than its appearance suggests.

In this early experiment, I gave an AI reference material and asked it to produce the calculation logic and visualization. The original screenshot shows the output. My role shifted toward specifying the design, reviewing it and iterating, rather than manually writing every step.

Why this experiment mattered

The hard part of an unusual chart is not simply choosing a mark type. The calculation and visual construction need to agree. A plausible-looking chart can still misrepresent the underlying value.

That makes this a useful test of AI-assisted Tableau authoring. Can an agent translate the reference into a workbook? Can a human understand and check what it produced?

Keep generation and verification separate

For this kind of chart, I would review the source values, how they map to the visible shape, the labels and any assumptions about the scale. Those are review criteria, not a claim that this historical screenshot includes a complete audit.

The original post also discussed Tableau Prep automation. Data preparation and workbook authoring are distinct stages; a good-looking final chart cannot establish that its upstream data pipeline is correct.

At Datacooper, cwtwb is the open-source workbook authoring foundation. The case replication repository provides a place to exercise capabilities against concrete examples and retain validation evidence.

The commercial opportunity I am exploring is a paid MCP that helps analysts finish actual BI work: specify the question, construct the workbook and review the output. The analyst's judgment remains central.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.

Building an editable Tableau dashboard with cwtwb and MCP

Datacooper — Sun, 04 Oct 2026 11:02:17 +0000

A dashboard generated by AI should leave you with a workbook you can keep working on. That was the question behind this early cwtwb experiment: could an agent assemble a Tableau dashboard without manually dragging sheets onto the canvas?

The screenshot shows the resulting workbook alongside the prompt. It includes sales by sub-category, sales by category, a monthly profit trend and a regional sales breakdown. The useful output is the Tableau .twb file, rather than an image of a dashboard.

How the workflow works

Describe the charts and dashboard you need.
The agent calls the MCP tools to configure workbook elements.
The implementation writes the workbook structure, including worksheets and layout containers.
Open the output in Tableau and review the result.

A TWB stores workbook definitions as XML. cwtwb provides a Python SDK so callers can work with higher-level operations instead of assembling that XML manually. MCP gives an agent a way to call those operations.

What this demonstration does and does not prove

This is a retrospective of an early prototype. The screenshot demonstrates workbook authoring; it does not prove every business calculation or interaction is correct. A production workflow also needs input checks, calculation validation, rendered output and tests of relevant parameter or filter states.

Today, the open-source SDK and the Workout Wednesday replication repository help make that review process concrete: a build script, locked input data, a workbook and recorded checks.

My planned paid MCP builds on that direction: help complete real BI tasks with clearer inputs, repeatable builds and evidence of the result. It remains a product plan, not a claim that every BI task is already automated.

Originally shared in this LinkedIn post.

Explore cwtwb on GitHub, the case replication repository and Datacooper.