I've been using Tableau for a while now, and am an avid member in the community. I've experienced a lot of personal pain with static parameters, and have shared this pain with others in the community. I can guarantee that the sentence "If only we had dynamic parameters" comes up at least once a day. We are obsessed with Dynamic Parameters. But are Dynamic Parameters what we actually need? I think No.

Back in March, Tableau published a survey they did on Dynamic Parameters and the biggest uses cases people have for them. Though they missed a big one (Dynamically updating Parameters), it still gave some scope as to why people are asking for it.

"Is there a one stop shop (or feature) for Dynamic Parameters? No, probably not, though there did seem to be a recurring theme centered on filtering, highlighting and comparison needs."

The answers to "Why hasn't Tableau developed Dynamic Parameters?" was here all along. Simply, Dynamic Parameters don't actually solve our issues. It's a hacky work around to bigger problems. I "think" Tableau understands this, and instead of taking the easy way out (Developing Dynamic Parameters), they decided to develop features that solve the core problems.

I realized this the other day when I was re-watching the Devs on Stage Keynote from TCC15. There were three key features demonstrated that directly relates to some of the main problems we have (And wish to solve using Parameters).

1. Cross Database Filtering

2. Cross Datasource Joins

3. Data Highlighter (The ability to highlight items without the need for a Parameter)

After I re-watched this, I just sat there, astounded and humbled. Rather than going down the slippery slope of adding every feature we ask for, Tableau stopped to think about what we were "really" asking for, and started to develop those features. I couldn't help but relate this Data Visualization. If we just simply gave our stakeholders the viz they asked for, nothing would every get done. It's our job as analysts to figure what they are "really" asking for, and develop visualizations accordingly.

Now, I'm sure there are still plenty of use-cases for having Dynamic Parameters, and I'm not saying we shouldn't still ask for it, all I am saying is that we need to think about the bigger picture.

Thanks for your thoughts on Dynamic parameter. We are eagerly waiting for this feature. Today I saw a post in our forum regarding the Dynamic parameter . Mr. Ali found some workaround and soon he will be sharing his methods/techniques

I have mixed feelings. On the one had - yes! Tableau does an outstanding job of not just developing the "requested feature of the week" with no thought behind the implications. This kind of discipline is rare in software development and I am very happy to see it because it means the software doesn't bloat into a bunch of features that don't work well with each other. And it also keeps things simple for the users. They don't have to be programmers to use the data highlighter or developers to use cross-data source filters.

And yes, the new features demoed will solve a large portion of the pain-points and use-cases. And I'm all for the features that were introduced. But...

...why not dynamic parameters in addition? The issue isn't so much: do they solve certain use cases? The issue is: do they open up new possibilities without harming the integrity of the tool or the user experience? And I believe the answer is a resounding, "YES!"

Take an example or two:

Floating objects on a dashboard. This new feature has allowed for all kinds of unique and creative dashboards that weren't possible beforehand . The feature opened up all kinds of possibilities. But imagine if Tableau had said, "we identified a use case of using blank space in a map for a legend -- so we give you the 'map-legend' feature." Yeah, it solves one use case, but there's no room for the creative freedom that floating objects give.

Table Calculations. What if Tableau had said, "we believe there are use cases for running totals and window sums -- so you've got a new menu option to turn those on -- but a new set of functions would be too complex for users and introduces too many possibilities for users to mis-use." Think of all the unforeseen solutions and creativity that would have been lost. And, yes there are ways to mess it up and there are new ways to solve some of the problems that are much simpler than the way it had to be done before (LOD calcs rock!) but that doesn't diminish the fact that a whole world of possibilities was made available with this feature.

I think dynamic parameters are much the same. They are an overarching feature that opens a world of creative possibilities. Can they be mis-used? Yes, but so can any other feature. Are there better ways of handling some use cases? Yes! And thank you, developers, for the data highlighter and cross-data source filters! They will make life (in those use-cases) so much easier than even dynamic parameters would have.

But, dynamic parameters would open up entirely new possibilities and paradigms of design and use that no one has even dreamed of yet. And those are the kind of features that make a new version what one would describe as a "game-changer".

I couldn't agree with you more! (My title is a little miss-leading, but I wanted to draw people's attention....so I figured this angle would work).

