BigData / Tableau Interview Questions

A Tableau workbook is the main file you create and save your work in when using Tableau Desktop. It's the container that holds everything related to one analysis project.

• One or more worksheets, each showing a single view or chart.
• Dashboards, which combine multiple worksheets into one interactive screen.
• Stories, which sequence dashboards and worksheets into a guided narrative.
• Data connections, calculated fields, parameters, and formatting all saved together in the same file.

A workbook is saved with either a .twb extension (a lightweight XML file that just references the data source) or a .twbx extension (a packaged workbook that bundles the data extract and any local files together, making it easy to share).

Because everything lives in one file, opening a workbook gives you the full picture of an analysis: the raw connections, every worksheet built on top of them, and the dashboards and stories assembled from those worksheets.

Tableau is a visual analytics platform transforming the way we use data to solve problems-empowering people and organizations to make the most of their data.

Tableau allows users to connect to various data sources, create interactive dashboards, and generate insightful reports. Tableau is the Business Intelligence (BI) industry's most potent and fastest tool for visualizing data. It turns the raw data into a format that is easy to understand. Data visualization or diagrams make it easy for employees at all levels of an organization to understand the information.

A worksheet is the basic building block of analysis in Tableau — it's the single-view canvas where you actually build one chart or table by dragging fields onto shelves.

• Fields from your data source appear as pills in the left-hand pane, split into Dimensions and Measures.
• Dragging pills onto the Rows, Columns, and Marks shelves determines what's plotted and how.
• Formatting, filters, tooltips, and the choice of mark type (bar, line, map, etc.) are all configured at the worksheet level.

Every worksheet in a workbook can be reused: you build it once, then drop it into as many dashboards or stories as you like, and any change you make to the worksheet automatically reflects everywhere it's used.

Worksheets are intentionally single-purpose — if you need multiple charts side by side, you combine several worksheets on a dashboard rather than cramming multiple views into one worksheet.

Data visualization is a way to represent data that is visually appealing and interactive. With advancements in technology, the number of business intelligence tools has increased which helps users understand data, data sets, data points, charts, graphs, and focus on its impact rather than understanding the tool itself.

Tableau offers a myriad of data sources such as local text files, MS Excel, PDFs, JSON or databases and servers like Tableau Server, MySQL Server, Microsoft SQL Server, etc. Categorically, there are two types of data sources that you can connect to in Tableau; To a file and To a server.

A dashboard combines multiple worksheets, along with text, images, web pages, and interactive controls, into a single unified view — the format most end users actually interact with.

• Worksheets are dragged onto the dashboard canvas as containers and arranged using tiled or floating layouts.
• Filters, highlight actions, and parameter controls can be added so a single dashboard supports cross-filtering between its component worksheets.
• Dashboards can be set to a fixed size, a range of sizes, or a fully automatic responsive layout for different screens.

Dashboard = Worksheet A + Worksheet B + Filter Action + Legend + Text Box

The real power of a dashboard comes from dashboard actions — clicking a bar in one worksheet can filter, highlight, or navigate other worksheets on the same dashboard, turning a set of static charts into an interconnected exploration tool without writing any code.

Tableau supports the following 7 data-types:

• String values,
• Number/Integer values,
• Date values,
• Date & Time values,
• Boolean values,
• Geographic values,
• and Cluster or mixed values.

A story is a sequence of worksheets or dashboards, called story points, arranged in order to walk a viewer through an analysis narrative — step by step, like a slideshow built from live, interactive Tableau content.

• Each story point can be a different worksheet, a different dashboard, or the same dashboard with a different filter or annotation applied.
• Navigation controls let the viewer move forward and backward through the points, or jump directly to one via the story point bar.
• Captions on each point explain what changed and why it matters, giving context that a single static dashboard can't provide.

Stories are commonly used for presenting findings to stakeholders: instead of a single dense dashboard, an analyst builds one point showing overall trends, a second point zooming into an anomaly, and a third point showing the recommended action — each still fully interactive if the viewer wants to dig in further.

Tableau is a suite of related products rather than a single application, each aimed at a different part of the analytics workflow.

A typical enterprise workflow uses Desktop or Prep to build and clean content, then publishes it to Server or Cloud where the rest of the organization can view and interact with it through a browser, without needing a Desktop license themselves.

