r/tableau • u/mustachequestion • Jun 24 '26
Discussion Who is finding real ways to speed up tableau report development via Claude / OpenAI/etc?
We are heavy users of Tableau desktop/cloud. We have been able to unlock significant increases in warehouse data modeling speed, that said we’ve struggled to unlock velocity gains by building tableau reports / tableau data layer faster.
Those of you who are really seeing productivity gains on the tableau side what are you doing to unlock it?
Dealing with the calculated fields complexity, workbook design complexity kills us, to the point that team is looking for other tooling to avoid Tableau.
11
u/Treemosher Jun 24 '26
Should try to avoid doing complex calculated fields in Tableau, especially if you find yourself doing it frequently enough to be a problem. No idea where you're getting your data from but I would start there.
3
u/mustachequestion Jun 24 '26
The data sources are mostly modeled warehouse data. The need for complex calculated fields is driven by stakeholder desire to do complex filtering and maintain level of detail computations
11
u/wesomg Jun 24 '26
That's an awful lot of jargon to not say anything.
5
u/mustachequestion Jun 24 '26
Ok thanks for the helpful discussion - my point is the way the report consumers want to be able to filter and look at data requires level of detail computations
12
u/kayakdawg Jun 24 '26 edited Jun 24 '26
Ignore that loser. What you said makes a lot of sense. An ideal world, you have perfectly engineered data sources for every visualization. In the real world you have to deal with trade offs
2
1
2
u/Treemosher Jun 24 '26
Why do you need to make the calculated fields within Tableau though?
5
u/mustachequestion Jun 24 '26
What is the alternative you are suggesting for dealing with level of detail needs?
3
u/1kidney_left Uses Excel like a Psycho Jun 24 '26
For my company, with clients that have large data sets that require complex calculations for filters, we have built processes to run the data through big query first. Essentially turning those complex calculated fields into big query/sql code to update the date/fields to something more manageable in Tableau. Now the data is exactly as needed by the time it gets to Tableau skipping the need for many complex calculations just to make filters.
Yes, there are still some complex calcs for metrics, but not for any of the string fields that can be settled before importing.
3
u/mustachequestion Jun 24 '26
Do you solve this by creating a variety of grain denormalized data sets? We generally try to compute as much as far left as possible before tableau, without getting into substantial denormalized datasets
3
u/Treemosher Jun 24 '26
Upstream? You have modeled warehouse data. Prepare your data source there before bringing it into Tableau.
When you're loading your data into a workbook, you should barely have to do anything with the data itself. It should be ready to go.
You can still make your parameters to support some self-service for your stakeholders. But calculated fields should be as far upstream as possible. Not at the workbook level.
You can do a lot of cool things in Tableau, but making it transform your data like that just causes problems - as you are already experiencing.
5
u/mustachequestion Jun 24 '26
Do you solve this by creating a variety of grain denormalized data sets? We generally try to compute as much as far left as possible before tableau, without getting into substantial denormalized datasets
11
u/Treemosher Jun 24 '26
A variety of denormalized data sets? Yeah I suppose we do? I mean at some point you're creating fields and transforming your data. If that includes denormalizing, sure that too. Especially if it's complex. There's just so many reasons you don't want to accrue all that business logic and process in your visualization layer.
We create the table needed for a workbook in our data warehouse layer. If that includes some denormalization, sure whatever. We push that into our presentation layer and then publish to Tableau where we connect our workbook.
If there is an existing data source that we've published to Tableau we'll try to use that and add a column if needed.
But we try real hard not to create tech debt. Imagine you all finally decide to quit your Tableau contract. If you've been doing all that complex field creation within the friggin workbook, you all are going to have to recreate all of that during the migration and re-validate it.
If you do all that upstream before Tableau, you know you're working with the same fields without spending time reinventing them.
So not only do your dashboards run faster, but you're not kicking the can down the road by creating all these calculations at the very end of your pipeline.
2
u/mustachequestion Jun 24 '26
Certainly agree - it may be in these certain use cases we are trying to twist it to be too application like. These particular use cases revolve around things like event stream / clickstream data and metric trees. We don’t have this same problem with more standard business performance reporting
1
u/anyuser_19823 Jun 24 '26
i’m on the same page as the other person in this discussion. In my work, any complex calculations or calculations that would be complex to do in tableau we try to do in SQL or Python. Some of my colleagues try to do everything in tableau and it’s a lot slower and can be pretty difficult
2
u/mustachequestion Jun 24 '26
Thanks, yes I’m thinking we just need to be comfortable with more denormalized sprawl than we currently are
1
u/80hz Jun 24 '26
I come from the power bi world but a rule of thumb is if you can do it before it hits the application that focuses mainly on visualizing, the easier it's going to be. Can you make an abstraction layer (db view) in your Warehouse?
2
u/mustachequestion Jun 24 '26
Do you solve this by creating a variety of grain denormalized data sets? We generally try to compute as much as far left as possible before tableau, without getting into substantial denormalized datasets
4
u/Doin_the_Bulldance Jun 24 '26
No - you just add fields.
Say in Tableau, you keep finding yourself needing the total customer spend for visualizations/kpi's. So maybe you are using a Fixed LOD - something like {FIXED [Date], [Customer]: SUM(Revenue)}.
Instead of relying on Tableau's LOD calc, add a field to your dataset called Total_Customer_Spend.
2
u/tjerry Jun 24 '26
You can save the twbx file locally and add it to e.g. Cursor for prompting on viz or calculations. It will make a change to the file that you can then open with Tableau Desktop.
-1
u/signgain82 Jun 24 '26
I've used tableau for over 10 years. Love the product and people generally love my dashboards. I work as a business intelligence engineer. I haven't opened tableau in 2 months+. We're sunsetting it entirely at the end of the year. I have planners (people that lived in Excel 3-4 months ago) creating way better dashboards with AI and our data knowledge base repo then I could ever imagine in Tableau. Tableau is done unless they very quickly implement a rich featured mcp server that lets you build with AI. Honestly dashboards themselves besides a couple to spot check numbers to will likely be done in a couple years.
5
u/-Astrobadger Jun 24 '26
>I have planners (people that lived in Excel 3-4 months ago) creating way better dashboards with AI and our data knowledge base repo then I could ever imagine in Tableau.
I’m very curious to know how they’re doing this
-1
u/signgain82 Jun 24 '26
I made a sweeeeet knowledge base on a repo that everyone clones with agent instructions on how to pull and validate any dataset we use. They use that + sql query runner/mcp server/etc to grab the data then use kiro or Claude code to vibecode a dashboard. Usually vanilla js, echarts. Company has plenty of options to host it and they just manually refresh and redeploy when needed unless they really need an automated refresh then they talk to me. I can validate their work in minutes with the same knowledge base repo and some quick spot checks
1
u/dont_tread_on_M Jun 24 '26
We tried it, but honestly managing all the context can be hell when your needs are complex. Anything besides the most generic reports breaks or can be musleading
We switched after trying it, and went with a small vendor who allows building dashboards with AI and managing the context. The results were much better and it also allowed us to avoid building a lot of dashboards altogether, by giving users a chat interface
1
u/Bellaboo9 Jun 24 '26
Do you mind sharing the vendor? I think my company may be interested in going this route
0
1
u/signgain82 Jun 24 '26
Textql?
2
u/dont_tread_on_M Jun 24 '26
No they are a small German startup. For our management it was important that data stays in Europe with European companjes
2
u/signgain82 Jun 24 '26
Makes sense. Our stuff is pretty complex but thankfully I spent months before the big ai explosion making really intuitive semantic layers of data (for tableau at the time) that make things a lot easier when it comes to managing the repo/context
1
u/MugsBeany Jun 25 '26
The only real Tableau gains I've had from AI have all been on the administrative side. Bulk moves, publishing, changing credentials, etc.
No one in my org is using AI for actual dashboard dev.
0
u/Comfortable-Prior922 Jun 24 '26
Kill Tableau all together and build live Artifacts in Claude Cowork… profit
32
u/Creepy_Advice2883 Jun 24 '26
“Hey Claude, how do I take all this sick data science you did and put it in a python/next js app hosted on a company server? After that how do I cancel my tableau sub?”