I certainly think we should still ask for Dynamic Parameters, for all the same reasons you have descried. There is no telling what doors it could open, or what we (Tableau users) could do with it.

This goes back to what I was saying before

"Now, I'm sure there are still plenty of use-cases for having Dynamic Parameters, and I'm not saying we shouldn't still ask for it, all I am saying is that we need to think about the bigger picture."

Really, all I wanted to point out was that Tableau does a great job at identifying use cases, and designing features accordingly, as opposed to developing the "requested feature of the week". Though Dynamic Parameter would be awesome......what I really want are features that solve my core problems first. (Like a more robust Tableau Query language...Analytic in nature)

I can't wait for the day we have Dynamic Parameters.........but I am willing to wait if it means I get Cross Database Filtering, Cross Datasource Joins and Data Highlighting first.

I guess it would be quite easy for Tableau to build dynamic parameters that will fill requirements which are set by a single user. But in real world one Zen Master wants to have this feature and second ZM suggests that Tableau should also add this one. And at the same time there are 50 other users which have different opinions how dynamic parameters should work.

I have also requested dynamic parameters, but still think that in many cases actions are enough. When you decide to select value from parameter, then you probably know the answer already. But if you build visualizations and explore data with help of those, you might find some new stuff.

I just hope that Tableau add some new features which allow users to develop something new. Many problems can be solved if Tableau doesn't put too heavy restrictions. Eg. couple years ago I thought it wasn't possible to have multiple geographic role drill-downs in a single filled map, but with help of Richard Leeke's map tools, that wasn't too hard to achieve.

...Pre-Tableau I used a, little known, Viz tool which will remain nameless!! When I first used it, 8-9 years ago was very good (for its time). However they would add features, on request, willy-nilly. Initially this was fine. We had a network chart type, which would link to FB and give you some cool views, want Line/Bar mixed chart, 'we have a button for that'!...etc.

Last year I had do go and train this software to a customer who had recently bought a copy (we are still, in theory, official trainers). I hadn't used it for a year or 2, so was quite looking forward to having a bit of 'reminisce' of my old friend!!...It had become almost unusable (& even harder to train!), it had so many options (a button for line/bar [one for lines on Axis 1, and another for Bars on Axis one], another for line/circle, another to turn pie's into donut...etc). Basically each of the, now 20, chart types was like a separate piece if software, nothing was in the same place (even the chart formatting was in different drop-downs depending what chart-type you were in). It's very hard to maintain consistency/vision with so many bespoke options...and despite these 100s of options, you were actually very restricted in what you could do. Due to the amount of 'bespoke' options, the software had to take control, and so many of the charts were (semi) pre-formatted (which was great for the requester, for that problem, but useless for anyone else...

Their aim; to create a 'layman' viz tool, where you'd click an option to get they chart you want.

The result; an inconsistent, restrictive tool that you'd need an encyclopedic memory to use.

So I'd always say 'be careful what you wish for'!...solving 'today's' problem, might lead to whole lot more pain 'tomorrow'!

One of my favorite things about Tableau is their hesitance in complicating the software unnecessarily, a point very well articulated by Joshua and illustrated by the fact this article,

LoDs are a brilliant example of this...something like this has been requested for ages, and they could have put in a quick fix...but no they thought it through (realizing it was not a calculation issue, per-se, but a VizLoD issue), and we now have some of the most adaptable/flexible features I've ever come-across. The full potential of which we are still unpicking!! Ville also makes a great point on the data-exploration element that actions encourage.

The Cross-Database Join, and Cross-Datasource filtering, and highlighting were 90% of my use-case for dynamic parameters...again, Tableau have got to the 'heart' of the problem, and not just added a 'requested' feature. I also think the 'Tableau Great & Good' will find novel ways of using these features in imaginative ways (which may solve even more of the (perceived) 'dynamic parameter' use-cases). Look at how Rody has cleverly shown how LoDs solve the 'Relative Date Filter indexed from Last Day of Data' http://community.tableau.com/docs/DOC-8399

- Tableau could have added an extra option, but as my above 'rant' (aims to!) demonstrate you only want to add in 'options' (i.e. extra things to remember) where there is no other way, and not at the expense of the 'guiding vision'

Joshua does raise a great point on the 'unknown unknowns'!...which I hadn't really considered before.

