Tableau Interview Questions (2026): Most Commonly Asked, With Answers

A dimension is a qualitative field, things like Region, Category, or Customer Name, that Tableau uses to slice and group data. Dragging one onto a shelf adds headers or labels, not a calculation. A measure is a quantitative field, Sales or Profit, that Tableau aggregates by default (SUM is the default) whenever you drop it onto a shelf.

Tableau color-codes the two in the Data pane, dimensions in blue, measures in green, and that same blue/green split carries onto the shelves once a field lands in the view.

No, and this is the trap. Dimension versus measure is about role: does a field slice the data, or does Tableau aggregate it. Discrete versus continuous is about how a pill behaves in the view, a discrete (blue) field draws separate headers or distinct marks, a continuous (green) field draws an axis. Most dimensions default to discrete and most measures default to continuous, but both are switchable.

Right-click a numeric measure like Profit Ratio and choose Convert to Dimension, and Tableau treats every distinct value as its own category instead of summing it, useful when you want to bucket a number rather than aggregate it. Right-click a date field and pick the continuous, green version of Year instead of the default discrete one, and a row of year headers turns into a single continuous timeline axis.

A calculated field is a new field built from existing fields, constants, and functions, saved into the workbook so you can drag it onto shelves like any other field. You reach for one whenever the source data doesn't already contain what you need to plot: a profit ratio, a custom date bucket, a flag for whether an order shipped late.

Tableau calculations run in three families that behave differently: basic row-level or aggregate expressions, LOD expressions, and table calculations. Mixing those up is one of the most common ways a chart ends up looking plausible while being quietly wrong.

A normal aggregate calculation computes at whatever granularity is currently in the view. Drop Customer Name off the view and a SUM(Sales) recalculates for the new grouping automatically. LOD expressions let you fix the level of detail independent of the view, coarser, finer, or entirely unrelated to whatever's on Rows and Columns right now. That's the whole point: compute at one granularity, display at another.

A join combines two tables into one logical table at the data source level, row by row, based on a matching key, before any aggregation happens. A blend keeps the two data sources separate, aggregates each one independently at whatever granularity is in the view, then combines the two aggregated results using a shared linking dimension.

Joins operate on rows. Blends operate on already-aggregated numbers. That's why you can't build a calculated field mixing row-level fields from two blended sources the way you can with a join, the row-level detail from the secondary source isn't available anymore by the time blending happens.

Extract, data source, context, dimension, and measure filters, with table calculation filters running last, technically a sixth. Tableau documents the sequence as extract, then data source, then context, then dimension, then measure, then table calculation (Tableau Help, Order of Operations).

Extract and data source filters strip rows before the workbook ever sees them. Context filters build a temporary filtered table everything downstream works from. Dimension and measure filters apply against whatever the context filter left behind. Table calculation filters hide marks after the calculation already ran, without touching the underlying numbers.

A filter removes rows from the view. A parameter is a single, standalone input value, a number, a string, a date, a list of choices, that doesn't touch the underlying data on its own. A parameter only does something once you reference it inside a calculated field, a filter, or a reference line. It's a variable, not a data operation.

A group partitions every member of a dimension into a fixed number of new categories, Texas, Oklahoma, and Louisiana become "South Central," for instance, and every value ends up in some bucket. A set is binary: a member is either in the set or out of it, based on a manual list or a condition, and there's no requirement that the whole dimension gets categorized. Groups reorganize a dimension's members. Sets flag a subset of them.

Filter actions pass a selection from one sheet as a filter onto other sheets, click a bar, related views narrow down to just that value. Highlight actions do the visual version without filtering anything out, the selected marks get emphasized and everything else dims, but all the data stays on screen. URL actions open a link, optionally building the URL dynamically from field values in the selection, useful for jumping from a summary view out to an external record.

Parameter actions and set actions are newer additions, 2019.2 and 2018.3 respectively, that let a click update a parameter's value or add and remove marks from a set instead of filtering directly.

