Build a Custom Tableau KPI Extension with Claude Code

Natively, a KPI card with a big number, a trend sparkline and a period over period change means objects stacking up on a dashboard. Eric says he counted five or six calculated fields for a single measure on a recent dashboard, because the data source did not already have them.

The viz extension only needs a measure and a date. Everything else, the comparison, the trend, the formatting, lives in the extension and its config.

Asked whether extensions need API tokens, Eric says the KPI card does not. If you are specific about what the extension should do, such as analyzing calculated fields and their dependencies, it is static code and just runs.

If you want it to answer questions about the data, or summarize a dashboard that changes on every refresh, the simplest route is an API key to a model. He mentions burning through a month of API balance in one evening when a setup was not efficient, and that going through Claude Code or Claude Desktop is much cheaper.

Attendees open a new sheet, pick Extension from the Marks dropdown, choose Access Local Viz Extensions and select the downloaded .trex. Tableau shows the developer and the URL, which points at the GitHub repo, and the card asks for a measure and then a date.

The idea is that as Eric pushes changes, anyone can reselect the extension from the Marks dropdown to pick them up. The first card shows SUM(Sales) at 2.3 million, which Eric checks against a plain sheet.

The KPI cards are viz extensions: they sit on a worksheet and render that sheet's marks. Eric shows a dashboard extension he built on the latest Makeover Monday data that finds map locations on the dashboard and interacts with them, plus an animated radar.

Josh points out that for a dashboard summary, a dashboard extension is the stronger choice, since you can attach all your worksheets and give it broader context.

A viewer notices the background color setting changes a layer behind the card, not the card itself. Eric describes it to Claude Code, pushes, refreshes, and it is still wrong. So he drops in a screenshot, since Claude is very good at reading images.

Meanwhile other config options work on the first try, including abbreviating large numbers to thousands or millions and setting decimal places.

Eric usually runs in auto mode and iterates in short loops with the extension open side by side. Plan mode up front, or a much more detailed prompt, can cut down the back and forth.

The long starter prompt he shared at the beginning was really prompt three or four in a series. He refined it until it worked the first time from a clean start.

GitHub Pages is not immediate, and refreshing an extension sometimes means adding it again from the same .trex. It gets hard to know whether a change made it through, so Eric asks Claude Code for a development version badge on the card.

He then switches the build to localhost with a local server to iterate faster. The missing sparkline turns out not to be a code bug: on refresh, Order Date had dropped to Detail, and moving it back to the date encoding brings the sparkline in.

A viewer asks what type of period the card compares. Eric wants the config to define the current period and what prior means, with a small label that spells out the date range. The card currently follows the date pill's aggregation, so switching to continuous month changes the trend line.

The work gets messy. Two chats running on overlapping code miss each other's changes, extension caching hides updates until a new sheet breaks it, and by the end the sparkline works but the change labels still need troubleshooting. Eric says he will finish it and push it to the repo.