In short...I'm quite happy with the new features, which will solve a vast majority of the need for dynamic-parameters (as well as the, as yet, 'unknown' things we might create with them). However if implemented with consistency/thought (the Tableau way!), it would be a welcome addition to our arsenal. For me the key is that 'dynamic parameters' add something new, and not just create 'hackey' ways to do things that could be done, better, with the existing features or to do things Tableau was never designed to do.

Need them or not, I'm fairly certain that whatever comes out of Tableau will NOT be called 'Dynamic Parameters', as there are simply too many definitions (expectations) for what that term means. We will certainly get some of the implied functionalities, in dribs and drabs over the next few years, but never will the 'Dynamic Parameters' feature request ever be marked 'Released'.

You wrote: "But are Dynamic Parameters what we actually need? I think No."

I think that argument is disingenous and you go on to contradict yourself by pointing out that "dynamic parameters" means different things to different people, and that we *do* have real-world use case for what those things are. I think a more honest statement would be "Do users have a need for the things they call 'dynamic parameters'? Yes. Does the feature have to look like a self-updating list of values in order to meet those needs? No, not in all situations."

In terms of knocking off the most commonly requested use cases, yes, Tableau is totally doing that with developing cross data source filtering and the new data highlighter. I had a brief conversation with Andrew BeersID at the conference and he passed on it was upwards of 60+% of the identified need out there based on Tableau's research. As a bit of a process control aficionado this is fantastic that Tableau is knocking off the top items on the dynamic parameters Pareto chart.

As forum answerers, I believe what we need to do when someone says "I want dynamic parameters" is to be more like Tableau and dive into the next level of the question to find out what their situation is really like and stay away from blanket statements that are too broad and too easily misinterpreted.

My "argument" wasn't meant to be disingenious. I was "attempting" to point out that "I think" the biggest use cases for Dynamic Parameters shouldn't be resolved with Dynamic Parameters (like cross database filtering).

Looking at it now, I could have worded things differently. But it got the conversation going. I've already learned a lot from this thread, and I hope others learn something too.

Tableau has gotten the message on the first one and seems to be busy addressing that functionality. On the other hand, they don't seem to have gotten the message on the second one (in my opinion, and to the best of my understanding), and are NOT working on introducing this sort of option.

In my opinion, if Tableau would just do #2 (and also allow Multi-Select parameters) we would quickly reach what Joshua Milligan describes here:

But, dynamic parameters would open up entirely new possibilities and paradigms of design and use that no one has even dreamed of yet. And those are the kind of features that make a new version what one would describe as a "game-changer".

When Tableau considers a new feature, the first basic question they ask is:

"What will this feature allow us to do that we can't do now?"

This is a perfectly legitimate question, and a way of determining development direction. Unfortunately, this limits development to only things that have a 'concrete', easily explained, 'Use Case'. However, this does not allow for the type of thing Joshua is talking about:

"Things not yet dreamed of."

Tableau innovates; that's what they do. Tableau gave us many, as yet dreamt of possibilities in the data visualization space of the past. Tableau knows that when chasing innovation, sometimes you just have to trust your gut (or your users guts). In this case, there are a whole lot of Tableau users saying:

I wonder what the 'biggest use case' for Dynamic Parameters really is.

I agree dynamic parameters as described by Joshua and others would be great, but think default values in quick filters (and parameters) was what a great share of voters had in mind when up-voting Dynamic parameters because it is an issue almost every dashboard consumer meets as soon as a dashboard is a month old or so.

Evidence: Following ideas went from relative anonymity to fame in a short time (with the help of active promotion) and have since been permanent members of the top 15 active ideas dashboard:

I think either a) default values or b) cross data source filtering is the biggest use case for dynamic parameters closely followed by c) multi-select parameters which by the way is mostly about cross data source filtering.

Sorry kettan, I did a bit (lot) of editing on my original post that you responded to; trying to sharpen my point. So that quote of mine that you posted, got eliminated. But I did post it. And I stand by it, and do still wonder what really is the biggest use case.

This was an attempt at doing something without the use of parameters. The original brief was easily done with parameters, but internally we have designed a number of views/databases that match the sites on the server. The original idea was to use parameters and then switch databases and the parameters would update as it would be using the same field.

