Video | Tableau | Data visualisation | Data prep | Tool strategy

Tableau Composable Data Sources Change your workflow

Use Published Data Sources as connections in your data model. This will change your workflow!

Part ofWhat's new in Tableau 2026.2Tableau Data Model Masterclass Tableau Key ConceptsGuest Appearences
Watch on YouTube
  • Composable data sources let you treat published data sources as building blocks, so analysts can compose their own model without rebuilding or editing someone else's certified data source
  • You can add tables in the flow of work via an embedding-style experience, relating them on shared fields like book ID, and Tableau dynamically scaffolds the multi-fact model without breaking existing joins
  • Row-level security can be layered onto a workbook's data source level using a live entitlements connection and a USERNAME() calculated field scoped across all tables, without altering the source model
  • Tableau Prep outputs can now feed relationships, so you can publish fact, aggregate and dimension tables and combine atomic detail with pre-aggregated tables in one data source to avoid the speed-versus-drilldown trade-off
  • Each query tree runs independently and stitches results together in memory, so over-atomising your model can create inefficient workbooks even though the database itself is hit less heavily
  • Composable data sources realise Tableau's semantic-model vision, turning the existing library of published data sources into reusable, AI-readable assets

What do composable data sources mean?

Kirk is back on the channel, and we’re tackling a feature we’ve waited a long time for: composable data sources. At the Tableau conference keynote, I joked that Tableau first talked about this in 2024 and guessed it might land in 2026.2, and we’re now nearing that release. This video is a deliberate follow-on from our Data Model Masterclass, which has been watched thousands of times. If you’ve never used the data model before, go and watch that hour and a half first because it sets up everything here.

So what does composable actually mean? Plenty of people are calling them compostable data sources, which would imply they break down. They don’t. The idea is the opposite. Previously, if you wanted to use a published data source, you’d go to the web, create a new published data source from a server or the cloud, and that was that. For an individual analyst, there’s no problem. But in enterprise environments, someone has already built a published data source you don’t own, and if you want to add a table, your only options are to ask them or rebuild the whole thing by dragging and dropping. That causes an explosion of near-identical data sources, and with AI in the mix, it gets even messier.

Composable changes this. You can publish smaller building blocks, fact tables, aggregate tables, and dimension tables with proper field-level metadata defined once. Then any author, or any AI client, can compose their own data source from those pieces instead of redefining everything over and over.

Published data sources as semantic models

At the conference, Tableau described the Tableau ecosystem as potentially the world’s largest source of semantic models. What they mean is that every published data source is already a piece of semantic information you’ve been building for twenty years. The final hurdle is simply letting those data sources talk to each other.

The catch is that a published data source can be a semantic model or not. You can point at one big table or view, pre-join everything, add no commentary, and it isn’t really semantic. Or you can bring tables in at their natural grain with proper commentary, and now it genuinely is. It relies entirely on the person creating it to do that work well.

Demo: the bookshop data source

We return to the bookshop data source from the masterclass, this time as a certified semantic model that Kirk and I have both signed off. The scenario: we sell books, and people also check books out, library or Audible style, but that checkout data lives on another platform and only arrives once a month, so it was never part of the original model.

1.00

Kirk builds a quick view of sales by month, colored by genre, to show the model working as expected. Then comes the interesting part. If you wanted to add checkouts the old way, you’d have to edit the shared data source, which could break it for everyone else using it.

Composing in the flow of work

What genuinely impressed Kirk is the UX. It’s true to Tableau’s original in-the-flow ethos. Instead of editing the shared source, you compose. Having already published the checkouts table on its own, you simply bring it in and relate it on book ID to book ID. You keep all the field commentary, calculations, security, and enterprise governance from the certified source, but get the flexibility of working with flat files on the desktop.

Because checkouts and sales each track their own dates, this becomes a multi-fact problem, so you bring in a dedicated dates-published data source too, relating checkout month to month-of-date. The lesson here: keep a single published date dimension with all your date fields and reuse it everywhere. You can then build a checkout-to-sales ratio calculation, drop dates from the dimension table to dynamically scaffold the axis, and add genre on color. Relationships never break what already exists, so the original join continues to work throughout.

1.00


Viewing the combined data model

When you publish the workbook, you get an embedded data source built from published data sources. Kirk’s favorite underused feature comes into play: from a worksheet, you can view the data model, show only the tables in use, and, crucially, toggle off the hierarchy, so you see it purely as a model. Looked at this way, you wouldn’t even know three separate published data sources sit inside the connection.

1.00

This showcases the power. Your dates field might be an organizational calendar published elsewhere. Your checkout source could support row-level security, so a regional manager only sees their transactions while still seeing the wider world of books and authors from the main model. I’d expected this to need a strict relationship between the entities; instead, Tableau largely figures it out, and you can relate to any specific table within a logical model. That opens up the possibility of rethinking how you organize projects: a central universe plus ancillary insights brought in ad hoc.

Where AI and suggestions could go

