Review a Tableau Workbook with AI: Audit Checklist

A Tableau workbook review is one of the best jobs to give an AI, and one of the easiest to get wrong. The model can read every calculation in a workbook in seconds. It cannot see the dashboard, the data or how slow it feels to a user on Monday morning. If you know which half of the review it can do, it's a fast, tireless first reviewer. If you don't, it will confidently tell you a workbook is "well optimized" based on nothing.

Here's how I review workbooks with AI: what's actually in the file, a review prompt, a checklist, and the two free tools I built at TableauOps for exactly this.

What is a .twb file, and can AI read it?

A .twb is plain XML. Open one in a text editor and you'll see it. A .twbx is a packaged workbook: a zip archive that holds the .twb plus any local files and extracts it needs. Tableau's page on file types and folders covers both.

The XML describes the workbook, not the data. Roughly, it contains:

• Data sources and connections: connection types, server names, file paths, whether an extract is used, custom SQL.
• Fields: every column, its caption, data type and role, whether it's hidden, and for calculated fields the full formula.
• Parameters.
• Worksheets: what's on Rows, Columns and the Marks card, and the filters on each sheet.
• Dashboards: size settings and the layout zones, including filter cards, legends and objects.
• Formatting and styles.

That's a lot for a language model to work with, and models handle XML well. So yes, AI can read it. The question is what it can judge from it.

What can AI judge from a workbook, and what can't it?

It can judge structure. Anything visible in the XML is fair game:

• Calculations: naming, complexity, nesting depth, copy-pasted logic, LOD and table calc usage.
• Unused fields: fields in the data pane that no sheet or calc references.
• Hidden fields and default names like Calculation1 or Sheet 12.
• How many filter cards each dashboard carries, and its sizing mode.
• Live versus extract connections, hard-coded local file paths, duplicate connections to the same table.

It can't judge runtime. None of this is in the file:

• Mark counts. How many marks a view draws depends on the data, which isn't in the .twb.
• Query and render times. Only a run tells you that. Tableau's performance recording is the tool for real timings.
• Whether the numbers are right. The model sees the formula, not the result.
• Whether anyone uses it. Usage lives on the server, not in the workbook.

So frame the AI review as a structural review. Anything about speed that comes out of it is a hypothesis to test, not a finding.

How do I get the XML into the model?

Real workbooks are big. A production .twb can run to many thousands of lines, much of it style and layout noise. Two approaches:

1. Paste the whole .twb if it fits in the model's context. Fine for small workbooks.
2. Extract what matters. For calc review I pull just the calculated fields with a few lines of Python:

import sys
import zipfile
import xml.etree.ElementTree as ET

path = sys.argv[1]
if path.endswith(".twbx"):
    with zipfile.ZipFile(path) as z:
        twb = next(n for n in z.namelist() if n.endswith(".twb"))
        root = ET.fromstring(z.read(twb))
else:
    root = ET.parse(path).getroot()

for col in root.iter("column"):
    calc = col.find("calculation")
    if calc is not None and calc.get("formula"):
        label = col.get("caption") or col.get("name")
        print(f"{label}\t{col.get('name')}\n    {calc.get('formula')}\n")

A note on how the output looks: Tableau stores a calc's internal name (something like [Calculation_1234567890]), and formulas that reference other calcs use those internal names. Keep both columns in what you paste so the model can follow the references.

Before you paste anything into a chat, scrub it. A workbook can contain server names, database names, file paths, usernames in custom SQL and filter values that are themselves sensitive. Check your company's AI policy first. If that's a problem, use a tool that never sends the file anywhere (more on that below).

A prompt for reviewing a Tableau workbook

This is the prompt I start from. The rules at the top are what keep the review honest.

You are reviewing a Tableau workbook. Below is its XML (or an extract of it).

Rules:
- Only report what you can see in the XML. Quote the field, sheet or
  dashboard name for every finding.
- You cannot see the data, mark counts or query times. Do not claim
  anything is slow or fast. You may flag things that commonly hurt
  performance, labeled "check with a performance recording".
- Use Tableau terms (LOD, table calculation, context filter, extract).

Review for:
1. Calculations: unclear names, deep nesting, duplicated logic,
   LODs and table calcs that might be doing the same job twice.