I tried to find a solution to the best of my abilities and then I spoke to a senior consultant at interworks who couldn't move it any further. In the end I spoke to the project manager and requested a change on the brief as I couldn't deliver what they were asking for. If dynamic parameters were available this would have been easy to do.

At the end of 2014 Tableau had 26000 customers in over 100 countries and it would be impossible for them to know exactly the use case of tableau in each one of those customers. If a large part of the community and a respected part (zen masters etc..) is asking for a feature shouldn't Tableau try and answer this? It's not like exploding pie charts where there's no business case behind it.

I responded on your linked-to thread with a couple of options that I think could meet your initial requirements.

Where this connects to this thread is that there are multiple mental models (paradigm) that people come to Tableau with, here are three:

- "cell-based" that comes from VisiCalc and its descendants, most notably Excel. We effectively operate on one cell at a time and can chain results together.

- "variable-based" that comes from programming. In this model variables are defined and operated over so an operation could be something like "get the value of parameter Alpha, compare it to record 1, if it matches then return X, then compare to record 2, and so on". Writing database application code using cursors is using this paradigm.

- "set-based" that comes from databases. This is where operations are performed "at once" across sets of records, like SUM([Sales]).

I regularly run into situations helping other users where they are using cell-based or variable-based thinking and user-controllable parameter values are *completely appropriate* to those paradigms. The challenge is that Tableau is a database-backed application so it uses a set-based paradigm. When we switch our mental models to correspond to how Tableau works (part of what my friend Joe Mako calls "Flowing with Tableau") then problems that seem challenging to solve in Tableau become a lot easier.

When it comes to the topic of dynamic parameters is that Tableau (the company) is naturally going to work from Tableau (the software)'s paradigms and that means coming from a set-based model. Features like cross-database filtering and the data highlighter demoed at TC15 totally fit with that *and* they solve the needs of a bunch of users.

So I see two challenges for Tableau:

1) That there are problems such as modeling & forecasting situations that are much more "procedural" in their operation and fit the cell-based/variable-based paradigms where users really do need a refreshable value list to do what we need to in Tableau.***

2) Better communicating how Tableau is different, i.e. that although Tableau may be able to generate a similar graph to what we see coming out of Excel, the way Tableau gets there is different. (This has been the topic of my personal research and writing for awhile now and posts like this are in some ways me thinking out loud).

*** There's another use case where I want a "filter" which which "All" gives me everything and has a list of other values that are a subset of the range of values of a given field. In my case I've got a dashboard with a "Choose Unit" parameter where All shows results across both hospitals in our system, then there are options for each hospital, and finally a set of options for the hospital units that we've turned on reporting for in the dashboard. So the All and hospital-level options include in their results values for units that are not selectable. Every time we turn on another unit for reporting in the dashboard (or add a hospital) I've got to go in an edit the parameter, I'd really like to make that a refreshable set of values and it doesn't seem to be something that would easily fit into what Tableau today calls a filter unless Tableau had a better sense of hierarchies.

*** There's another use case where I want a "filter" which which "All" gives me everything and has a list of other values that are a subset of the range of values of a given field. In my case I've got a dashboard with a "Choose Unit" parameter where All shows results across both hospitals in our system, then there are options for each hospital, and finally a set of options for the hospital units that we've turned on reporting for in the dashboard. So the All and hospital-level options include in their results values for units that are not selectable. Every time we turn on another unit for reporting in the dashboard (or add a hospital) I've got to go in an edit the parameter, I'd really like to make that a refreshable set of values and it doesn't seem to be something that would easily fit into what Tableau today calls a filter unless Tableau had a better sense of hierarchies.

I think this particular scenario wouldn't be covered by the cross-data filtering and highlighting, if I am not mistaken, and seems to be a common request with regards to dynamic parameters. (I also think it was one of items mentioned in the survey that went around a while back) In this case, at least for me in a similar vein, it is about reducing overhead when needing to update for new values. While it's not a work-stoppage/earth shattering scenario, it certainly would be helpful to not have to think about having to update parameter values in my dashboards on a monthly basis.

As an aside, the one thing I always liked about the way new features are rolled out in Tableau, at least in the incremental releases, is how it covers a lot of those "little things" that go a long way. I think Tableau is addressing a lot of the functionality that falls under the umbrella of "dynamic parameters" in such a way.