A live connection queries the underlying database directly every time someone interacts with the view, so it's always current but its speed is capped by the database's own performance. An extract pulls a compressed snapshot into Tableau's Hyper engine, the columnar in-memory format that replaced the older.tde format back in Tableau 10.5, which is usually faster for complex calculations and large aggregations because the engine is built specifically for the kind of querying a dashboard does. That snapshot stays frozen until someone refreshes it.

A.twb is an XML file that points to a live connection or extract, it doesn't bundle any actual data. A.twbx packages the workbook together with its extracts and any local files like background images into a single zipped package, so it's portable and someone can open it without access to the original database.

Use.twbx when sharing a self-contained workbook, Tableau Public submissions or an email to someone outside your network. Be careful though, since a.twbx with an embedded extract literally contains the data, so it's not something you want to send if the underlying rows are sensitive.

Each shelf applies a different visual encoding on top of whatever mark type you've picked, bar, line, circle, and so on. Color splits or shades marks by a dimension or measure. Size scales the mark's size by a field. Label prints text directly on the mark itself.

Detail is the one people forget. It adds a field that changes the granularity of the view, breaking marks apart into more detailed pieces, without adding any visible encoding at all. Drop a field on Detail and suddenly your totals look different, that's usually why. Tooltip controls what appears on hover and can include fields that aren't on Rows or Columns at all.

A dashboard is a fixed canvas that combines several worksheets, filters, and actions into one interactive view meant to be explored freely. A story is a sequence of dashboard or sheet snapshots, called story points, stitched together like a slideshow with captions, meant to walk a viewer through a narrative in a set order.

You build stories on top of dashboards and sheets you've already made, not as a replacement for them. If someone needs to explore data on their own, give them a dashboard. If you need to walk an executive through three specific findings in order, that's a story.

It reads the number and type of fields you've selected, how many dimensions, how many measures, discrete or continuous, roughly how many distinct values, and highlights which chart types in the panel are valid for that combination, greying out the rest.

It's not magic, it's pattern matching on field roles and counts, and it's frequently not what you actually want to build. Most people who work in Tableau daily ignore Show Me entirely and build the chart by hand from the Marks card, since it's faster once you know the tool.

A crosstab is rows and columns of numbers, no chart at all. It's the right call when the audience needs exact values to reference, like a finance close report that gets copied into another document, or when there are too many dimensions and measures to represent visually without producing a chart nobody can read.

If someone's going to open the export and read specific numbers off it rather than spot a trend, give them a table, not a bar chart with forty categories crammed onto one axis.

The date pill on Columns is set to a discrete part of the date, the default blue YEAR(Order Date), instead of a continuous date. Discrete date parts each get their own header, so Tableau treats every year as a separate category and breaks the line at each boundary instead of drawing one continuous series.

Right-click the pill and switch to the continuous, green version of the date. Same data, one unbroken trend line, because now there's one axis instead of a row of discrete headers.

[Profit Ratio] as a raw field is usually [Profit]/[Sales] computed row by row, one ratio per order. AVG([Profit Ratio]) then averages those individual ratios with equal weight, so a $10 order and a $10,000 order count the same. SUM([Profit])/SUM([Sales]) sums both sides first and divides once, which weights every dollar of sales equally instead of every order equally.

[Profit Ratio] (row-level field): [Profit] / [Sales]

AVG([Profit Ratio])      // average of the per-row ratios
SUM([Profit]) / SUM([Sales])  // ratio of the totals

Neither number is wrong. They answer different questions, and this gets asked specifically to see whether you notice the difference before shipping a dashboard with the wrong one.

{FIXED [Customer Name] : SUM([Sales])}
AVG({FIXED [Customer Name] : SUM([Sales])})

The inner expression computes total sales per customer, one number per customer, regardless of what else is in the view. Wrap that in AVG() and you get the average of those per-customer totals, which is genuinely different from AVG([Sales]) on the raw orders table, that second version averages per order, not per customer, and a customer with 40 small orders drags the number down compared to one with 2 large ones.

This exact pattern, an aggregation wrapped around a FIXED aggregation, is close to the single most common LOD question I've seen show up on Tableau interview questions lists, because it tests whether you can reason about two levels of granularity at once instead of reciting FIXED syntax.

