How to Use Composable Data Sources in Tableau

Composable Data Sources: Bringing It All Together with Kirk Munroe

By Celia Fryar

What happens when a published Tableau data source answers your original question, but the next question requires information it does not contain? Perhaps you need to compare sales with customer ratings, introduce monthly targets, or apply access rules for different users. Composable data sources provide a way to extend an existing model with additional published data sources, allowing the analysis to develop as new questions emerge.

Published data sources have long supported sharing and consistency across workbooks. Extending them, however, often required returning to the original owner, creating another version, or using data blending to bring additional information into a view. Each approach addressed a need, but could also introduce more maintenance, repeated business logic, or performance challenges.

For this Data-Driven Community session, I welcomed Kirk Munroe, Tableau Visionary, Ambassador, and author of Data Modeling with Tableau, to explore a more modular approach. Kirk explained how published data sources can become reusable building blocks, then demonstrated the concept through a series of questions about book sales.

The conversation also explored where modeling decisions belong and how to balance flexibility with performance. As I shared during the session, moving reusable logic upstream has long been part of my approach. Kirk added an important consideration: we also need to preserve the level of detail people require to filter, explore, and ask new questions.

Watch Composable Data Sources with Kirk Munroe

>> CELIA FRYAR: Thank you for being here. We have a great program today about composable data sources, a feature that so many of us have been eagerly looking forward to, and someone who is very much an expert in this space. I’m excited that he’s been willing to come and share from his wealth of knowledge. We want to just acknowledge that you guys are data heroes. We firmly believe that those of us who carry the torch on bringing insights to data serve a role that is essential, and they’re so much valued. Regardless of the role of AI in your lives, y’all, you are data heroes. Please step into that and be that for your people around you.

Today I’m going to talk about a couple of upcoming things in our realm here. First of all, the Austin TUG tomorrow on the 10th of September, is hosting Matthew Miller, who’s VP of Product at Tableau. He’s going to be talking to us about data storytelling in this AI age. Let’s just be cool. If you’ve ever seen any of his posts on LinkedIn, he’s a master storyteller. Then at the end of the month, we’re hosting Michael McCusker, who is a Tableau Ambassador, Real rising star in the data fam. I’ve been watching this happen over the summer, where he’s been assimilating this messaging.

He’s one of these people who are very talented at taking complex things and communicating them in an incredibly straightforward and digestible way. He’s going to be talking on the San Francisco talk. It’s going to be happening midday, our two o’clock in the Central Time Zone. From idea to execution, what do you do to make that happen when you have a concept of a KPI that you’d like to have, and it’s just not there. Then how you can create that yourself these days with the tools that we have at our fingertips.

Today we’re going to have Kirk speaking to us in just a moment. He is a Tableau visionary and ambassador. I’ve been fortunate enough to become familiar with him in his work in that space. He’s an author of data modeling with Tableau, and very much a thought leader in our space for anything to do with data models, relationships, what is a way to maximize what we’re doing with performance issues and anything to do with data modeling and data, period. I think of you first, Kirk.

Thank you for being here today to talk about our composable data sources. Like I said, we want to chat in chat. We’ll keep that open, and Lauren and I’ll be keeping an eye on that. Onto that, we will be also following up with a email this week that’ll give you the recording link to the session, as well as a quick tips-and-tricks video that Lauren put together to explain how you too can do this quickly and easily in the new version of Tableau. That will be later this week as a follow-up.

Lauren and I run this monthly, usually the second Wednesday of every month, and we’d love for you to join us on a regular basis. We 99% of the time pick topics that you guys have asked for in chat in meetings. We very much welcome your input. Right now, we have only one suggestion for the last few months of the year, and it was to talk about Tableau next. Really would welcome your input. Please either email us, direct message us, just say it in chat. We’re listening, and that’s what we guide these as on the basis of.

This too was a request earlier this year. Without further ado, I’m going to pass the baton to you, Kirk, and ask you to please take us away. Like I said, we’ll keep an eye on chat. The screen is yours.

>> KIRK MUNROE: Thank you, Celia, Lauren, and everyone for having me today. I used to talk about this more than data sources and semantic models and stuff, but it seems like it’s a niche I’ve got myself into. It’s fun to be here talking to everyone about it today. I’ll probably do 10 or 15 minutes of presentation, and just on background, because I think it’s important for context, but mostly stay in demo because at the end of the day, I’m a product person. Hopefully everyone loves it. I think it pops better from that.

We’re talking about moving from published data sources to composable analytics. Again, I think you now know who I am from the introduction, hopefully. Again, I did write the book on data modeling with Tableau, which is getting old. It probably needs a refresh somehow or other. I can share the links at the end. I would say another thing you can check out is along with, Tim Ngwena of Just-Tim, formerly Tableau Tim. We’ve done a Tableau Data Master masterclass series on his channel, which should be worth checking out because it goes through three different parts, three different videos you can follow along as well, including composable data sources in the most recent.

I’m going to start with a shared trauma story. Usually, I ask people these things, which is to raise your hands if you’ve ever done any of these. Again, we’re not in a room, so you can just either put it in the comments or think it to yourself, but basically whether you’ve mastered creating the one great big denormalized table to make it easy to create a dashboard, or embedded all your calculations and business logics inside dashboards, or you’re duplicating data sources because someone asked you for something that just has a slightly different view, might need one, just one additional little table.

Cringe when you see the pills and data sources with those little blending orange check marks in them, and then, in general, connecting to a published data source, hoping to create a model with another one. We probably could have added using something like Tableau Prep or Alteryx and taking the output from that and combining that with relationships with another data source. We were calling this PTSD, which is Published Tables, but Siloed Decisions. That’s when you end up with these.