2. Unused or hidden fields, default names (Calculation1, Sheet 3).
3. Dashboards: number of filter cards, sizing mode, sheet count.
4. Data sources: live vs extract, local file paths, duplicate
   connections, custom SQL.
5. Anything a new developer would struggle to maintain.

Output a table: severity (high/medium/low), location, finding, suggested fix.
Then list the three changes you would make first.

Tableau workbook audit checklist

This is what I check, whether or not AI is helping. The AI pass covers the structural items quickly; the runtime items need Tableau itself.

Performance

• Extracts versus live. Is each source extracted where it should be, and live where freshness matters? Are extracts filtered and aggregated, or pulling every column?
• Filter cards. A filter card has to query for the values it shows, and one set to "only relevant values" has to re-query when other filters change. A dashboard with a dozen of them pays for that on every interaction. Filter actions are often the lighter alternative. Tableau's workbook performance guidance is the starting point for this section.
• LOD count. Each LOD becomes part of the query. A handful is normal. Dozens on one sheet is worth a look.
• Mark counts. Large crosstabs and dense scatter plots are the usual culprits. Check with a performance recording, not the XML.
• Dashboard size. Automatic sizing lays the dashboard out again for each window size, so cached results are reused less between users. A fixed size is the common recommendation, and dashboard sizing is one of the things Tableau's Workbook Optimizer checks.

Tableau Desktop also ships a Workbook Optimizer. From the Server menu, click Run Optimizer, and it checks the workbook against Tableau's performance best practices. Read the Workbook Optimizer docs. Run it alongside any AI review; it's built by the people who wrote the query engine.

Maintainability

• Naming. Can a new developer tell what Calc_v2_final does? Ask the AI to propose names.
• Unused fields. They clutter the data pane and can bloat extracts.
• Hidden calcs. Hidden fields that other calcs depend on are where bugs live.
• Duplicated logic. The same CASE in three calcs will drift apart. Pull it into one.
• Comments. Calcs accept // comments. Complex ones should have one.

Design

The XML can tell you a dashboard has fourteen sheets and nine filters. It can't tell you whether the main number is readable. For design, you need something that looks at the rendered viz.

TableauOps tools: the Workbook Roast and the Viz Assay

I built two free tools for this, because I wanted reviews that don't depend on pasting a workbook into a chat.

The Workbook Roast

The Workbook Roast reads a .twb or .twbx right in your browser tab. Parsing happens locally; the page makes no network request with your workbook, and it walks you through checking that yourself in the Network tab. It returns a score out of 100 and reports on unused fields, connections that double up on the same table, hard-coded file paths, calculations that need review (the longest, the deepest and the copy-pasted), and dashboard load: filter cards and sizing modes, dashboard by dashboard. It works with workbooks from Tableau Desktop, Server or Cloud downloads.

That's the structural pass from the checklist above, without sending the file anywhere.

The Viz Assay

The Viz Assay is a score out of 100 for how good a viz is, produced by a tool I call the Refiner. You drop a workbook or paste a Tableau Public link. It checks the viz against the rules Tableau's own authoring AI is given and names every flaw with a fix. It works in layers: a spec lint that reads the workbook XML (chart choice, sorting, axes that skip zero, unsynced dual axes, rainbow scales, red against green, crowded dashboards, default names and tooltips), and a render-and-judge layer, live for Tableau Public links, where Tableau renders the view, the Refiner checks the palette, simulates color blindness and contrast, and a vision model reviews labels, titles and legibility. A third layer that checks the data behind the viz is listed on the page as next. Workbook files dropped on the Assay page are processed in your browser.

Roast for maintainability and load, Assay for design. Then an AI chat for the questions specific to your workbook.

Can AI replace a human workbook review?

No, and it doesn't need to. A good AI pass catches the things humans skip because they're boring: the forty unused fields, the copy-pasted calc, the eleventh filter card. That frees the human reviewer for the questions only they can answer. Does this dashboard answer the question it was built for? Is the metric definition right? Would the audience trust it?

For more on where that line sits, see AI for Tableau developers: what to hand off and what to keep. If the review turns up calcs you need to rewrite, write Tableau calculated fields with AI has the prompts and the checks.

Next step

Drop one of your own workbooks on the Workbook Roast and see what it finds. Then take its top finding, run the review prompt above against that part of the XML, and compare. More guides are on the Tableau + AI hub.