Skip navigation

Dynamic parameters

score 2277
You have not voted. In Review

This idea is currently being reviewed.

 

As the result of some further investigation, the idea has been broken up into 5 different scenarios as listed below. These scenarios have ideas associated with them and we encourage you to vote for the one(s) that apply most closely to your situation.

 

  1. Cross Data Source Filtering - "I want to use one filter to filter different data sources."

    This is feature of the idea is now in Beta! For more information see: As Requested, You Can Filter across Data Sources in Tableau 10  | Tableau Software

  2. Highlighting and Comparison - "I want a great experience for finding and highlighting members in a view for comparison that doesn't require placing a field on color, or using a table connected to another view via actions. I want dedicated objects (much like quick filters) that will highlight qualifying data versus filtering it."
  3. Default Values for Filters - "I want to be able set the default date for a filter based on the most recent date in my data or set a custom range of dates."
  4. Default Values for Parameters - "I want to be able set the default date for a parameter based on the most recent date in my data or set a custom range of dates."
  5. Using Parameter Values in More Places - "I need to be able to use parameters in a number of different places. For example, setting boundaries for stepped color ranges, in axis titles, and for determining the min and max values on an axis."

This conversation is also being continued with our PM team here: Dynamic Parameters Update

 

 

Parameters are really useful when you need to do something too complex to be handled by quick filters or action filters. However parameters are currently hobbled by the fact they have to be static lists.

 

It would be really, really useful and solve a lot of Tableau gotchas, if you could define the options available for a parameter dynamically, from the result of a datasource, and preferably with the option to apply filters also.

 

Currently the closest you can get to this is to create a view from a datasource, put it in a dashboard, and put an action filter on it. However action filters on a view are a poor substitute for a form element, and can't be referred to in calculations, and don't retain their state between dashboards. Quick filters can be used in some situations, but they can be very slow to calculate if you have a large dataset, and again they can't be referenced in calculations.

 

UPDATE: I thought I'd add some examples of the kinds of gotchas I think can be resolved with this feature:

 

  • It could be used to filter across multiple datasources that share a dimension, without having to join those sources (joining can be a performance nightmare and in many cases leads to duplication of data which causes further difficulties).
  • It could be used to create dashboard level filters as asked for in the most popular idea: http://community.tableausoftware.com/ideas/1035
  • It could be used to do performance optimisation of complex queries. We have many cases where we can get our particular DB to perform better using particular rawsql tricks, however within rawsql you can only use the values of parameters, which currently limits their usefulness.
  • It could be used for filtering based on subqueries, since the parameters can be injected into the subqueries. This opens up the possibility of doing complicated filters that are not directly possible through Tableau.
  • Will add more as I come across them!...

 

UPDATE2:

 

  • Commenter Scott Woffenden raises a really good point that these could then be injected into stored procedures also, which opens up a whole world of possibilities. Tableau's requirement for a datasource to be a single query or view raises lots of difficulties when it comes to optimising queries on big databases. Stored procs allow you to do all sorts of cool stuff, one way this would help us is in allowing us to create multi-step queries eg create a temp table of some kind that is then reused and so on. You often find yourself doing these sorts of things when you are trying to work around the particular quirks of a databases query planner.

Comments