These polls used to do way better on LinkedIn than they do lately. Just before we gave this presentation at Tableau conference, which you can see up on the top, I did along with Will Perkins, I asked this question, and it was just interesting that it came back when I asked people, with composable data sources coming from, what are you most looking forward to? It was a nice blend. Again, a small sample size, but basically a third, a third, a third between not having to blend anymore the governance aspect and then being able to use Tableau Prep with relationships. I do think it makes Tableau Prep a way more useful product.

Just a quick history of how we got here is Tableau in the early days definitely made us flatten out our data sources in One Big Table. Even if you felt like you weren’t because you created your joins in Tableau instead of creating a view in the data source or writing custom SQL, you still ended up with that. That caused a lot of problems. If that was the way it was going to be, how do you extend these data sources and make them more usable to different people? They added data blending in November of 2010. I don’t know if you’ve ever used blending before. It’s a bad experience.

I was working with a client in the last six months or so, and what they pointed out with this blending– They had a dashboard that took three and a half minutes to open. I took a look, and it didn’t look that complex. I go, “Do you have a blend going on?” and we found the blend. They really needed to do it. It was before composable data sources. I go, “I know you need that, but could you humor me and pull the blend off?” The workbook opened in two seconds. It’s like orders and orders and orders of magnitude sometimes.

It was something you needed because you just had a table. All you could do is if you couldn’t open up the original data source, you needed some way to add things like, say, sales targets or something, which is an example we’ll show today. Then Tableau introduced this concept of a published data source in 2012. Before this, you couldn’t even share data sources across workbooks. Depending on when you started using Tableau, this might seem like a foreign concept, but it was crazy in that you had to recreate the data source every single time you created a workbook.

Then I would say Tableau was pretty weak in general at data modeling until 2022.2, about April of 2020. This would be like six and a half years ago now. A lot of people still don’t use relationships, but relationships had a massive impact because it allowed you to bring in your data and keep it at a natural level of grain that it’s at. At the right level of detail, it saved up having to write a lot of LOD calculations and slow calculations and made it a lot quicker extracts, et cetera. It was a big move forward.

Then shared dimensions, or multi-factor analysis, came a little over two years ago now, which is the ability to combine multiple fact tables together. I think this is when Tableau got super serious about it, because I always say before this, all you could really do is drill down, but you couldn’t really figure out correlations across different parts of the business. It was very hard before you had this feature to be able to answer questions like, do we think our product sales are going down in a category when their support calls go up, or if the returns are coming back, because it was really hard to share things like customer and product across multiple tables that came from different business areas or different fact tables.

Now you can do. It’s a very powerful feature that doesn’t get used that much. Basically, none of these solved the extensibility problem of: I have someone else’s data source. I don’t want to have to recreate it. I just want to extend that data source by adding additional context through additional tables to it. Before, you’d have to go back and open up data sources to do this. It was a pretty big deal.

What we talk about now is, and this was our TC presentation, I’ll go through it a little bit quickly, the presentation part, but we started calling this the unlearning era. Basically, if you’re new to Tableau, you don’t have to worry about the unlearning area, but if you’ve been using Tableau for a long time, especially pre 2020, you know that now you have to start thinking about I have to do things completely differently. I think people at the time, I think at TC, even though it was only a few months ago, like in May, they were sick about hearing about AI, or we would have built it in more.

I think that this is even way more important in the area now that we’re turning agents against these data sources because we don’t want to have to keep creating table descriptions and field level descriptions and aliasing over and over and over again in multiple data sources. Now we can create it in base data sources, and we can just compose new data sources, which we’ll see today. Then we can make those available to agents, and it’s just going to reduce their chattiness, make them a lot more effective in giving the right answers, and just take the governance problem way down.

It’s already a pain for people to add that semantic knowledge on top of their data sources, but having to do it over and over again would just not be sustainable at all and be pretty poor governance. In the unlearning era, though, we talk about first getting rid of this One Big Table and moving to a modular build. In the past, it was very easy because we reduced risk when we just got it down to one table, but this one table and flattening and getting all your answers up front should not be the default answer.

Although it’s safe and then people are more likely to trust our dashboard because we have a better control over our data model, they’re not very good at letting people ask new questions against them. The other thing they tend to do is they get people to push their logic into the workbook, as opposed to what we want to do is we want to get this down to the data source so they’re reusable. That net revenue means net revenue to everyone. It could be different from company to company, but at least within your company, you’re always going to get the same answer.

We used to flatten to survive, really, and now the new has got to be to model, to use relationships to evolve. The second was that we used to think about endpoints. You’d build a published data source, and people would have to use that published data source. Now we have to start thinking about them as building blocks because published data sources were good for sharing and governance, but you couldn’t really extend on top of them. Now what we’re saying is a certified data source is not the end of the story, and just because they’re reusable doesn’t mean it’s untouchable. We should be able to take these and create layered assets out of them.

That’s where the term that our architecture becomes more composable but not duplicated, which is important. Before, it used to be publish and stop; now we know that we publish and expand, which could have us completely rethinking about the way we create and publish data sources. The last one, which goes with it, is we have to stop thinking about duplicating and going to extending. What happened was Tableau forced us to do this a lot.

What happened was when you have a published data source and you needed to extend that data source, you might go back to the owner if you didn’t own it and ask them to extend it. They would naturally be nervous to do that because it might break any number of workbooks or at least make them be retested. Again, with relationships, it shouldn’t break them, but you never know. Even if it’s your own, the same thing comes true. What you would do is you create another whole published data source, and then you end up with a Tableau Server or cloud site with a million different data sources.