INCLUDE computes at a finer level than the view by adding a dimension you haven't put on the view yet, useful when the calculation needs detail the view itself doesn't show, an average order size per customer even though the view is aggregated at the region level. EXCLUDE does the opposite: it removes a dimension that is in the view, so you can show a value as if that dimension weren't there, a running percent-of-total across all regions displayed inside a view broken out by region.

FIXED ignores the view's dimensions entirely, in both directions. INCLUDE and EXCLUDE only make sense relative to whatever's actually in the view, which is also why swapping a dimension in or out of the view can silently change what an INCLUDE or EXCLUDE calculation returns, and a FIXED calculation won't (Tableau Help, Level of Detail Expressions).

Fan-out. If Orders has one row per line item and Returns has multiple rows for the same order, one row per returned unit, say, joining on Order ID multiplies every Orders row by however many matching Returns rows exist. SUM(Sales) on the joined table then counts each order's sales once per return instead of once total.

It's not a bug, it's exactly what a row-level join does when the join keys aren't one-to-one, and it's one of the most common ways a Tableau workbook quietly overstates a number without throwing any error.

FIXED calculations are computed before dimension filters apply, which is exactly why a plain dimension filter can't touch a FIXED result unless you promote it to context first. INCLUDE and EXCLUDE sit after dimension filters, so they do respect whatever a dimension filter already removed, since by the time an INCLUDE or EXCLUDE calculation runs, the dimension filter has already trimmed the data it's working from.

That one placement difference is the real answer to "when would I use INCLUDE or EXCLUDE instead of FIXED", not some vague rule about granularity.

Because a context filter materializes a temporary table of just the rows that survive it, and every other filter, every LOD calculation that respects context, and every mark drawn afterward works off that smaller table instead of the full data source. On a data source with tens of millions of rows, filtering Region down to three values as a context filter before applying a dozen other dimension filters can noticeably cut query time, since those later filters scan a fraction of the original rows.

The catch: building that temporary table itself costs something up front, so a context filter on a small extract that only removes a handful of rows can make things slower, not faster. Test it, don't assume it.

Letting a user swap which measure drives an entire chart, Sales versus Profit versus Quantity, from one dropdown, using a single set of axes and colors instead of three separate charts. A calculated field like CASE [Measure Selector] WHEN "Sales" THEN SUM([Sales]) WHEN "Profit" THEN SUM([Profit]) END reads a parameter and returns a different aggregation depending on what the user picked, something a plain filter has no mechanism to do, since a filter only ever includes or excludes rows, it never swaps which field gets plotted.

Anytime membership needs to update automatically as the underlying data changes, Top 20 Customers by Sales, or Customers Over $10,000 Lifetime Value. A dynamic set defined by a condition re-evaluates every time the workbook refreshes, so the actual customers in it can shift month to month without anyone touching the definition.

A group's membership is fixed at creation, editing which members belong to which bucket is a manual step. There's no condition-based version of a group that recalculates itself the way a dynamic set does.

Filtering removes context. If someone clicks a single region on a map and a filter action fires, every other chart on the dashboard collapses down to just that region, and the viewer loses the ability to compare it against everything else. A highlight action keeps every mark visible and just emphasizes the selected one, which is usually what you want for a "show me how this region compares to the rest" dashboard, versus a filter action, which is right for a genuine drill-down where seeing only the selected subset is the actual point.

Sheet swapping stacks several sheets in the exact same floating position and uses a parameter plus a calculated field to control which one has data, and therefore renders, at any given time, a workaround that predates any native toggle feature. Show/hide buttons and dynamic zone visibility, added in 2022.3, do the same job natively: a button tied to a boolean value shows or hides a specific dashboard object directly, no parameter-swap trick required.

Sheet swapping still shows up in interview questions because plenty of production dashboards were built before the native version existed and nobody's rebuilt them since. Starting fresh in 2026, there's rarely a reason to reach for the old trick over the native toggle.