Measures are the numeric metrics or measurable quantities of the data, which can be analyzed by dimension table. Measures are stored in a table that contain foreign keys referring uniquely to the associated dimension tables. The table supports data storage at atomic level and thus, allows more number of records to be inserted at one time. For instance, a Sales table can have product key, customer key, promotion key, items sold, referring to a specific event.

Dimensions are the descriptive attribute values for multiple dimensions of each attribute, defining multiple characteristics. A dimension table ,having reference of a product key form the table, can consist of product name, product type, size, color, description, etc.

Tableau Public is a free version of Tableau intended for publishing visualizations that anyone on the internet can view, rather than for private or internal business data.

• Workbooks are saved directly to Tableau's public cloud gallery, not to a private server.
• Every workbook published to Tableau Public is visible to anyone, and the underlying data can typically be downloaded by viewers — there is no way to keep it private.
• It's widely used by journalists, students, and hobbyist data analysts to showcase portfolio work, since it requires no licensing cost.

Because everything published is public, it should never be used for confidential, proprietary, or personally identifiable data. Organizations that need to share dashboards privately use Tableau Server or Tableau Cloud instead, which support authentication, permissions, and private hosting that Tableau Public simply does not offer.

Visualize Data: Rather than having complex computations over an Excel sheet, Tableau provides beautiful insights, data blending, and dashboarding derived from the data.

Create interactive visualizations: Tableau provides a drag-n-drop facility to quickly let the users interact with the data. You can check some of the templates created using Tableau in the Tableau gallery.

With Tableau's gallery of templates, you can choose your option and customize it. With data visualization features, you can easily embed tons of information in the form of infographics that appeal to the audience.

Easy implementation: With drag-and-drop options, Tableau is reportedly easier to use. This is one such tool that you can learn without having any coding background or experience in Python, Business objects, or DOMO.

Handle large amounts of data: Tableau is competent enough to handle millions of rows without affecting the dashboard performance.

Integration with scripting languages: With Tableau, you can perform complex data computations using scripting languages like Python and R by importing some visuals or packages.

The parameters in Tableau are the workbook variables like a number, date, or calculated field that allows users to replace a constant value in a calculation, filter, or reference line.

For example, you create a field that returns true if the sales are greater than 30,000 and false if otherwise. Parameters are used to replace these numbers (30000 in this case) to dynamically set this during calculations. Parameters allow you to dynamically modify values in a calculation. The parameters can accept values in the following options:

• All: Simple text field.
• List: List of possible values to select from.
• Range: Select values from a specified range.

Tableau Server is the self-hosted platform organizations install on their own infrastructure to publish, share, and govern Tableau workbooks at scale, without giving every viewer a full Desktop license.

• Authors publish workbooks from Tableau Desktop directly to Server, where they live inside projects and sites for organization.
• Server handles authentication (often via Active Directory/SSO), permissions down to the individual workbook or row level, and scheduled extract refreshes.
• Viewers interact with published content through a web browser or the Tableau Mobile app — no Desktop installation required.

Because Server is self-managed, IT teams control the infrastructure, scaling, backups, and security configuration themselves, which is the main trade-off compared to Tableau Cloud, where Tableau operates the hosting on the organization's behalf.

Server is the backbone of most enterprise Tableau deployments: content is built once in Desktop, then centrally governed and distributed through Server rather than emailed around as individual files.

Tableau Prep is a visual, drag-and-drop tool for cleaning, reshaping, and combining data before it ever reaches a Tableau Desktop workbook, aimed at the "data wrangling" step of analytics.

• You build a flow: a visual pipeline of steps like cleaning, filtering, splitting fields, pivoting, aggregating, and joining or unioning multiple data sources.
• Each step shows a live preview of the data as it's transformed, so you can catch mistakes immediately instead of at the end of a long script.
• Finished flows can output a cleaned data extract, or be scheduled to run automatically (via Tableau Prep Conductor on Server/Cloud) to keep downstream dashboards fresh.

Raw CSV -> Clean step (trim/rename fields) -> Join with lookup table
        -> Pivot -> Output as .hyper extract

Prep complements Desktop rather than replacing it: Prep handles the "get the data into good shape" work, while Desktop handles the "explore and visualize" work, and the two are commonly used together in the same project.