Now we just have to rethink about it and say, “How do we create data sources that people can layer on top of safely?” That’s what composable data sources effectively become all about. We used to copy because that was the fast solution; now we have to extend because that scales a lot better. What we were originally going to call it was published data sources don’t have to be pains in the butt anymore, but Salesforce took that away from us. I’ll just go through this quickly to say that there’s a couple of ways you can do this, but you should think about your published data sources as building blocks regardless. The Lego works pretty well.

There’s one philosophy you could take to say, I have a sales data source, and I have a marketing data source. What I could do is say, what’s better is I’m going to break those up into individual tables and publish each of those as a data source, and then I will allow people to do things like create a whole customer semantic data source, or they could recreate these often as well. That’s the idea. Or we could take existing published data sources which have sales and marketing both in them, as an example, and then let people even build bigger on top of that.

In other words, your published data sources don’t have to be single tables. They can already be data sources that you can add on to as well. There might even be a better visual for this, which is we could think about all these having the key fact tables in them and then having a bunch of shared dimension like customer and product that sit on top and don’t build them into these models and have people be able to compose just what they need for their area or, again, build them up into the bigger ones. I think this becomes more obvious when we get into the demo, which we’ll do now.

The only reason I like to show this before the demo is Tableau used to call this, if you’ve been around for any length of time, the cycle of visual analytics, which they got away from. Part of the reason was the idea is the old way would be: you’d get a task, you’d get data, you’d choose visual mapping, view data, develop insight, and act on it. In the past, before Tableau, with things products like Cognos or Business Objects, you almost had to go all the way around. If you came here and you viewed your data and it was wrong, what you would have to do is go, “I don’t have an insight or I have to go back and open up and create my whole new data model again. “

Tableau did in Desktop is they let you just keep adding to it, kind of, but on Server or cloud, it’s harder to do this because, until composable data sources, this flow of going back and getting new data really became interrupted because I would have to go and open up a data source or create a new data source and start again. I think they’ve done a really good job as we get into this. You’ll see in the user experience that they’ve really brought this back, and I would say actually do it better now than it’s ever been done in the past. Does anyone have any questions before we jump into the demo?

>> CELIA: I’m not seeing any.

>> KIRK: Perfect. Let me just show you. We’ve got this data source that I created from the bookshop data source. You can get this by– I can show you the link, but if you search it, Tableau makes this available. I know they still primarily use Superstore, but this was the data source that they used to show relationships way back in 2020. It’s been around the whole time. What I’m going to do is I’m going to create a new workbook using this data source, and then I’ll show you the data source.

This is our data source when we connect. What it has in it is it has four quarters of sales data unioned together. Books are sold by edition, because there could be reprints, et cetera. Then each edition has a publisher; an edition is associated to a book, of course, and then books have authors. The other thing I’ve done here is I’ve taken– I could have made this more obvious. If you know this data source, I’ve taken book in the info table, and I’ve pre-joined them together into this one book logical table. This is a book and information about books in it.

We could answer lots of cool questions on this. Just as a simple example, if I come down to, say, sales date. Let me say I dropped sales date up here, and I want a continuous month on this. Then we could take sales. There’s just one row for every sale. If I take that up, that shows us our sale. Then in book, I brought in the genre of the book just as an example, and we could get this. This just shows simply this is sales of books by month. Odd that everything’s in the year 2193. I don’t know how they did it that way, but it’s only one year’s worth of data.

This shows our sales; our big month is obviously– then sci-fi fantasy is our biggest category. This is great. Imagine we continue, we build a dashboard on this and then say before composable data sources, that someone came back to us now and said, “You know what though, what I actually want to see is that I want to see the relationship between sales and book ratings.” In other words, when book ratings go up, I want to know if sales also go up, which is a very valid question. If I come over to my data model here and I go ratings, you’ll see I don’t have ratings in my model.

Again, I could jump back here, and I’m like, “I don’t have ratings.” It’s a valid question, but as an analyst, dashboard developer, I don’t want to go back to the executive who asked for that and say, “You’re going to have to give me a day or so. I have to go find the ratings and I have to build a data source.” They don’t want to hear that. Do you know what I mean? Especially now they go, “I’ll just ask Claude or something.” What’s neat, and this is what the feature is, you’ll notice up here, which is completely new, is this add published data source.

If I click on add published data source, I could say, we already have a ratings data source. If you see, I have one here called ratings. Then again, I could go explore it independently, but I know this is the right one. I’m going to go ratings, and then what happens is each book has ratings. It’s just a Tableau relationship. I could either keep this as a base table if it were a fact table, like a table of measures in this case. That doesn’t make a lot of sense, but I could say, you know what, I’m going to take books, and books have ratings. Then what happens is it’s on book ID and book ID.

One really slick thing about relationships right away: this is now a composable data source. It has multiple data sources in it. You’ll notice that it’s effectively going to be an embedded, if you know the terminology, data source of published data sources, which is neat. I don’t have to flood my server with a bunch of new published data sources. At the end, I’ll show you we could create a new published data source from multiple data sources, but in this case, what I’m doing is, when we do it inside the workbook like this, we’re effectively letting dashboard developers and analysts compose their own data sources, which is why the name actually makes sense when you see it in action.

Another nice thing about relationships, whether they’re in composable data sources or not, is when you add a table like this on a relationship versus a join, you never break anything that’s existing.You’ll notice everything that would have been in the workbook would have been fine. The way I could show you this is this feature has been in now for, I think, coming up on a couple of years, although it always gets better. If you come to the worksheet menu and view data model, what we’re actually going to get– A little weird. This is better in desktop than the browser. I should have used desktop.