A field that reliably identifies new rows, an auto-incrementing ID or a timestamp that only moves forward, so Tableau can append just the rows added since the last refresh instead of re-pulling the entire source. Without a field like that, Tableau has no reliable way to tell which rows are actually new, so it falls back to a full refresh, re-pulling everything, every single time, which defeats the point of going incremental on a genuinely large table.

A table calculation, running total, percent of total, rank, moving average, operates on the aggregated result set already sitting in the view, not on the raw rows. That's the key difference from something like SUM([Sales]), which aggregates rows before the view ever renders.

Compute Using is the addressing setting, and it tells Tableau which dimension in the view defines the direction the calculation runs across. Everything else in the view becomes the partition it runs within. Get the addressing wrong, say addressing by Region when you meant Date, and a running total restarts or accumulates along the wrong axis, and the numbers still look plausible enough that nobody catches it for months.

Quick table calcs, applied by right-clicking a measure pill and picking Running Total or Percent of Total, cover single-step operations. You need a custom calc built with WINDOW_SUM, WINDOW_AVG, INDEX, RANK, or LOOKUP once you're combining steps, a running total of a percent-of-total, or a rank that only applies within a filtered subset while ignoring another dimension entirely.

The custom version also lets you set addressing and partitioning explicitly in the formula rather than relying on the small dialog box, and that matters once the view has more than two dimensions in play.

A dual-axis chart puts two measures on two separate but overlapping axes sharing the same set of dimension marks, usually built by dragging a second measure onto an existing axis to create a second Marks card, a line and bar combo is the classic example. Without synchronizing, each axis scales independently to its own measure's min and max, which is exactly what you want when the two measures are on completely different scales, Sales in dollars and Profit Ratio as a percent, for instance.

Synchronizing forces both axes to share the same scale, which you'd use when comparing two measures that are genuinely comparable, Sales this year versus Sales last year. Then a visual crossover point actually means something instead of being an artifact of two independently scaled axes lining up by accident.

A reference line is a single static or computed value drawn across the view, average or a fixed target, for example. A reference band shades the area between two computed values, average plus or minus one standard deviation is a common one, useful for showing a normal range at a glance.

A trend line is a fitted regression line, linear, logarithmic, exponential, or polynomial, computed from the actual marks in the view, and it recalculates as filters change. People lump these together because they all draw lines on a chart, but only the trend line is a statistical model, the other two are just static reference values sitting there.

The standard pattern is an entitlement table joining usernames or groups to the rows they're allowed to see, joined into the data source, then a calculated field like USERNAME() equals [Entitlement User], or using ISMEMBEROF for a group check, set as a user filter on every relevant sheet.

On a live connection to a large fact table, that filter becomes part of every query Tableau Server issues. If the entitlement join isn't indexed properly on the database side, every view load pays that join cost per user per query, and it compounds badly under concurrent load. On an extract, you either bake the filter into per-user extracts, which doesn't scale, or apply it at query time against a shared extract, faster than the live join but still dependent on the entitlement table being present and current inside that extract.

That's a pivoted, crosstab-shaped source, and Tableau wants long data, one row per year per record. On the data connection screen you can multi-select those year columns and use Pivot to collapse them into two new fields, a Pivot Field Names column that becomes your Year dimension after a rename, and a Pivot Field Values column that becomes your measure.

For anything beyond a one-off fix, or if the source refreshes regularly in the same bad shape, do the reshape in Tableau Prep instead so it's a repeatable step in a flow rather than a manual pivot redone by hand every time a new file lands.

Custom SQL gives you full control, window functions, CTEs, business logic your data team already wrote, and hands Tableau exactly the result set you want. The cost is that Tableau treats the whole block as one opaque query, so it can't push filters down into the inner query the way it can with native table connections, which means every interaction re-runs the full custom query instead of an optimized subset of it.

It also carries an initial-query cost on every session before any extract refresh logic even kicks in. If you only reached for Custom SQL to do a join, switch to native tables with a relationship or join instead, Tableau optimizes that far better than a black-box query it can't see inside.