Filters restrict the data shown in a view, letting you narrow a worksheet down to only the rows relevant to the question you're asking, without changing the underlying data source.

• Filters can be applied to dimensions (e.g. only show Region = "West"), measures (e.g. only show Sales > 1000), or dates (e.g. only show the last 12 months).
• A filter can live on a single worksheet, or be added to a dashboard as a quick filter so viewers can change it interactively.
• Filters can also be added to the whole data source, applying everywhere that data source is used across a workbook.

Drag [Region] to the Filters shelf -> select "West", "East"
-> only rows matching those regions appear in the view

Filters are foundational to almost every Tableau worksheet: they're what lets one dataset serve many different analytical questions, simply by changing what's included before the visualization is drawn.

Tableau applies several distinct kinds of filters, and understanding the order they run in matters as much as knowing what each one does.

This isn't just a categorization exercise — the order these run in changes results. For example, a Top-10 filter based on a table calculation only produces correct results if it runs after dimension filters have already narrowed the data, which is exactly why table calculation filters are applied last in Tableau's fixed filter order.

A calculated field is a new field you define using a formula built from existing fields, constants, and Tableau's built-in functions — it lets you derive values the raw data source doesn't already contain.

// Profit Ratio
SUM([Profit]) / SUM([Sales])

// Custom category
IF [Sales] > 1000 THEN "High" ELSE "Low" END