Understanding the heuristics Tableau runs under the covers matters, which is why the masterclass is essential homework. Tableau’s ethos has always assumed you’re smart and know what you’re doing, the opposite of the Salesforce wizard-driven approach.

The obvious next step is for Tableau to suggest other data sources to bring in based on what people use. How many published data sources sit unused on servers but would answer someone else’s question? Once one person creates a relationship, that’s insight an AI model can pass to the next ten analysts: instead of writing complex data fields, there’s a date table over here, bring it in. What I want isn’t an agent that auto-builds my model, but one that helps me reason: I want to compare checkouts to sales, it notices both share book, suggests the relationship, and points me to the already-published date table. Tableau is about 90% of the way there because the modeling and heuristic engine are the hard parts. When done right, querying through the Tableau MCP also dramatically reduces chattiness and token usage.

VizQL Data Service and the connection window

One idea we keep coming back to is how hard it is to communicate that Tableau, especially with VizQL Data Service, probably creates the largest single developer surface for connecting to 200-plus data sources. VizQL Data Service is an API that lets developers query any data source in the Tableau ecosystem, and the new REST API connector provides a single point of access to virtually any database worldwide.

Layer analytics extensions on top, run machine learning or Python in Tableau Cloud as a published asset, and composable data sources make those capabilities portable. This is why we keep promising a “ten things you didn’t know you could do with this connection” video, building one mega connection that touches many different systems at once.

Adding row-level security

Kirk shows how to apply row-level security by genre using a simple entitlements table, published as a live connection so we can update it on the fly. The point is you can add security at the workbook’s data source level without messing up the certified model, which its owner may not want secured for everyone.

1.00

You search for and bring in the book security source, relate it on genre, then create a calculated field, USERNAME() equals the name field, called RLS. Add it as a filter set to true, and scope it to affect the security table and all other tables. Publish without letting others author and each user only sees their own genre. Editing the live Google Sheet entitlements updates the security almost instantly, which surprised even Kirk, because each query runs against the live source rather than a cached extract.

1.00

Bringing in targets via Tableau Prep

The last and arguably most powerful demo: sales targets that previously forced you into a data blend because you didn’t own the source and the data needed pivoting. Now you can use Tableau Prep with relationships. Kirk builds a flow that connects to the targets on Tableau Server, adds a clean step, pivots columns to rows, renames the genre and target fields, and then outputs to a published data source.

1.00

The breakthrough is that Prep outputs can now be used to feed relationships. Before, the Prep output was always the final destination; now you can have three outputs from one flow and build your data model off them. Kirk describes a real example: take transactional call-center data, fork the flow, keep one drill-down output at the grain and aggregate another to a monthly resolution rate, ranked by employee, then drive a bump chart that filters the detailed source on click. The aggregated source handles the heavy lifting because it’s always filtered first.

Recapping the assembled model

Pulling it together, we started from the certified bookshop source, then added security, a dates table for checkout comparison, and now targets, all without going back to the original owner and without breaking any existing workbook. Relating the cleaned targets on both genre and date lets us compare sales against target across months, even though targets only exist at month grain, and row-level security passes through the whole thing.

1.00

Viewing the data model again shows everything stitched together. In Desktop, highlighting a field would pop up the tables it came from, and Kirk expects a Prep-style interface showing the joins to arrive in time.

Workflow implications for analytics engineers

You can compose either way: build an embedded data source inside a workbook, or publish a brand new superset data source for others, agents, or VizQL Data Service to consume. With Prep increasingly part of the analyst toolkit, your role starts to look like a lighter-weight analytics engineer without needing SQL. You publish fact tables of raw transactional data, use Prep to create aggregate tables and cleaned dimensions, and trained users compose their own sources.

This kills the old trade-off: aggregate and you lose drill-down, don’t aggregate and your dashboard crawls. Put both grains in the same data source, and you no longer have to choose. The excitement is staying in your flow of work to do advanced things from a business perspective, adding row-level security, bringing in targets, without leaving it.

Query trees, performance, and live versus extract

A word of caution. Each fact path is an independent query tree Tableau runs, and when a view uses calculations or fields from multiple trees, it does a coalescing query in memory. Get too atomic, and you can pull back so much data that things slow down. The upside is that your database isn’t hit with a single nasty generated query; if connections are live, the query can push down to Snowflake, but cross-tree stitching always happens in memory because databases struggle to model it.

It’s worth being clear: this is a live connection to published data sources, which may themselves be extracts. The live-versus-extract toggle applies to the whole picture. Hit extract in Desktop and it snapshots all the tables as hyper files, then queries them by what’s in the view. The UX confuses people; a live Google Sheet sitting alongside extracted tables isn’t visually distinguished, and Kirk wishes Tableau borrowed Looker-style terminology to make the connection type clearer. Used irresponsibly, you can build very inefficient workbooks, but that’s always been true in Tableau; if you can do something odd, it will let you.

We’ll pencil in that “ten things you didn’t know you could do with a Tableau data source” video.