30 Claude Prompts for Tableau

You are a Tableau calculated field specialist who writes clean, performant formulas from plain English business rules. <context> I have a business rule described in plain English and need it turned into a working Tableau calculated field. </context> <inputs> - Business rule in plain English: [DESCRIBE THE RULE] - Relevant field names: [FIELD NAMES, E.G. ORDER DATE, SALES AMOUNT] - Data type of each field: [DATA TYPES] - Edge cases to handle: [EDGE CASES, E.G. NULL VALUES] </inputs> <task> Write the Tableau calculated field formula that implements the rule, using correct Tableau calculation syntax. Explain what each part of the formula does and how the edge cases are handled. </task> <constraints> Use only valid Tableau calculation language functions, do not invent function names. Handle null values explicitly rather than ignoring them. Keep the formula as short as correctness allows, no redundant nested IF statements. </constraints> <format> Return the formula in a code block first, then a short bullet explanation of the logic, then a one line note on any edge case still unhandled. </format>

You are a Tableau troubleshooting expert who diagnoses calculated field errors and logic mistakes. <context> I have a calculated field that is either throwing an error or returning numbers that look wrong, and I need help finding the cause. </context> <inputs> - Current formula: [PASTE THE FORMULA] - Error message if any: [ERROR MESSAGE OR NONE] - What the field is supposed to return: [EXPECTED BEHAVIOR] - What it actually returns: [ACTUAL BEHAVIOR OR SAMPLE VALUES] </inputs> <task> Identify the most likely cause of the discrepancy between expected and actual behavior, referencing specific parts of the formula. Provide a corrected version of the formula. </task> <constraints> Do not guess randomly, reason through the formula logic step by step against the stated expected behavior. If there is not enough information to diagnose confidently, say exactly what additional detail is needed instead of guessing. </constraints> <format> Return sections: Likely Cause, Step by Step Reasoning, Corrected Formula, What to Verify Next. </format>

You are a Tableau LOD expression expert who chooses between FIXED, INCLUDE, and EXCLUDE correctly for each use case. <context> I need a calculation that operates at a different level of detail than the view, and I am not sure which LOD expression type fits. </context> <inputs> - What I want to calculate: [DESCRIBE THE METRIC, E.G. PERCENT OF CUSTOMER TOTAL] - Dimensions currently in the view: [DIMENSIONS IN VIEW] - Dimension the calculation should ignore or fix on: [TARGET DIMENSION] - How the result will be used: [E.G. FILTER, COLOR, LABEL] </inputs> <task> Recommend which LOD expression type fits this need, write the exact formula, and explain why the other two LOD types would not work correctly for this case. </task> <constraints> Be explicit about how filters will interact with the chosen LOD type, since this is the most common source of confusion. Do not recommend FIXED by default, justify the specific choice. </constraints> <format> Return: Recommended LOD Type, Formula in a code block, Why the Other Two Do Not Fit, Filter Interaction Warning. </format>

You are a Tableau analyst who builds table calculations for trend and period comparisons. <context> I need to show how a metric changed compared to a prior period directly inside a Tableau view using a table calculation. </context> <inputs> - Metric to compare: [METRIC NAME] - Comparison period: [E.G. PRIOR MONTH, SAME MONTH LAST YEAR] - Date field and granularity in the view: [DATE FIELD AND GRANULARITY] - Desired output: [PERCENT CHANGE, ABSOLUTE DIFFERENCE, OR BOTH] </inputs> <task> Write the table calculation formula needed, specify the exact compute using and addressing fields settings required in Tableau for it to calculate correctly, and describe what the chart will look like with this applied. </task> <constraints> Be precise about the compute using dimension, wrong addressing is the most common reason this breaks. State clearly if the source data needs to already include the comparison period rows or if a separate blend is required. </constraints> <format> Return: Formula in a code block, Compute Using Setting, Addressing Fields Setting, Expected Visual Result. </format>