You’ll see that we get the whole data source, but if I take here, what I’ll get is it shows me only the tables that are being used. Since this sheet doesn’t use the ratings table, the addition of a new ratings table is not going to mess it up, which is neat. You can also get rid of the hierarchy of the multiple data sources as well here by saying group by data source. Let me come out of– Let’s go back to our data model. You’ll see that this is going to stay here. If I were to make a change, you’ll see that that should update automatically.

Remember the question I had getting back to it is I wanted to know the correlation between sales, which again is just a count of rows on this. I can double-click that on and rating, which now I have, because we’ve composed our own data source by adding ratings. I could take ratings, and we want to make an average of ratings. Now, for example, what I could do is I could come in here now and take our book ID, or book title, whichever. There’s only one title. Title is unique in this data source, so I could take that and throw it on like this, and then I’m going to swap rows and columns.

These are ratings, and these are sales. Now I could quickly answer the question by throwing a trend line on, is, there is a positive correlation, even if the R-squared is not that high. There is a positive correlation between when ratings go up, books tend to sell more. I could decode on that analysis of it all day. You could throw genre and show it’s not true for all genres. Interesting. Again, there’s not enough data here, and it’s fake data anyway, but you get the idea. We could actually ask the question like that.

I think another very valid use case is, though– Let’s say that we’re building this for someone, but we don’t own this data source. We assume this is a published data source, this bookstore data source, that serves a purpose. For us, the same executives, say, we’re building for says, “You know what, though, not everybody should be able to see every genre,” as an example. As a matter of fact, I have this simple little entitlements table over here, which goes– Let me take that out. I’m going to show you how it’s live. Which has– We have genres, and we have people’s names.

“I would like,” they say to you, “for you to take this into consideration.” The interesting thing is, once we build this in the model, if you were using an MCP client and an agent, again, it would also, and I’ve tried to break this and can’t in a good way, also take this into consideration. Again, another great case of why you would use Tableau even if you’re using cloud, for an example. I’m going to come back here and say, I want row-level security on this. What I’m going to do is I have to first add that entitlements table. It’s based on genre, and we know genres in book.

I’m going to come here and say there’s already a book security one. Again, pretty easy to make, but what’s slick about it is you’ll notice– I don’t know why Tableau always says it’s an XLS. It’s not. You’ll see it is a Google Drive, and it’s live. This is a live data source connected to the sheet. We’ll see how that comes into play, where everything else is an extract. It’s a mixed. Another cool thing about this is you can mix live data sources with extracts, which you can’t do in a normal– Wow. The things that happen in demos. Why would– Let me try that again?

Book security. Why? Let me– I’m going to publish this for just a second. I’m going to publish this as a working workbook in Bookshop. Let’s go like that. Then I’m going to go to this workbook. I don’t know why this would be different, but let’s go edit this workbook and come here, and I have a published data source.

[pause 00:28:32]

>> CELIA: The error would imply that this is the problem, but I’ll show you how easy it was to create the other one for a second. We can see if that’s– Let’s try this again. I’m going to go like this, and I’m going to go new– I’m going to do two things. First off, let’s do this just in case it’s a bad error message. New published data source. Super simple. Again, this one’s called book security. I’m signed in with that Google account. I’m going to go connectors. I’m going to go Google Drive. I’m going to connect with this account. Continue, continue, and I’m going to say book security. I guess this could be a bigger issue, couldn’t it? Is this thing not called– I don’t know about the search either. We’re going to connect to this, just to show super simple model. It just has genre name in it of who can see it. Again, it doesn’t have to be one-to-one.

I’m going to publish this as security two, and then let’s just see if it’s this bug. Let’s come back here, and I’m going to go Bookshop data source. We’ve already seen the other one added to it. I’m going to go new workbook using this data source, and I’m going to come back here. Just to see if it was the other one, I’m going to add security too, just to show you it’s live. Let’s hope this works.

>> CELIA: I love the self-talk. This is very, very familiar.

>> KIRK: You see how my brain works on this kind of stuff.

>> CELIA: Yes. I appreciate that.

>> KIRK: This is a completely fine data source, is what makes no sense. Let me come back here. This is going to make my demo terrible if this is the bug, but I’m going to extract this. Didn’t I publish Society? It should work with live. I’ve done this demo a bazillion times with live, which makes it more fun because I actually change it and it dynamically changes, which is great. That’s a simple data source to be. Let’s go. Security two. I’m going to overwrite it. Now, if I go back to our original– This one. Let’s just see if that’s what it is.

Oh, I might have to do this. Sorry. Continue editing. I’m going to come here, and we’re going to see if that’s it. Just ruins the demo pretty bad. If not security two. That’s not a good bug. Anyway, I’m going to come down here and show this. I don’t know if people caught that. It seemed to only work if I made it an extract after I just said how great of a feature it is when it’s live. I’ll get back to the product manager on that. Now what we want to do, anyway, is imagine– This is our table, which is these people should only be able to see these genres.

Now what I have to do is, and I can write a calculated field anywhere, but in case you haven’t done this before, it’s a fun thing. I can just come here and go create calculated field. Tableau has this slick feature, which is username, and username returns the– If you’re on cloud, it returns the email address of the user is always the username. If you have an on-premises server and using Active Directory on-site and not Entra ID, it uses the Active Directory name, so you just have to watch that in the entitlements table.

For Tableau Cloud, it’s always the– For every other web OAuth provider, it’s going to return their email address. I’m going to call this row-level security, and I’m going to say username equals name. Name, again, which if you want to see which one it comes from the security. It’s name– I ruin my calculation by doing that. Create calculated field. Let me do this again. RLS name equals username. This is just a true or false– That basically says if the signed-in person is me or not, then I add up here a filter where I say RLS. I only want it when it’s true. Basically, what I’m saying is I only want when it’s true.