A plain aggregate like SUM or AVG just ignores NULLs in the underlying rows, so AVG of 10, NULL, 20 is 15, not 10. Table calculations run on the already-aggregated grid, so if an entire cell in that grid is genuinely missing, no data at all for that dimension combination, rather than explicitly NULL, you can end up with an empty cell that a running total either skips or, depending on domain completion, fills in as a zero-value phantom point.

LOD expressions inherit NULL behavior from whatever aggregate sits inside them, but the real gotcha is that a FIXED LOD computed at a finer grain than the view can return NULL at the view level if that fixed combination has no matching rows once other filters are applied, which looks like a bug the first time you see it but is working exactly as designed.

Tableau's forecast model is exponential smoothing, it automatically tests several Holt-Winters variants for trend and seasonality and picks whichever fits best, it's not ARIMA and not a machine learning model, so don't describe it to a stakeholder as anything fancier than that.

It needs a continuous date field on the axis with enough history to detect a pattern, ideally a couple of full seasonal cycles if you want it to actually pick up seasonality rather than just extrapolate a flat or linear trend. Gaps in the date range get filled in through domain completion before the model ever runs, so a spotty history produces a forecast built partly on interpolated zeros, a common way to end up with a forecast that looks confident but is quietly wrong.

Permission templates set defaults for everything published into a project, Viewer, Explorer, Creator capabilities like download, save, and filter, and they're meant to be the set-it-once layer for governance. An individual workbook or view can carry its own rule that overrides the project default, for example a normally view-only project holding one workbook a specific group is allowed to edit.

The common confusion is someone changing permissions at the project level and expecting it to cascade down to workbooks that already have their own explicit overrides. It doesn't. Existing per-workbook rules stick until someone edits them directly, or until you use Lock at the project level to force everything underneath to inherit and stop drifting.

These control what happens on the target sheet when the selection on the source sheet is cleared, not what happens on click. Show all values resets the target back to unfiltered once nothing's selected, a good default for exploratory drill-downs.

Keep filtered fields leaves the target showing whatever the last selection filtered to, so clicking away doesn't reset the view, useful when you want the last click to stick as a semi-persistent filter. Exclude all values flips the logic entirely, clicking a mark filters it out of the target rather than filtering down to it, which is the pattern behind click-to-remove interactions like pulling an outlier off a scatter plot.

Certification is organizational signaling, not a technical restriction. A certified badge shows up in data source search results so someone building a new workbook knows it's the vetted, IT-owned source rather than an ad hoc extract someone built three years ago and forgot about.

It usually comes with an owner listed and a certification note flagging known caveats or where to get help. It doesn't change query performance, security, or refresh behavior at all, it's purely a governance and discoverability layer sitting on top of the data catalog.

Assign a custom geographic role by right-clicking the field and going to Geographic Role, and if there's no exact standard match, either build a custom territory by grouping an existing geographic role, a set of ZIP codes or states rolled up into a new field that represents your internal region, or generate custom geocoding for codes with no overlap to any built-in geography at all.

Custom geocoding works by exporting Tableau's built-in geocoding data as a template, adding latitude, longitude, and your codes to it, then importing it back as a custom geocoding set and assigning that role to your field, so the map plots correctly instead of dumping everything into an unknown bucket.

IF [Sales] >= 5000 THEN "High"
ELSEIF [Sales] >= 1000 THEN "Medium"
ELSE "Low"
END

IF/ELSEIF handles ranges and conditions, which is what tiering needs. CASE is the better fit when you're matching a field against a short list of exact discrete values, a region code to a region name, say, because it reads faster and Tableau optimizes it slightly better than a long ELSEIF chain. Neither one aggregates on its own, so this bucket runs at the row level, and you'd typically drag it onto Color or Rows as a discrete dimension, not sum it.

FIXED expressions ignore every filter in the view except extract filters, data source filters, and context filters, by design. That's what makes them independent of the view. Drop a plain dimension filter on Region and a {FIXED [Customer Name]: SUM([Sales])} calculation keeps summing sales across every region for that customer, filter or no filter, because a dimension filter isn't one of the three FIXED respects.