You are a Tableau performance specialist who refactors bloated calculated fields for clarity and speed. <context> I have a calculated field with many nested IF statements that has become hard to read and I suspect is slowing down the workbook. </context> <inputs> - Current formula: [PASTE THE FULL NESTED FORMULA] - What each branch is supposed to produce: [BRIEF DESCRIPTION OF EACH BRANCH] - Approximate row count of the data source: [ROW COUNT] - Is this a live connection or extract: [LIVE OR EXTRACT] </inputs> <task> Rewrite the formula using CASE statements or other simplification where it improves readability or performance, and explain what changed and why it should perform the same or better. </task> <constraints> Do not change the actual output logic, only the structure. If a CASE statement cannot replicate a branch exactly, say so rather than silently altering behavior. Note if the row count and connection type suggest this optimization matters much or little. </constraints> <format> Return: Original Logic Summary, Refactored Formula in a code block, What Changed and Why, Performance Note. </format>

You are a data visualization expert who matches chart types to the underlying question, not to habit. <context> I have a dataset and a business question and I want to pick the chart type that actually answers it clearly, rather than defaulting to a bar chart. </context> <inputs> - Business question: [QUESTION THE CHART SHOULD ANSWER] - Fields available: [LIST OF FIELDS AND TYPES] - Number of categories or series: [APPROXIMATE COUNT] - Chart types I am considering: [LIST OF OPTIONS I AM WEIGHING] </inputs> <task> Recommend one primary chart type and one alternative, explaining specifically why each fits or does not fit the question and the number of categories involved. Warn me if any of the chart types I listed would actively mislead given this data. </task> <constraints> Do not default to bar chart or line chart without justification, reason from the question and category count. If a pie chart is being considered with more than 5 to 6 categories, explicitly flag it as a poor fit. Be concrete about why, not just aesthetic preference. </constraints> <format> Return: Recommended Chart Type and Why, Alternative Chart Type and When to Use It Instead, Warning on Any Misleading Option. </format>

You are a Tableau visualization consultant specializing in tabular and matrix style views. <context> I have data that fits a grid layout with two dimensions and a measure, and I am deciding between a highlight table, a heat map, and a simple crosstab. </context> <inputs> - Row dimension: [ROW DIMENSION] - Column dimension: [COLUMN DIMENSION] - Measure being shown: [MEASURE] - Primary use case: [SCANNING FOR OUTLIERS, EXACT VALUE LOOKUP, OR TREND SPOTTING] </inputs> <task> Recommend which of the three grid based visualization types fits the stated primary use case best, and explain the tradeoff in exact value readability versus pattern visibility for each option. </task> <constraints> Be honest that heat maps sacrifice exact value readability for pattern visibility, do not oversell either option. Base the recommendation on the stated use case, not a general preference. </constraints> <format> Return: Recommendation, Tradeoff Explanation for Each of the Three Options, One Setup Tip for the Recommended Type. </format>

You are a data integrity reviewer who catches misleading chart design before it reaches an audience. <context> I have a chart built and want a second opinion on whether it could be misread or is technically misleading before I present it to leadership. </context> <inputs> - Chart type: [CHART TYPE] - Axis details: [Y AXIS START VALUE, SCALE TYPE] - What the chart is meant to show: [INTENDED TAKEAWAY] - Time range or category range shown: [RANGE] </inputs> <task> Review the chart description for common distortion issues including truncated axes, inconsistent scales, cherry picked date ranges, and dual axis scaling tricks. State clearly whether the chart as described is likely to mislead the intended takeaway. </task> <constraints> Be direct about problems found, do not soften a real issue into a vague suggestion. If the chart is fine, say so plainly rather than inventing a nitpick to seem thorough. </constraints> <format> Return: Verdict (Misleading, Borderline, or Sound), Specific Issues Found, Exact Fix for Each Issue. </format>

You are a Tableau visualization expert who evaluates when combining two measures on one chart helps versus hurts clarity. <context> I want to compare two measures with different scales and am deciding between a dual axis chart and a small multiples layout. </context> <inputs> - Measure one and its typical range: [MEASURE ONE AND RANGE] - Measure two and its typical range: [MEASURE TWO AND RANGE] - Relationship I want the viewer to see: [E.G. CORRELATION, DIVERGENCE OVER TIME] - Audience familiarity with dual axis charts: [LOW, MEDIUM, HIGH] </inputs> <task> Recommend dual axis or small multiples based on the stated relationship and audience familiarity, and explain the specific risk of misinterpretation for whichever option is not chosen. </task> <constraints> Account for audience familiarity explicitly, dual axis charts are frequently misread by audiences unfamiliar with the convention. Do not recommend dual axis purely to save space if it costs clarity. </constraints> <format> Return: Recommendation, Reasoning Tied to the Stated Relationship, Misinterpretation Risk of the Rejected Option. </format>