It’s really important you do this. We don’t want to filter only the security table. We effectively want security in all related tables. In other words, we want Tableau to do the join based on anywhere the genre applies. Basically, anywhere where books get filtered by that genre, and then only return the values when it’s true. If this works, what should happen if I go back to sheet one, what you should see is remember, there was eight lines of genres. If I would go back and click, you should see it’ll probably take a second, but you’ll now notice there’s only four lines of genres, which is neat.

If I came back here, for example, and I took myself off this. Before, this was really slick because I could go like that and then come back here. If I hit refresh here, what it would do is it would actually get rid of the genre right away because it was live. I’ll spare you– I’ll do it in the background, but now what we would have to do, unfortunately, because of this, what is hopefully a bug, is– we’ll see it come back in a second. I’m going to come to security two, and then what we’re going to do is we’re going to– Can I extract? No. Oh. They changed where this is. Refresh extracts now. There we go. Full refresh.

In a second, once that thing runs, I’ll go back to this tab to show you. I’m going to drop off, and there’s only going to be three lines here. For now, I want to continue, and we’ll see how that kicks in in a second. Again, it’s super slick when it’s live. [chuckles] The last thing I want to show you, in the interest of time, if so many of these that are fun to show is this has said Tableau blending thing we get hit with a lot. Imagine the next thing this executive we’re helping out is so impressed with what we’re doing, they say, “You know what? We actually have targets for sales for all these genres. Let me send you an Excel file. Can you bring that in?”

Of course, the thing is formatted like this, which is terrible, and Tableau doesn’t like it this way. We have a couple of options. We could bring this in using Tableau Prep by using a pivot of columns to rows first, but in this case, we can make it simpler than that, because you can do this pivot of columns to rows in Desktop. You can’t do the opposite. You need Prep for that. For now, I’m not going to use Prep, but you get the– We could use Prep. Again, if we have time, I could show that, but same kind of idea.

I’m going to come back here, and I’m going to go new publish data source because you can’t connect to tables. You can only connect to publish data sources. I could say files, real-world kind of scenario. I come to documents, and demo data should have had this ready book targets. There’s our book targets Excel file. Now, what we could do is we can come in here, and if you’ve never seen this has been in Tableau for a long time. You can’t do it with most databases, but with flat files, it’s pretty easy to come here, and I can pivot, and then if I update now, this is basically month, and then this is going to be our sales target.

Then what I can do with this is I can publish this as targets 8 because I’ve done this demo a bunch of times before. Oh, just a second. I’m going to go like this and extract this just to make sure. Create an extract. Again, I used to do this. The live semantics, because it’s an Excel spreadsheet, I’m not connected. In theory, if you connect it to one driver SharePoint, you should also be able to do this live, but that wasn’t what I was doing here anyway. I just want to make sure it seems like right now it might need to be an extract to work.

While we’re waiting for this extract, if we come back here– Now what happens if I refresh this? I feel like if I come here and come to this one and go update now, I’m still on for– That extract didn’t run yet. Anyway, we’re going to come back here. We got this book targets being created. Let’s give it a second because we’re going to join– We’re also going to create a relationship to extend our composable data source with this model as well. I’m going to publish this as targets now that it’s extracted. Now what we’re going to do is we’re going to come back into this workbook with our security in it, still hasn’t updated.

Now what we’re going to do is I’m going to add a published data source. This also shows where– There’s a couple of places we could join this or create relationships with this, but I really think we want to hang everything off a single date field because, remember, this has a date, and sales has a date. What I’m going to do is I’m going to add two published data sources. First, what I’m going to do is I’m going to add a date fact table. All this has in it, really, is it’s got one row for every day of 2023.

I’m going to take sales Q3, and I’m going to go like this, and I’m going to say what I want is I want sales date to be equal to date in here. That’s the first thing, makes sense in a second, but this is why we want shared dimensions or multi-fact. The next thing I’m going to do is I’m going to go get targets 8, the one we just created. I’m going to go like this. You’ll notice it’s down here. I want it in a base table position. Should be a bit longer presentation, but I want to share dates and the really facts, like a measure in this.

What I want is I want to be able to take this and also hang it off dates like this. Now, you’ll notice that this is only at the month level, and this is at the day level. What I want here is the name of the month. I could have transformed that in the Excel or created, effectively, a calculated field to put everything in the first of the month, but I can also create relationship calculations. I could say date name of the month of the date in this. Basically, what I’m saying is: find the month of the date, its name, which is what I have over here and then create a relationship on that.

It’s automatically at the month level. We can’t see it at the day level because they’re just not that granular, but it’s a really good use case, I think. How we can share this dates and then have two tables that are at different levels of grain, and still, as long as we know that, can get the answers we want. I’ll show you what I mean. If we come over here now, instead of trying to do some awful blending to get that in, now what I could do is– remember it’s by genre– I could take genre like this. I can– again, row-level security can only see those, barring what happened with that extract.

Then what I want to do is I want to take this date, and I want to show it at the month level. Then what I can do is– What we want is we want to know sales for each of them, but we also want to know, what did they call it, our sales targets down here. We also want to know what our sales target is. It’ll stitch that together for us in the view, which is pretty slick. Here it is. It’s like they can’t break it down. Again, there’s different ways we could hang it on, but why did that not work? It should have worked.