The fix is to promote that filter to a context filter (right-click it, Add to Context), which runs before the FIXED calculation in Tableau's order of operations instead of after it. It's a small setting with a real trade-off: context filters also force Tableau to build a temporary table before every other calculation runs, which costs performance on a large data source, so you're trading a correctness bug for a slower workbook. I don't think that trade is free, and I'd rather see someone reach for INCLUDE or EXCLUDE when the view's filters are supposed to affect the LOD calculation, and save context filters for when they genuinely aren't.

Relationships, introduced in Tableau 2020.2, don't pre-join tables into one fixed logical table the way a join does. Instead Tableau keeps the tables logically separate and generates the actual join, at the right level of detail, dynamically, based on whatever fields are in the current view (Tableau Help, Relate Your Data). That sidesteps the fan-out problem from the Returns example above in a lot of common cases, because Tableau aggregates each table to the matching granularity before combining them instead of joining raw rows and letting duplicates multiply through.

I can't put a precise number on how many production workbooks have actually migrated off old-style joins onto relationships. My guess is plenty haven't, because a join-based data source that already works correctly isn't worth touching just to modernize it, and multi-fact relationships, sharing dimensions across more than one fact table in a single data source, only arrived in Tableau 2024.2, recent enough that a lot of teams haven't rebuilt around it yet.

Order of operations again. A dimension-based Top N filter runs in the same stage as other dimension filters, and Tableau doesn't guarantee one runs before the other unless you force it. If Top 10 evaluates against the full unfiltered product list before the region filter narrows things down, you get the top 10 products company-wide, not the top 10 within that region.

The fix is the same move as the FIXED problem: promote the region filter to a context filter, which forces it to run before the Top N dimension filter instead of alongside it, so Top 10 gets computed only against rows that already passed the region filter.

Whether it's on an extract at all. Quick filters are the most commonly blamed culprit, and they do matter, each one that isn't set to "Only Relevant Values" can trigger its own query against the full table, but I'd check the connection type before touching a single filter, because moving a genuinely large live source onto an extract is usually the biggest single lever available, bigger than trimming filters one at a time.