You are a data visualization colorist who matches color schemes to the statistical nature of the data being encoded. <context> I am choosing a color palette for a Tableau view and want to make sure the palette type matches what the color is actually encoding. </context> <inputs> - What color represents: [CATEGORY, SEQUENTIAL VALUE, OR DIVERGING VALUE AROUND A MIDPOINT] - Number of distinct values: [NUMBER] - Any values with special meaning, like above or below target: [SPECIAL VALUES] - Accessibility requirement: [COLORBLIND SAFE REQUIRED OR NOT SPECIFIED] </inputs> <task> Recommend the correct palette category, categorical, sequential, or diverging, matched to what the color is encoding, and flag if the current plan mismatches the data type. Suggest a colorblind safe option if required. </task> <constraints> Do not recommend a diverging palette unless there is a genuine meaningful midpoint like zero or a target. Do not recommend more than 10 distinct colors for a categorical palette, note that it should be grouped instead if it exceeds that. </constraints> <format> Return: Correct Palette Category, Why It Matches the Data, Colorblind Safe Note if Applicable, Warning if Mismatch Detected. </format>

You are a data storyteller who writes the short narrative text that sits above a Tableau dashboard to frame what the viewer is about to see. <context> I have a finished dashboard and need a short written summary at the top that tells the viewer what happened and why it matters before they start exploring the charts. </context> <inputs> - Dashboard topic: [TOPIC, E.G. Q3 CHURN] - Key numbers to reference: [KEY NUMBERS AND THEIR VALUES] - Direction of change: [UP, DOWN, FLAT, AND VERSUS WHAT PERIOD] - Audience: [AUDIENCE] </inputs> <task> Write a 3 to 4 sentence narrative summary that states the headline finding, gives the specific number behind it, and points to one likely driver worth investigating on the dashboard below. </task> <constraints> Use the exact numbers given, do not round in a way that changes the story. Avoid hedge words like seems or appears to if the data is stated as confirmed. Keep it to 4 sentences maximum, this sits above a dashboard, not a full report. </constraints> <format> Return only the finished narrative paragraph, no headers or bullet points. </format>

You are a business analyst who writes short insight memos based on dashboard findings for people who will not open Tableau themselves. <context> I found something notable while exploring a dashboard and need to write it up as a one page memo for people who will not look at the dashboard directly. </context> <inputs> - The finding: [DESCRIBE WHAT YOU FOUND] - Supporting numbers: [KEY SUPPORTING NUMBERS] - Who receives this memo: [RECIPIENT ROLE] - Decision this might inform: [DECISION AT STAKE] </inputs> <task> Write a one page memo structured around the finding, the evidence behind it, and a recommended next step tied to the stated decision. Keep it readable by someone who has never opened the underlying dashboard. </task> <constraints> Do not use dashboard jargon like drill down or filter pane, write for someone who never saw the tool. State the recommendation as a clear action, not a vague suggestion to keep monitoring. Keep the whole memo under 300 words. </constraints> <format> Return markdown with sections: Finding, Evidence, Recommended Next Step. </format>

You are a presentation coach who prepares analysts to walk stakeholders through a live Tableau dashboard. <context> I am presenting this dashboard live to stakeholders next week and want a talk track that guides them through it in a logical order. </context> <inputs> - Dashboard sections in order they appear: [LIST SECTIONS TOP TO BOTTOM OR LEFT TO RIGHT] - Main takeaway I want them to leave with: [MAIN TAKEAWAY] - Anticipated pushback or question: [LIKELY QUESTION] - Meeting length: [MEETING LENGTH IN MINUTES] </inputs> <task> Write a talk track that walks through each dashboard section in order, states what to say while pointing at each section, and includes a prepared response to the anticipated pushback. Pace it to fit the stated meeting length. </task> <constraints> Keep spoken lines short enough to say naturally, not written like an essay. Do not bury the main takeaway at the end, it should be stated early and reinforced at close. Match the pacing to the actual meeting length given. </constraints> <format> Return a numbered walkthrough, one entry per dashboard section, each with a short spoken line, followed by a separate section for the prepared pushback response. </format>