It didn’t like my date name calculation, which normally works. I’m just going to do something fun here for a second and date. Here we go. Whoops. In dates– I’m going to come over here and create a calculated field called date name. Anyway, you guys get to see how my brain works, if nothing else. What’s it returning for date name? January. February. That’s right. What is– Did I pick the wrong field over here? What’s month showing? If I come over here and go month January, and then what was my calculated field? That should be working. That matches.

These are bringing in everyone right now, but it shouldn’t be doing that. Let’s go for simplicity for the year, just for now. If I take that off– No, it’s multiplying them up. I’m sorry. I’m not sure why it’s doing that. That seems to be another thing. Sorry, this one went sideways. At least you guys get to see the problems we run into when we’re helping out to try to figure these things out. Has anyone figured out what I did wrong there that I’m getting those numbers that are wrong? It should be date name, and it should be the same, because if I were to take month from here and put it there, it lines up, but then it’s bringing in the total value, just not that value.

Anyway, I’ll have to get back to the product manager, but just to show that we could– That’s the– Oh. I’m sorry. My fault. Again, I think– No. This usually works, but if I went– This would take too long. Unless I’m doing something obvious. I’m going to figure out later, maybe me. In any case, you’ll see that it will bring in– The point is, we can bring the targets in; either I’m doing something wrong, or Tableau is doing something wrong there, which I’ll get back to you. I’m also demoing on a beta server, which makes me worried that that’s it, though I don’t– I think it’s a normal build though. It is.

You know what, maybe it’s because this is 2020 6.3 that these bugs exist that don’t. I probably should switch over to production– a non-beta server now. Sorry about the bugginess, but hopefully you got the concept of how you can take data sources and then build them together using composable data sources like this. Did anyone have any questions? Again, my deepest apologies. I’m running into those bugs, but worked the last time I did the demo.

>> CELIA: That’s super real. No worries about it.

[laughter]

>> CELIA: Oh man, I used to purpose to to train on a version or two back, just to make sure that it was going to be steady as she goes, but invariably it’ll be an upgrade the night before that’ll throw things off.

>> KIRK: The only reason I had it all set up on the beta server is because it took till 2026 .2.4 for them to work out all the bugs, but they were working on the beta server. Now I have to migrate all that content to a production server, but I also have to figure out if they know about those bugs.

>> CELIA: That’s a good point. Has anybody– If you want to add a reaction to your screen, if you tried to put together a composable data source, I’d be curious to see of the ones who are here in the room. Two, a couple of you. I think that there were some differences you guys were finding between what was possible on desktop versus cloud. There may have been some issues that were bumped into a couple of days ago that I think I heard some rumblings about. Anybody want to surface any of that?

We got a question in the chat. How do you feel about modeling with composable data sources versus pushing it back to the data itself for long term? That’s a good– It should be more of a data architect. What do you think about that? What threshold or criteria would you use?

>> KIRK: I think it depends. Tableau’s got to be working on ingestion of data models properly that have the foreign key/primary key relationships already built. It should be that if you had a typical star schema built in your database, that when you connect to one table, you should be able to have an option where Tableau pulls in the relationships between all those. You don’t have to expose it. Specifically to the question, Blake, I think it’s hard to push it back into the data source completely itself because then what happens is the grain of the data becomes an issue where if–

For example, people push metrics back to their databases a lot. I know data engineering teams love doing that because that’s what they know, but my thing I find I run into all the time when I see that is the metrics are pre-compiled at a level or pre-aggregated to a level that people want to be able to filter lower than, and then you’re completely hosed because you can’t get that.

The idea I like in Tableau, and I’m going to put an asterisk on this because it’s a new feature and I’m not sure what performance is like, and maybe some new bugs have been introduced, I like the idea of publishing fact tables that are clearly fact tables, dim tables that are clearly dim tables, and then aggregate tables that are clearly aggregate tables, and then letting people be able to compose their own data sources that they need now. In order to do that, your creators in Tableau world have to understand data structures pretty well.

Maybe what you do is an in between is you have a subset of creators, or even less creators, not to take away money from Tableau, but less creators who create these composable data sources and then let people be explorers or creators if they want to use Desktop to use those. I like the idea of then you only have to put all the metadata to give semantics, like field descriptions, table descriptions, in ones because you’re only putting it on each table and then you’re putting them together.

Now, anyone who’s used virtual connections in Tableau, that was almost the promise of virtual connections, but they never really finished that feature. It doesn’t work very well. This would almost be like what virtual connections could have done. Do you know what I mean? It allows the data engineering team to embed credentials into tables, and all that extra context into tables, and knowing that that’s going to be safe. It’s a very long-winded way of me saying, I still think it’s a hybrid where I would do some of the stuff in Tableau simply for the flexibility of being able to answer any question they wanted to be able to answer on it. Did that answer the question or–

>> CELIA: Yes. Thank you. I think that in my background, in my world, the thought was you push it back as far upstream as possible for creating fields and try not to let it be workbook bound, for the sake of it being isolated and having to be reproduced over and over and over.

>> KIRK: I agree that you should push it back as far as you can push it. I just think because people want so much flexibility in the level that they want to be able to apply filters and slice and dice, that you can only push it back so far.

>> CELIA: That’s the point.

>> KIRK: I think it’s a Goldilocks thing for sure. Push it back as far as you can, but really think about that. Just quickly, this is a separate presentation, but this is another one I did at TC with Candy; I won’t show the whole thing. What we did in this, just to give you an idea, and this one exactly. I think about in terms of Tableau Prep as well, as a last-mile data prep tool. I don’t think about Tableau Prep as an ETL tool. I know they position it that way. Technically it is, but whatever, which is you’re always trying to trade off, I think, as flexible calculations as you can get with all the filtering, slice and dice, with how long the query takes to run as well.