After that: custom SQL as the data source (it blocks Tableau's own query optimizer and predicate pushdown, since the database has to run the whole custom query as one opaque block), too many marks in a single view, and calculated fields nested three or four LOD expressions deep, roughly in that order of how often I'd expect each one to be the actual bottleneck.

That's domain completion, often called densification. When you put a continuous date on Columns and a dimension on Color or Detail, Tableau doesn't just plot the combinations that exist in your data, it computes the full cross product of every date in range against every value of that dimension and fills in missing combinations with a mark, at zero or null depending on the aggregate.

It's most visible with a line mark type since lines try to connect every point along the axis, so weekends with no rows show up as real-looking dips in the trend. Switching the mark type to a shape or circle instead of a line usually confirms it, since discrete marks don't visually connect the phantom points the same way.

The actual fix depends on intent. If the zero is meaningful, no sales that day, leave it alone. If it's an artifact of a dimension filter not actually applying to every date, you usually need to move that filter to a context filter or restructure the LOD calc so the padding doesn't run against the full unfiltered domain.

Yes, you can nest LOD expressions, but they don't share filter context automatically, and that's where people get burned. A FIXED expression ignores all dimension filters in the view by default, it only respects context filters and data source filters, so if you nest a FIXED calculation inside an EXCLUDE that's supposed to react to a view-level filter, the inner FIXED result was already computed on the full unfiltered domain before the outer calc ever sees it, and any filter added afterward silently does nothing to that inner value.

A real debugging scenario: someone builds a FIXED calc on Customer to get a per-customer sales total, then wraps an EXCLUDE around a date dimension expecting the customer total to move when a Year filter gets applied, but the FIXED value never changes because Year isn't part of that FIXED expression's own dimensionality and isn't a context filter.

The fix is either adding the filtering dimension into the FIXED expression itself, converting the offending filter to a context filter so it applies before the FIXED evaluates, or collapsing the whole thing into a single EXCLUDE built at the right grain instead of stacking two LOD calcs that disagree on filter scope.

Hyper is a real columnar analytic database engine underneath, it came out of Tableau's 2016 acquisition of the HyperDB team, not just a file format tweak. It supports proper SQL-style joins, larger row counts, and parallelized query execution at extract time, versus the older TDE format, which was closer to a flat columnar cache with much more limited join handling.

The practical refresh gotcha shows up with calculated fields that can't be pushed down and evaluated lazily at query time, non-additive LOD expressions especially. Hyper sometimes has to materialize those calculations at extract-build time instead of leaving them to be computed on read, which turns a routine refresh into a much heavier row-by-row computation pass. That's why dropping one FIXED LOD into a workbook backed by a huge extract can noticeably slow refresh time even though the formula itself looks trivial, the cost isn't in the formula, it's in when and how often it has to be recomputed against the whole extract.

Blending works by running the primary source's query, collecting the distinct values of the linking field from that result, then querying the secondary source filtered to just those values and aggregating before combining. When the linking field has high cardinality, thousands of distinct customer IDs for example, that secondary query can carry an enormous filter list, and because blending only aggregates the secondary source at whatever grain the linking fields define, you lose access to any row-level detail from the secondary source that isn't part of that link.

Relationships solve the join-level problem, no more fan-out or duplication from a naive join, correct aggregation across different grains, when both sources are genuinely queryable together at query time. You still reach for a blend instead when the two sources live in connections that can't be federated into one query at all, a Salesforce connector paired with a local Excel file, since relationships still need Tableau to be able to issue one combined query across the sources involved.

Say you have Category and Sub-Category in the view and want percent of total Sales for each Sub-Category within its own Category, so percentages sum to 100% per Category, not globally. That calc needs to address across Sub-Category while being partitioned by Category, so each Category's percentages sum independently of the others.

Now wrap a Rank around that first calc, and it needs to address across both Category and Sub-Category together, ignoring the partition the inner calc used, otherwise the rank resets to 1 within each Category instead of giving a true global rank.

The mistake people make is assuming Compute Using is one global setting for the whole nested formula, when each table calc layer actually carries its own independent addressing. If you don't explicitly set the outer Rank's addressing to include Category, it silently inherits a partition boundary from the inner calc's context and produces ranks that reset per Category, which usually doesn't get noticed until someone asks why the same item is ranked first in three different categories at once.

The typical break happens when the extract is refreshed by a scheduled task or Bridge agent running as a service account, and somewhere the entitlement join was built assuming USERNAME() reflects whoever's actually viewing the dashboard. That's true at query time for a live connection or an extract queried through Server, but it breaks the moment someone downloads the extract locally or the workbook gets embedded somewhere the identity context isn't a real Server session, since USERNAME() then just returns the local machine account or an empty value, and the RLS filter either shows nothing or, worse, shows everything if the fallback logic isn't strict.

The fix is to never rely on USERNAME() as the sole gate. Join an entitlements table into the data source at the extract's grain, one row per user-permission combination, so the filter is a real join condition evaluated against actual Server session identity every time the view renders. Keep the extract refresh schedule and the entitlements table's own refresh in sync too, a stale entitlements table, someone changed roles but the extract hasn't refreshed since, is a silent security bug, not just a stale-data annoyance.

First check whether it's actually still using the extract on Server, a common mistake is publishing with an embedded live connection instead of an extract, or the extract refresh schedule failing silently so Server is quietly falling back to hitting the live source on every load.

Next, pull up the Performance Recording dashboard, available from the workbook menu when opened on Server, and it breaks load time into query time, rendering time, and layout computation, which tells you immediately whether the bottleneck is the database, Tableau's own query generation, or just the number of marks being rendered client side.

If it's query time, grab the actual generated SQL from the logs and check whether it's the extract's own aggregation getting hit with heavy context filters, or whether a data source filter combined with row-level security is producing an expensive per-user query that Desktop never had to run since you were testing as yourself with different, or no, RLS applied. Also check whether Server itself is the bottleneck, concurrent background extract refreshes competing for the same VizQL Server process resources, in which case the fix isn't the workbook at all, it's the refresh schedule stepping on live user traffic.