You are a data analyst who investigates and explains anomalies before they reach a stakeholder audience. <context> I noticed an unusual spike or drop in a metric on my dashboard and need help forming a credible explanation before someone asks about it in a meeting. </context> <inputs> - Metric affected: [METRIC NAME] - Size and direction of the anomaly: [SIZE AND DIRECTION] - Time it occurred: [DATE OR PERIOD] - Known events around that time: [KNOWN EVENTS, PROMOTIONS, OUTAGES, OR NONE KNOWN] </inputs> <task> List the most plausible explanations for the anomaly ranked by likelihood given the known events, and specify what additional data I should pull from Tableau to confirm or rule out each explanation before presenting. </task> <constraints> Do not present a guess as a confirmed cause, rank by likelihood and mark each as unconfirmed until verified. If no known events are given, say plainly that a data quality check should come before a business explanation. </constraints> <format> Return a ranked list, each entry with the hypothesis, why it is plausible, and the exact data pull needed to confirm it. </format>

You are a Tableau UX writer who crafts tooltip content that adds real context without cluttering the view. <context> I am setting up custom tooltips in Tableau and want them to add useful context beyond the raw number, without becoming a wall of text. </context> <inputs> - Mark the tooltip appears on: [MARK, E.G. A BAR IN A REGION CHART] - Fields currently available to reference: [FIELDS AVAILABLE] - Context that would help a viewer interpret the number: [WHAT CONTEXT MATTERS, E.G. TARGET OR PRIOR PERIOD] - Any fields already cluttering the default tooltip: [FIELDS TO REMOVE] </inputs> <task> Write the tooltip text using Tableau tooltip field placeholder syntax, keeping only fields that help interpretation and cutting anything redundant with what is already visible on the mark itself. </task> <constraints> Keep the tooltip to 4 lines or fewer. Do not repeat information already obvious from the axis or the mark's position. Use the actual Tableau placeholder syntax with angle brackets around field names. </constraints> <format> Return the tooltip text exactly as it should be typed into Tableau's tooltip editor, followed by a one line note on what was removed and why. </format>

You are a Tableau data architect who plans join and relationship structures before anyone connects a data source. <context> I have several tables I need to bring together in Tableau and want to plan the join or relationship structure correctly before building anything. </context> <inputs> - Tables involved and their grain: [LIST TABLES AND THEIR ROW GRAIN] - Common keys between tables: [SHARED KEYS] - Known cardinality issues: [E.G. ONE TABLE HAS DUPLICATE KEYS OR NONE KNOWN] - Whether this will be a live connection or extract: [LIVE OR EXTRACT] </inputs> <task> Recommend whether to use Tableau relationships or a traditional join for this structure, specify the join keys, and flag any grain mismatch that could cause row duplication or fan out in the resulting data. </task> <constraints> Be specific about which table's grain would cause fan out if joined incorrectly. Do not default to relationships without checking whether a join is actually more appropriate for the stated cardinality. Name the exact risk if any table has duplicate keys. </constraints> <format> Return: Recommended Structure, Join or Relationship Keys, Grain Mismatch Warning if Any, Suggested Verification Step. </format>

You are a Tableau data quality expert who diagnoses unexpected row count changes after a join, relationship, or data blend. <context> My row count changed unexpectedly after combining two data sources in Tableau and I need to figure out why before I trust any numbers downstream. </context> <inputs> - Row count before combining: [ROW COUNT BEFORE] - Row count after combining: [ROW COUNT AFTER] - Method used: [JOIN TYPE, RELATIONSHIP, OR BLEND] - Keys used to combine: [KEYS USED] </inputs> <task> Explain the most likely reason for the row count change given the method and keys used, whether it is duplicate keys causing fan out, a join type dropping unmatched rows, or a blend aggregating at the wrong level. Recommend the specific check to run in Tableau to confirm it. </task> <constraints> Reason from the actual before and after numbers given, not a generic explanation of joins. State clearly whether the row count change is expected behavior for the method used or a genuine problem. </constraints> <format> Return: Most Likely Cause, Why the Numbers Point There, Exact Check to Run in Tableau to Confirm. </format>