• Calculated fields can be simple arithmetic (like Profit Ratio above), logical (IF/CASE statements), string manipulations, or date math.
• Once created, a calculated field behaves exactly like any other field — it can be dragged onto shelves, used in filters, or referenced by other calculated fields.
• Calculations can be row-level (evaluated per record) or aggregate-level (evaluated after data is aggregated, like the Profit Ratio example, which needs SUM() to make sense at the visualization's level of detail).

Calculated fields are one of the most powerful features in Tableau because they let you reshape and derive new metrics without ever touching or duplicating the source data itself.

An extract is a compressed, optimized snapshot of your data that Tableau stores using its own Hyper engine format (.hyper files), instead of querying the original database live every time.

• Extracts can pull the full dataset or a filtered subset, and can even be aggregated to a higher grain to shrink file size.
• Because it's a local, columnar, purpose-built format, an extract is usually much faster to query than hitting the live source directly, especially over a slow database connection or large tables.
• Extracts need to be refreshed (manually or on a schedule via Tableau Server/Cloud) to stay up to date with the source system.

Data menu -> Extract -> Create Extract...
-> choose rows/filters -> save as .hyper

Extracts are a common performance lever: workbooks that feel sluggish against a live connection often speed up dramatically once switched to an extract, at the cost of the data being only as fresh as the last refresh.

This choice determines whether Tableau talks directly to your source database on every interaction, or works off a locally stored snapshot.

Live connections are the right call for operational dashboards that must reflect real-time data (like a live ops monitoring board), while extracts are usually preferred for reporting dashboards where slight staleness is acceptable in exchange for much better interactivity and query speed, especially against large or slow source systems.

These three shelves are where the actual structure of a Tableau view is defined — everything else is refinement on top of what you place here.

• Rows shelf: fields placed here define what appears down the vertical axis (or as separate rows in a table).
• Columns shelf: fields placed here define what appears across the horizontal axis (or as separate columns).
• Marks card: controls how each data point is drawn — its mark type (bar, line, circle, map, etc.), color, size, label, detail, and tooltip content.

Columns: [Order Date] (continuous, by month)
Rows:    SUM([Sales])
Marks:   Color = [Region], Mark type = Line

The combination of what's on Rows/Columns (which sets up the axes/grid) and what's configured on the Marks card (which sets up the visual encoding) is really the entire "language" of building a Tableau chart — almost every visualization type is just a different arrangement of these three areas.

The Marks card is the control panel that determines how the data points in a view are visually rendered, sitting right next to the Rows and Columns shelves.

• Mark type dropdown chooses the base shape: Automatic, Bar, Line, Area, Circle, Shape, Square, Text, Map, Pie, Gantt Bar, Density, or Polygon.
• Color: drag a field here to encode categories or values as different colors.
• Size: drag a measure here to encode magnitude as mark size.
• Label: controls text shown directly on the marks.
• Detail: adds a field to the level of detail of the view without adding it to color, size, or label — useful for keeping marks separate (e.g. one line per customer) without any visible encoding change.
• Tooltip: customizes what appears when hovering over a mark.

Because most of these properties accept any field you drag onto them, the Marks card is what turns a plain bar chart into a rich, multi-dimensional visualization — encoding several variables (position, color, size, label) into a single view at once.

A dual-axis chart overlays two measures on the same view, each with its own independent Y-axis, so you can compare two metrics with different scales side by side in one chart rather than two separate ones.

Columns: [Order Date] (by month)
Rows:    SUM([Sales])
         SUM([Profit])   -- drag onto the same Rows shelf area
-> right-click the second measure's axis -> "Dual Axis"

1. Place the first measure on the Rows shelf as usual.
2. Drag the second measure onto the Rows shelf, next to (not replacing) the first — this initially creates two separate stacked panes.
3. Right-click the axis for the second measure and choose Dual Axis to merge them into one shared plot area with two Y-axes.
4. Optionally right-click one axis and choose Synchronize Axis if you want both measures to share the same scale instead of independent ones.

A classic use case is plotting Sales as bars and Profit Ratio as a line on the same timeline — each keeps its own natural scale, but both appear together so trends and relationships between the two metrics are easy to spot.

Data blending combines data from two separate data sources into one view, at the level of the visualization itself, rather than at the query level like a join does.

• One data source is designated the primary, the other the secondary; the primary's row-level data effectively drives the view.
• Tableau connects them using one or more common fields (a linking field), aggregating the secondary source's data up to match the primary's level of detail.
• Because blending aggregates the secondary source first, secondary-source measures show up already summarized — you can't drill into their row-level detail the way you can with the primary source.

Primary:   Sales (by Region, Month)
Secondary: Marketing Spend (by Region, Month)
-> linking field: Region + Month
-> Marketing Spend appears aggregated to that grain in the view

Blending is the go-to option when two data sources can't be joined directly — for example, they live in entirely different databases, or one is a live connection and the other an extract — but it comes with the aggregation trade-off that a proper join or unioned extract avoids.

Both let you combine two data sources, but they operate at different stages and with very different implications for how detailed your results can be.

The rule of thumb: use a join whenever both sources can support it and you need full row-level flexibility; reach for blending only when a join isn't possible, keeping in mind its aggregation trade-off.

When connecting multiple tables from the same data source, Tableau lets you join them using standard relational join types, configured visually in the data source pane.

Orders (left table) LEFT JOIN Customers (right table)
  ON Orders.customer_id = Customers.customer_id
-- keeps every order, even ones missing a matching customer record

Tableau shows a visual Venn-diagram-style icon for each join type in the data source pane, making it easy to pick the right one without writing SQL by hand. Choosing the wrong join type is a common source of row duplication or missing data — for example, an inner join silently drops orders that don't have a matching customer, which can understate totals if not caught.

A context filter is a filter you promote to run before all other (non-context) filters on the same worksheet, creating a temporary, filtered "context" that every other filter and calculation then operates within.

• Performance: if a worksheet has a filter that dramatically shrinks the data (e.g. Region = "West"), making it a context filter means Tableau only has to evaluate subsequent filters against that smaller subset, instead of the full dataset each time.
• Correctness for dependent filters: a "Top 10 Customers by Sales" filter needs to know the correct universe of customers to rank — if you also want that ranking limited to one region, the region filter must run first, which requires making it a context filter.

Right-click the [Region] filter pill -> "Add to Context"

Context filters aren't free, though: changing a context filter forces Tableau to rebuild the temporary table behind the scenes, which has its own cost, so they're best used for filters that are large, static, and shared across many dependent calculations, not ones that change frequently.

Tableau applies different filter categories in a fixed order, regardless of the order you added them in the interface. Understanding this order explains many "why doesn't my filter work the way I expected" situations.

1. Extract filters (if using an extract) — limit what's even pulled into the extract.
2. Data source filters — applied to every worksheet using that source.
3. Context filters — run next, and define the "context" for everything after.
4. Dimension filters (non-context) — standard filters on discrete fields.
5. Measure filters and Sets used as filters.
6. Table calculation filters — run last, since they depend on the result set already being assembled.

This ordering is why a Top-N table calculation filter that seems to "ignore" a dimension filter is usually actually working correctly — it's just evaluating the ranking after all earlier filters already ran, which is normally the desired behavior, but can surprise someone who expected filters to apply in whatever order they were dragged onto the shelf.

A set is a custom, reusable field that defines a subset of data based on a condition or a manually chosen list of members — effectively a saved "in/out" grouping you can drop onto a view.

• Fixed sets are built from a manually selected list of specific members (e.g. these 5 named customers).
• Computed (dynamic) sets are built from a condition or a Top-N rule (e.g. "Top 10 Customers by Sales"), and automatically update as the underlying data changes.
• Sets can be dragged onto Color to highlight members vs non-members, used in a filter, or combined with other sets (union/intersection) to build more complex logic.

Right-click [Customer Name] -> Create -> Set
-> Top tab -> Top 10 by SUM(Sales)
-> produces a dynamic "Top 10 Customers" set

Because computed sets are rule-based rather than a fixed list, they're especially useful for things like "always show me this quarter's top performers," where the actual members should shift automatically as new data comes in.

A group combines several individual dimension members into a single, higher-level category, primarily to simplify a view or roll up related values without altering the source data.

Group "California", "Oregon", "Washington" -> "West Coast"
Group "New York", "New Jersey", "Connecticut" -> "Tri-State"

• Groups are typically created by manually selecting members in a view (right-click -> Group) or from the field's context menu in the data pane.
• A grouped field becomes a new field of its own (e.g. "State (group)"), leaving the original ungrouped field intact and usable elsewhere.
• Groups are static by nature — unlike a computed set, a group's membership doesn't automatically change unless you manually edit it.

Groups are commonly used to clean up messy categorical data (combining "USA", "U.S.A.", and "United States" into one group) or to create business-meaningful rollups (combining individual states into regions) directly inside Tableau, without needing to alter the underlying data source.

Both let you organize dimension members, but they answer different questions: a group asks "how should these members be relabeled/combined?" while a set asks "which members are in or out?"

A quick way to remember it: use a group when you want to relabel and combine ("these three states are now one region"), and use a set when you want a yes/no flag on membership ("is this customer in my top 10 or not").

A hierarchy arranges related dimensions in a parent-child order so viewers can drill down from a broad category to finer detail directly within a single view, using the small expand/collapse (+/-) icons Tableau adds automatically.

Location Hierarchy:
  Country
    -> State
        -> City

• Tableau automatically creates a default Date hierarchy (Year → Quarter → Month → Day) whenever a date field is used.
• Custom hierarchies (like Country → State → City) are built by dragging one dimension onto another in the data pane, which prompts Tableau to create the hierarchy grouping.
• Once a hierarchy exists, clicking the "+" icon next to the top-level field on a shelf drills into the next level, without needing to manually swap fields in and out.

Hierarchies are purely a navigation convenience layer over existing fields — they don't create new data or calculations, they just organize how a viewer can drill up and down through related dimensions already present in the source.

A table calculation is a calculation applied to the values already in a Tableau view, after the underlying query has returned and aggregated the data — as opposed to a regular calculated field, which is computed as part of the query itself.

• Common examples include running total, percent of total, rank, moving average, and difference from previous value.
• Table calculations depend on the structure of the view — specifically the partitioning (which fields reset the calculation) and addressing (which fields the calculation runs across), both configurable via "Compute Using."

Quick Table Calculation -> Running Total
-> Compute Using: Table (down)
-> produces a cumulative sum as you move down rows

Because they operate on the already-aggregated view rather than the raw rows, table calculations are the tool of choice for anything inherently relative to other rows in the result — a rank, a running total, or a percent-of-total simply can't be computed correctly by looking at one row in isolation, which is exactly the situation a normal row-level calculated field is built for.

Both create derived values, but they operate at fundamentally different points in Tableau's query pipeline, which changes what each one can and can't do.

A simple diagnostic: if a calculation's correct result depends on knowing what other rows are currently visible in the view (like "what rank is this among the rows shown"), it needs to be a table calculation; if it only depends on that row's own values, a regular calculated field is the right tool.

An LOD expression lets you compute an aggregation at a level of detail that's different from the granularity of the view itself — something neither a normal calculated field nor a table calculation can do on their own.

{ FIXED [Customer ID] : SUM([Sales]) }
{ INCLUDE [Order ID] : SUM([Profit]) }
{ EXCLUDE [Sub-Category] : AVG([Discount]) }

• FIXED: computes the aggregation at exactly the dimensions listed, ignoring whatever's in the view.
• INCLUDE: computes at a finer level than the view by adding extra dimensions, useful inside calculations that need row-level detail temporarily.
• EXCLUDE: computes at a coarser level than the view by removing dimensions the view would otherwise use.

A classic example is "total sales per customer, shown alongside order-level rows" — a normal SUM([Sales]) would just repeat the order's own value, but { FIXED [Customer ID] : SUM([Sales]) } computes the true customer-level total and repeats that same total across every one of that customer's orders, regardless of how granular the view is.

Both add dimensions to control the level of detail, but they respond differently to whatever else you place on the view afterward.

{ FIXED [Region] : SUM([Sales]) }    -- always Region-level, no matter the view
{ INCLUDE [Order ID] : SUM([Sales]) } -- view's dimensions + Order ID

A useful mental model: FIXED defines an absolute level of detail independent of the view, while INCLUDE defines a relative level of detail that's always at least as fine as whatever the view currently shows.

An action defines a piece of interactivity: clicking or hovering over a mark in one worksheet triggers a change somewhere else — another worksheet, a dashboard, or even an external URL — turning static charts into an interconnected experience.

Dashboard menu -> Actions -> Add Action -> Filter
Source sheet: Sales by Region
Target sheet: Sales by Product
Run action on: Select

Actions are configured at the dashboard level (or via worksheet-level "Actions" for some types) and can be triggered by Select, Hover, or Menu click, giving fine control over exactly how much interactivity a viewer gets before something on the dashboard responds.

Every field in Tableau is treated as either discrete (blue pill) or continuous (green pill), and this distinction drives how the field behaves on shelves, not just how it's colored.

SUM([Sales])         -- green pill, continuous, creates an axis
[Region]              -- blue pill, discrete, creates headers
YEAR([Order Date])    -- can be either, changes chart shape dramatically

Both dimensions and measures can technically be switched between discrete and continuous (right-click the pill -> Discrete/Continuous), which is a common cause of confusion for beginners — a date field set to continuous produces a smooth timeline, while the same field set to discrete produces separate labeled buckets, and the resulting chart looks completely different even though the underlying field is the same.

Aggregate functions collapse many row-level values into a single summarized value, and are the default behavior applied to every measure dropped onto a shelf.

SUM([Sales])
COUNTD([Customer ID])   -- unique customer count, not total rows
AVG([Discount])

By default, every measure dragged into a view is wrapped in an aggregate function (usually SUM), which is why measure pills often show as SUM(Sales) rather than just Sales. Changing which aggregate is applied is as simple as right-clicking the pill and choosing "Measure (Sum)" -> a different function from the list.

Both are Tableau workbook file formats, but they differ in whether the data itself travels along with the visual content.

File -> Export Packaged Workbook -> saves a .twbx

The practical rule: if you're sharing a workbook with someone who doesn't have access to your live database (e.g. emailing it to a colleague or posting it to Tableau Public), use .twbx so the data goes with it; if you're just saving your own work against a source you'll always have access to, a plain .twb is smaller and fine.

VizQL is the underlying query language and rendering engine that translates the drag-and-drop actions you perform in Tableau — dropping fields onto Rows, Columns, and the Marks card — into an actual database query, and then translates the query results into the visual you see.

• Every action in the Tableau interface (dragging a pill, applying a filter, changing a mark type) is internally represented as a VizQL statement.
• VizQL generates the appropriate SQL, MDX, or other native query for whatever data source is connected, abstracting away the differences between backends.
• On Tableau Server, the VizQL Server process is specifically responsible for executing these queries and rendering the resulting visualizations for every request.

VizQL is the core innovation behind Tableau's approach to visual analytics: instead of writing SQL and then separately building a chart, an analyst manipulates the visualization directly, and VizQL handles translating that visual manipulation into the correct underlying query automatically.

Tableau treats NULL as "no value," and handles it differently depending on where it shows up: an axis, a dimension header, or inside a calculation.

• On a continuous axis (like a date or number line): Tableau shows an indicator icon in the bottom-right of the view noting that some marks are not shown due to NULLs, since a NULL can't be plotted on a numeric axis.
• As a dimension member: NULL values typically appear grouped together under a "Null" header, treated like any other category value.
• In calculations: functions like ISNULL() and IFNULL() let you explicitly detect or substitute NULLs; arithmetic involving a NULL generally propagates to a NULL result unless handled.

IFNULL([Discount], 0)   -- substitutes 0 wherever Discount is NULL
ISNULL([Ship Date])      -- returns TRUE/FALSE

A common gotcha: a NULL on an axis silently hides affected marks rather than erroring out, which is why checking for that small NULL indicator icon is a good habit whenever a chart looks like it's missing data points you expected to see.

A Gantt chart plots bars along a timeline to show the duration and sequence of discrete tasks or events, making it the natural choice whenever "how long did this take, and when" is the question.

Columns: [Start Date] (continuous)
Rows:    [Task Name]
Marks:   Gantt Bar, Size = [Duration]

• The Gantt Bar mark type sets each bar's starting position based on a date field on Columns.
• The bar's length is controlled by dragging a duration measure (e.g. days to complete) onto the Size property of the Marks card.
• Rows typically hold the task, project phase, or resource name, so each row shows one continuous bar (or a broken series of bars for recurring tasks).

Common use cases include project timelines (task start/end dates), employee scheduling (shift start/duration), and equipment usage logs — anywhere the core story is "this thing was active from this point for this long," which a Gantt chart shows more intuitively than a plain table of start and end dates ever could.

A heat map encodes a measure's value using color intensity across a grid of two dimensions, letting you spot patterns, hotspots, and outliers at a glance across a large number of categories without reading individual numbers.

Rows:    [Sub-Category]
Columns: [Region]
Marks:   Square, Color = SUM([Sales])

• Two dimensions define the grid's rows and columns (e.g. Sub-Category by Region).
• A measure is dropped onto Color, and a diverging or sequential color palette shows low vs high values.
• Mark type is usually Square or Circle, sized uniformly, so color alone carries the message rather than mark size.

Heat maps scale well to far more categories than a typical bar chart could display legibly — a grid of 20 sub-categories by 10 regions (200 cells) is easy to scan visually for color patterns, while the same data as 200 individual bars would be unreadable.

A treemap shows hierarchical, part-to-whole data as a set of nested rectangles, where each rectangle's area represents a measure's magnitude and rectangles can be colored by a second measure or dimension.

Marks: Square/Treemap type
Size:  SUM([Sales])
Color: SUM([Profit])
Label: [Sub-Category]

• Larger rectangles represent larger values; smaller rectangles represent smaller ones, all within the same total space.
• Nesting (e.g. Category containing Sub-Category rectangles) shows hierarchy directly through rectangle grouping.
• Coloring rectangles by a second measure (like Profit) turns a treemap into a two-variable view: size shows one metric, color shows another.

Treemaps are especially useful when you have many low-value categories alongside a few high-value ones, since area naturally draws the eye to what matters most, without the long tail of small values cluttering the view the way a bar chart with dozens of thin bars would.

Tableau's built-in forecasting feature projects future values for a time-series measure using exponential smoothing models, without requiring the user to write any statistical code.

Analytics pane -> drag "Forecast" onto the view
-> Tableau extends the line/bars with projected future values
-> shaded band shows the confidence interval

• Tableau automatically detects trend and seasonality patterns in the historical data to choose an appropriate exponential smoothing model.
• Forecasted points are visually distinguished (typically a dashed line or lighter shading) from actual historical data, and a shaded confidence band shows the range of likely outcomes.
• Forecast length, seasonality, and confidence interval width can all be adjusted in the Forecast Options dialog.

Because it's based on exponential smoothing rather than more advanced regression or machine-learning models, Tableau's native forecasting is best suited to quick, exploratory projections; more rigorous forecasting needs are often better served by exporting data to R or Python via Tableau's statistical integrations.

Reference lines and reference bands add a fixed benchmark directly onto a chart, so viewers can immediately see how actual values compare to a target, average, or acceptable range without doing mental math.

Right-click the axis -> Add Reference Line
-> Value: Average of SUM(Sales)
-> Label: show value + computation

• A reference line is a single horizontal or vertical line, typically showing a constant, an average, a median, or a percentile.
• A reference band shades the area between two values (e.g. between the min and max, or plus/minus one standard deviation), highlighting an acceptable range rather than a single point.
• Both can be scoped to the entire table, a pane, or per cell, so a "per-region average" line is possible alongside data broken out by region.

These are especially effective on dashboards meant for quick decision-making: a sales chart with a target reference line lets a viewer instantly see which regions are over or under target, without needing a separate number or table to compare against.

A bin is a field that groups a continuous measure into fixed-size ranges (buckets), turning something like exact ages into ranges such as 0–10, 10–20, 20–30, and so on.

Right-click [Age] -> Create -> Bins...
-> Bin size: 10
-> produces a new field "Age (bin)" with values like 0, 10, 20...

• Creating a bin produces a new discrete field, which can then be used on Rows/Columns like any dimension.
• The bin size is configurable, and Tableau suggests a reasonable default based on the data's range and distribution.

A histogram is the chart built on top of bins — it's specifically a bar chart where the X-axis is a binned field and the Y-axis is a count (or other aggregation) of records falling into each bin. In other words: a bin is the underlying field/grouping mechanism, while a histogram is the specific visualization that displays those bins as bars, typically created automatically via the "Show Me" panel once a single measure is selected.

Row-level security (RLS) restricts which rows of data an individual user can see in a published view, so the same dashboard shows different data to different people based on who's logged in — without needing to build a separate workbook per user or team.

User-filter approach:
{ FIXED : IF USERNAME() = [Sales Rep Email] THEN 1 ELSE 0 END } = 1

Or using a mapping table:
[Region] = LOOKUP(current user's allowed region)

• The most common pattern joins or references a permissions/entitlement table mapping usernames (or groups) to the data they're allowed to see.
• A calculated field using USERNAME() or ISMEMBEROF() compares the logged-in user against that entitlement data, and is used as a filter on every relevant worksheet.
• RLS is enforced at query time on Tableau Server/Cloud, based on the identity of whoever is viewing the dashboard.

RLS is essential for any shared dashboard containing sensitive or role-specific data — for example, a regional sales dashboard where each sales manager should only see their own region's numbers, all served from one single published workbook rather than dozens of near-identical copies.

Both are desktop applications, but only one of them can actually build content — the other exists purely so people without a full license can still view work someone else created.

Tableau Reader is essentially a distribution mechanism: an author builds and packages a workbook (.twbx) in Desktop, then shares that file with someone who only has Reader installed, and that person can explore filters and parameters within the workbook, but can't create new worksheets, add fields, or connect to a different data source.

A custom SQL connection lets you write your own SQL query as the data source, instead of connecting to a table (or set of joined tables) through Tableau's visual data source pane.

SELECT customer_id, region, SUM(sales) AS total_sales
FROM orders
WHERE order_date >= '2025-01-01'
GROUP BY customer_id, region

• Useful when the needed logic — complex joins, window functions, pre-aggregation — is easier to express directly in SQL than through Tableau's visual join interface.
• Custom SQL is treated by Tableau as a single "black box" table; Tableau doesn't know the underlying table structure, which can limit some optimizations it would otherwise apply to a native table connection.
• Because the query text becomes part of the data source definition, changing requirements often means editing the SQL directly rather than adjusting fields visually.

Custom SQL is a powerful escape hatch, but it comes with a performance caution: since Tableau can't push some filters down into a custom SQL query as efficiently as it can with native tables, extracts built from custom SQL are often recommended over live connections to those same queries, especially for anything complex or frequently used.

Hyper is Tableau's in-memory, columnar data engine that powers extracts, replacing the older .tde format with a faster, more scalable architecture.

• Columnar storage lets analytical queries scan only the columns actually needed, rather than reading whole rows, which is a major speed advantage for the kind of aggregate queries Tableau typically runs.
• Hyper supports much larger extracts than the legacy .tde format could practically handle, and generally builds/refreshes extracts faster too.
• It uses dynamic code generation for query execution, compiling parts of a query into optimized machine code on the fly rather than relying purely on a generic interpreter.

Data source with an extract -> stored as .hyper
-> queried through Hyper's columnar engine at view-render time

Hyper is largely invisible to end users day-to-day — you don't interact with it directly — but it's the reason extracts became dramatically faster and able to handle much larger datasets after Tableau adopted it, replacing the older TDE-based extract engine used in earlier versions.