I had this thing when to use prop and desktop before on the Flerlage twins, like four or five years ago, but now you don’t need to write. I’m happy to share this presentation as well.

Basically what we did, which I think was cool, is we took this use case of saying, say someone has a fictional call center, and they’re tasked with ranking employees by manager by month based on a call resolution rate, but they still want to be able to drill down into call details. What we basically did is you could push this back down to the database for sure, but if you’re not a data engineer yourself, that might be hard to do.

What Tableau Prep is really good at is we took this overly simplified fact table that, say, given to us from the data engineering team, and then we use Tableau Prep to find the first date. We could skip that one, but we basically created a resolution rate, just a simple one or zero that we could add up, then we clean some things up. Basically, I got the number of calls per month, and then I could just sum up that binary zero or one to get the number of by month and then write just a simple calculation.

Then in Tableau Prep, what you could do, which is really nice because you can’t really do this in Tableau Desktop if you expect a query to return in any amount of time. As I say, by every month, a manager ID. I want to rank every employee by resolution rate, and then what we did in the model is we basically because of composable data sources is we took the fact table. This is just the fact table, effectively of every call, and then we took this aggregate table, which you could think of as a metric table.

What that allowed us to do is we could create a viz like this that’s super performant because this is working off an agg table, but when you click on it, we can pass filters in Tableau, of course. These work off the fact table, but it’s still very fast because we know it’s filtered to a manager and a month before it goes to the fact table to return the results we want. I think that’s an example of the thinking.

I said I would consider certifying just tables as published data sources, like fact tables, good kind of metric tables, or aggregate tables, whatever you want to call them, and then dim tables like a standard, like we have one customer, we have one product, and everyone can use those without having going back to the database to get them because we’ve got them certified as data sources in Tableau, and we let people compose their own data sources as we need them. Happy to share a link to that presentation as well.

>> CELIA: That would be great. Yes, please.

>> KIRK: I feel like I have to combine these together. It’s like a lot of different concepts hit in one presentation.

>> CELIA: They all flow together. It’s all part of the conversation for sure.

>> KIRK: Yes.

>> CELIA: Thank you so much, Kirk. Any final questions? Y’all been quiet, but feel free to– I hope this is okay– connect with you on LinkedIn. We will send a follow-up with some of these resources and– Wow, a lot to digest. Thank you so much for sharing.

>> KIRK: Sorry about the bugs. I think they’re on Tableau. If they’re not, I’ll definitely own them. That’s some weird behavior for sure.

>> CELIA: That’s an ideal. One of my friends would say so.

>> KIRK: Alrighty. Thanks.

>> CELIA: Thank you so much, Kirk. I really appreciate it. Thank you for joining us, and we will be back this time next month. I hope you guys will join us. In the meantime, when you get the email, the survey, whatever, please let us know what your what’s top of mind for you and your world, and we’ll be glad to build that into the back half of this year. Okay?

>> KIRK: Thanks and goodbye.

>> CELIA: Thank you very much. See you soon.

>> KIRK: Bye

>> CELIA: Bye-bye.

Presentation Summary

In this DDC event, we explored composable data sources as a practical way to combine published Tableau data sources through relationships. Kirk demoed an existing bookshop model and extended it with ratings, an entitlements table for row-level security, and sales targets.

Throughout the presentation, Kirk connected the demos to broader modeling decisions, including shared dimensions, reusable business definitions, and the role of Tableau Prep. The live walkthrough also included unexpected behavior, giving an opportunity to distinguish the intended modeling approach from results that required further investigation.

Session Outline

  • Moving from standalone published sources to reusable building blocks
  • Extending a bookshop model with ratings
  • Inspecting the tables used by a worksheet
  • Adding row-level security through an entitlements table
  • Bringing monthly targets into a model with daily sales
  • Balancing upstream preparation with analytical flexibility
  • Combining aggregate tables with detailed records
  • Final takeaways

Rethinking Published Data Sources

Kirk Munroe began the presentation with familiar situations: building one large flattened table for a dashboard, placing business logic inside individual workbooks, or duplicating a source because someone needed one additional table. These decisions often helped teams deliver a specific analysis, but made it harder to accommodate the next request without repeating work.

Now, relationships introduced a way to retain tables at their natural grain, or level of detail. Shared dimensions expanded this approach by allowing multiple fact tables to connect through common dimensions, such as customer or product. Composable data sources extend the same thinking to published assets.

The central shift is to treat published data sources as building blocks. A source can remain useful for its original purpose while also contributing to a larger model. This creates an opportunity to reuse existing work as analytical needs expand.

We have several possible approaches.

  • Teams might publish individual tables for others to assemble,
  • Extend existing sources containing several tables, or
  • Maintain shared dimensions for use across different business areas.

The appropriate structure depends on the questions being asked and the people responsible for building the models.

Extending the Bookshop Model with Ratings

The first demo began with a published bookshop data source. It contained four quarters of sales data unioned together, along with information about editions, publishers, books, and authors. Kirk used this model to create a view of monthly sales by book genre.

He then introduced a follow-up question: Do books with higher ratings also have higher sales? The existing model did not contain ratings, so answering the question required additional data.

Using Add Published Data Source, Kirk brought an existing ratings source into the workbook and related it to the book table through Book ID. The resulting model combined published sources within the workbook, allowing him to extend the analysis without creating another published copy of the entire bookshop model.

With ratings available, Kirk created a scatterplot comparing sales with average ratings at the book level. A trend line showed a positive relationship in the sample, although he noted the limited data and its fictional nature. The example illustrated how quickly a new analytical question could become a view once the relevant source was added.