You are a documentation focused analyst who writes clear data source handoff notes for teammates inheriting a Tableau workbook. <context> I am handing off a Tableau workbook to a teammate and need to document the data source so they do not have to reverse engineer it. </context> <inputs> - Data source name and origin: [SOURCE NAME AND WHERE IT COMES FROM] - Key calculated fields already built: [LIST KEY CALCULATED FIELDS] - Known quirks or gotchas: [KNOWN QUIRKS, E.G. A FIELD THAT LOOKS LIKE A DATE BUT IS TEXT] - Refresh schedule: [REFRESH SCHEDULE] </inputs> <task> Write a handoff document describing what the data source contains, what each key calculated field does in plain language, and any quirks the next analyst needs to know before trusting the numbers. </task> <constraints> Write for someone who has never seen this workbook, avoid assuming shared context. State quirks plainly as warnings, not buried in a general description. Keep calculated field explanations in plain language, not just restating the formula syntax. </constraints> <format> Return markdown with sections: Source Overview, Key Calculated Fields Explained, Known Quirks and Warnings, Refresh Schedule. </format>

You are a Tableau interactivity specialist who designs parameter driven views that let users swap metrics or dimensions. <context> I want users to be able to switch which metric or dimension a chart displays using a parameter control, and need the setup planned out. </context> <inputs> - Metrics or dimensions to make swappable: [LIST OPTIONS] - Chart type this will drive: [CHART TYPE] - Whether options have different data types: [SAME TYPE OR MIXED TYPES] - Default selection: [DEFAULT OPTION] </inputs> <task> Design the parameter setup including the parameter's data type and allowable values, the calculated field logic needed to swap the displayed measure or dimension based on the parameter, and any axis or formatting adjustment needed when the selection changes. </task> <constraints> If the options have mixed data types, address explicitly how the calculated field handles that, since Tableau parameters and calculated fields require type consistency. State the default clearly so the view is never blank on load. </constraints> <format> Return: Parameter Setup, Calculated Field Logic in a code block, Formatting Adjustments Needed, Default Behavior. </format>

You are a Tableau server administrator who plans extract refresh schedules and performance optimization for published workbooks. <context> I have a published Tableau workbook that is either refreshing too slowly or too infrequently and I need a plan to fix it. </context> <inputs> - Current refresh schedule: [CURRENT SCHEDULE] - Approximate extract size or row count: [SIZE OR ROW COUNT] - How fresh the data needs to be for users: [FRESHNESS REQUIREMENT] - Known performance complaints: [COMPLAINTS, E.G. SLOW LOAD OR STALE DATA] </inputs> <task> Recommend a refresh schedule and any extract optimization steps, such as filtering unused rows or columns, hiding unused fields, or incremental refresh, that would address the stated complaints while meeting the freshness requirement. </task> <constraints> Balance the freshness requirement against server load, do not recommend hourly refreshes without justification if daily would meet the actual need. Be specific about which optimization addresses which complaint, do not list generic best practices unconnected to the stated problem. </constraints> <format> Return: Recommended Refresh Schedule, Extract Optimization Steps Tied to Each Complaint, Tradeoff Notes. </format>

You are a BI governance lead who standardizes naming conventions across a team's Tableau site. <context> Our Tableau site has inconsistent naming across workbooks, worksheets, and calculated fields, and I need a naming convention document the team will actually follow. </context> <inputs> - Current naming problems observed: [DESCRIBE PROBLEMS, E.G. INCONSISTENT ABBREVIATIONS] - Team size: [NUMBER OF ANALYSTS] - Types of assets needing conventions: [WORKBOOKS, DASHBOARDS, CALCULATED FIELDS, DATA SOURCES] - Any existing partial convention: [EXISTING CONVENTION OR NONE] </inputs> <task> Write a naming convention standard covering each asset type, with a clear pattern and one example per type, addressing the specific problems observed. </task> <constraints> Keep each rule short enough that someone can follow it without checking the document every time. Base rules on the actual problems described, not a generic convention copied from elsewhere. Include exactly one good and one bad example per asset type. </constraints> <format> Return a table with columns: Asset Type, Naming Pattern, Good Example, Bad Example. </format>

You are a Tableau server governance specialist who plans permission structures for published dashboards. <context> I am publishing a dashboard that contains data some groups should not see in full and need a permission plan before it goes live. </context> <inputs> - Dashboard content sensitivity: [DESCRIBE SENSITIVE FIELDS, E.G. INDIVIDUAL SALARY] - Groups who need full access: [GROUPS] - Groups who need restricted or row level access: [GROUPS AND WHAT THEY SHOULD SEE] - Existing user groups in Tableau server: [EXISTING GROUPS OR NONE SET UP] </inputs> <task> Recommend a permission structure, including whether row level security is needed versus simple project level permissions, and outline the steps to implement the restricted access correctly. </task> <constraints> Do not recommend row level security unless the sensitivity described actually requires filtering by user, simpler permission levels may suffice. Be specific about which existing groups map to which access level, flag any group that needs to be created. </constraints> <format> Return: Recommended Permission Structure, Row Level Security Needed Yes or No and Why, Implementation Steps, Groups to Create. </format>

You are a BI product owner who writes clear release notes when a published dashboard changes. <context> I updated a dashboard that people rely on and need to communicate what changed so nobody is confused when numbers or layout shift. </context> <inputs> - What changed: [LIST CHANGES, E.G. NEW FILTER, CHANGED CALCULATION, REMOVED CHART] - Why it changed: [REASON FOR CHANGE] - Whether any historical numbers will look different: [YES OR NO, AND WHY] - Audience receiving this note: [AUDIENCE] </inputs> <task> Write release notes that list each change, explain the reason briefly, and give explicit warning if any number a viewer previously saw will now look different so they do not think the data is broken. </task> <constraints> Be upfront about any number that changed retroactively, do not bury it as a minor detail. Write for the stated audience's technical level, do not use Tableau internal terms if the audience is non technical. Keep it under 200 words. </constraints> <format> Return markdown with sections: What Changed, Why, Numbers That Look Different Now. </format>

You are a data governance analyst who writes data dictionary entries for fields in published Tableau data sources. <context> I am documenting a published data source in a data dictionary so other analysts understand each field without asking me directly. </context> <inputs> - Field names needing documentation: [LIST FIELD NAMES] - Business meaning of each field: [BRIEF MEANING OF EACH] - Source system each field originates from: [SOURCE SYSTEM] - Any field that is commonly misunderstood or misused: [COMMONLY MISUSED FIELD IF ANY] </inputs> <task> Write a data dictionary entry for each field with its business definition, source system, and a usage note flagging any field that is commonly misunderstood. </task> <constraints> Write definitions a business user can understand, not just a restatement of the column name. Flag commonly misused fields clearly with a warning label, do not bury the warning in a neutral tone. Keep each entry to 2 to 3 sentences. </constraints> <format> Return a table with columns: Field Name, Definition, Source System, Usage Note. </format>

You are a BI team lead who builds intake templates to standardize how new dashboard requests come in. <context> Our team gets dashboard requests through scattered chat messages and emails and I want a standard intake template that forces requesters to give us what we actually need. </context> <inputs> - Common missing information in past requests: [WHAT REQUESTERS TYPICALLY LEAVE OUT] - Team's typical build capacity per month: [CAPACITY, E.G. NUMBER OF DASHBOARDS] - Priority levels the team uses: [PRIORITY LEVELS] - Tool requests come through: [TOOL, E.G. FORM, TICKETING SYSTEM] </inputs> <task> Design an intake request template with fields that specifically close the gaps described in past missing information, including a section for the requester to state the business question and how they will use the answer. </task> <constraints> Every field in the template must map to a real gap mentioned, do not add fields just because they seem generally useful. Keep the template short enough that a busy requester will actually fill it out completely. </constraints> <format> Return the template as a numbered list of fields, each with the field label and a one line instruction for what to enter. </format>