Reviewing Which Tables a Worksheet Uses

Adding ratings also provided an opportunity to examine how relationships affected the original sales worksheet. Kirk opened View Data Model and showed which tables were involved in the view.

The existing worksheet did not use ratings, so the newly related table was not needed for its analysis. This helped explain why the sales view continued working after the model was extended.

Inspecting the tables used by a worksheet makes the relationship between the model and the visualization more visible. It provides useful context when evaluating how an additional source participates in an analysis or investigating unexpected results.

Adding Row-Level Security

The next scenario introduced a different requirement: some users should only see particular book genres. Kirk used an entitlements table associating users with the genres they were permitted to view, then incorporated it into the model through the genre field.

He created a Boolean calculation comparing the Name field in the entitlements table with USERNAME(). Filtering this calculation to True limited the results to the entries associated with the signed-in user.

Kirk emphasized the filter’s scope. The security filter needed to apply to all related tables, so the entitlement rules affected the book data used in the analysis. Filtering only the security table would not accomplish the intended result.

Once the filter was applied, the sales view changed from eight genre lines to four. This showed how the added entitlement information could restrict the existing analysis without rebuilding the original bookshop source.

Working Through the Live Connection Issue

The security example was intended to use a live connection to a Google Drive sheet alongside extracted data. During the demo, Kirk encountered an error when adding the live security source and was able to continue after converting it to an extract.

This changed how updates to the entitlement information would reach the view. Kirk explained how the live version had behaved in previous demos, then initiated an extract refresh after removing one of his genre permissions. The additional reduction in visible genres was not confirmed during the session.

Kirk noted he was working on a beta server and planned to investigate the unexpected behavior. The cause remained unresolved, so the walkthrough showed the security-filtering approach while leaving the live connection and refresh behavior open for follow-up.

Bringing Monthly Targets into the Model

Kirk’s next example introduced sales targets supplied in an Excel file. Before incorporating them into the model, he pivoted the month columns into rows, producing fields for month and sales target.

He then published the prepared target data as a separate source. This step reflected an important part of the workflow: the composable model was assembled from published data sources, so the spreadsheet first needed to become one of those reusable components.

To connect sales and targets, Kirk introduced a shared date table. Sales contained daily dates, while targets were defined at the month level. He related sales to the date table and used a relationship calculation based on the month name for the target data.

The intended analysis compared sales and targets by month while preserving their different levels of detail. Monthly targets could support a monthly comparison, but the source did not provide daily target values.

The resulting view displayed unexpected totals, which Kirk investigated but did not resolve during the presentation. The example introduced shared dimensions and different data grains, while also showing why the resulting values must be checked before the analysis is considered complete.

Keeping Business Definitions Reusable

Beyond the individual demos, Kirk returned to the importance of consistent business definitions. A measure such as net revenue should have an agreed meaning within an organization, and rebuilding its logic across workbooks creates more places to maintain it.

Composable data sources offer a way to organize reusable logic and descriptive metadata within the underlying published assets. Field descriptions, table descriptions, and aliases can be established in those sources as part of a more consistent foundation for analysis.

Kirk also connected this work to AI-assisted access to data. He described reusable semantic context as increasingly important when published sources are made available to agents. The modeling and documentation work remains an essential responsibility for the people preparing those sources, including defining measures and maintaining appropriate access rules.

Deciding What Belongs Upstream

How composable modeling compares with moving the work back into the underlying database, you may ask? I shared my preference for pushing reusable field logic as far upstream as practical, reducing the need to reproduce it in individual workbooks.

Kirk agreed with the principle and explained where the tradeoff appears. When metrics are pre-aggregated, users may lose the ability to filter or investigate below the stored level of detail. A calculation prepared for one reporting need may therefore limit a later question.

His preferred approach was a hybrid model, balancing upstream preparation with the flexibility available in Tableau. He also emphasized the knowledge required to compose sources responsibly: the people doing this work need to understand data structures and how the components relate.

For some teams, this could mean having a smaller group of experienced creators assemble models for broader use. Reusable sources create more options, while informed modeling decisions remain central to their value.

Combining Summary Performance with Detailed Exploration

To illustrate this balance, Kirk shared a separate call center example. The requirement was to rank employees by manager and month using call resolution rates, while retaining access to individual call records.

Tableau Prep was used to prepare monthly results and employee rankings. The model then combined an aggregate table supporting the summary analysis with a fact table containing the detailed calls.

The summary visualization used the prepared aggregate data. When a user selected a result, filters for the relevant manager and month could be passed to the detailed view, narrowing the records requested from the fact table.

This example showed how prepared summaries and detailed records can serve different needs within the same analytical experience. Kirk described Tableau Prep as a useful tool for this final stage of preparation, helping balance calculation flexibility with query performance.

Final Takeaways

Composable data sources invite a broader view of what a published Tableau source can become. By extending reusable assets through relationships, teams can add context to existing analysis and reduce the need to duplicate entire models whenever a new question appears.

The session also reinforced the importance of data grain, shared definitions, filter scope, and validation. Watch the full session to follow Kirk’s modeling approach, see the live troubleshooting, and consider how your own published sources could support a more flexible analytical foundation.

Picture of Celia Fryar

Celia Fryar

Celia is a Training and Enablement Lead at XeoMatrix. A Data educator and strategist with over 20 years of industry experience, Celia is dedicated to turning analytics into action and opportunity. She's also an Adjunct Professor at the University of San Francisco.

Latest Blog Posts

Tableau+: Decoded

What is Tableau+? Explore how Tableau Agent, Pulse, Cloud, and Tableau Next support conversational analytics, governance, and trusted insights.

Upcoming Events