Another option is to duplicate your data source, and use one data source for worksheets on each dashboard, then your global filters will effectively be dashboard local filters.
Additionally, when dealing with Extract, instead of duplicating, create a new Tableau Data Engine connection that connects to the .tde file. This way you are not creating an additional copy of the .tde file, but just a connection to the Extract. Also, you only need to refresh the main extract.
There's also The specified item was not found. that I've used.
I thought about the duplicate data source option, but I don't want to increase the size of my workbook file. So working within the same data source is, I believe, the best way of achieving the result without adding any size. Would the new TDE connection require the same data to get imported/saved in the packaged workbook? I'm guessing it would.
I agree with your concern that simply right-clicking on an extract data source and selecting duplicate, causes an another .tde file to be created, doubling the size of a packaged workbook, and making it so there are two extracts to update.
The way to prevent that from happening is to instead do the following:
1. from the main menu, Data->Connect To Data
2. select Tableau Data Engine
3. browse to and select the .tde created earlier (if you are dealing with a packaged workbook, you will want to unpackage the workbook first and deal with the .twb)
You now have another connection to the same extract without the increase in size, and only one extract to perform a refresh on.
In fact, when you select Tableau Data Engine as your connection type, you are not able to preform a Data->Extract->Refresh Extract, that operation can only be done on the the original connection made and where the extract was performed.
Does that make more sense?
Side note: There are other times where I really do want another .tde file created (not losing ability to refresh separably, or different optimized calculations). So you have two routes to effectively duplicate a data connection, one that creates a copy of the .tde file and another that is a another connection to the .tde file.
That is a useful trick Joe.
It used to be that duplicating the connection just gave you a second reference to the same underlying TDE file - in fact I wrote an article at one stage which relied on that. But that did lead to quite a bit of potential confusion with adding extra calculated fields to one copy or the other and then optimising - so I think the change that came in a while back to make it duplicate the TDE was probably the best approach. Especially now you've pointed out the option of connecting back to the same TDE file - I hadn't thought of that.
Interesting point, Joe.
Is it me or does connecting to a TDE lead to odd behaviour? Here's something I just did to play around with this.
1. Connect to Superstore sales, create an unfiltered extract
2. Create a new TDE connection, connecting to that extract
3. Add a calc. field to the original connection. That field is not available in the duplicated connection, even after refreshing the extract and the duplicated connection
4. Create another TDE connection to the original extract (remember, this one now has a calc. field)
5. My new TDE connection has the calculated field.
6. Delete the calc field from the original connection.
7. Refresh everything. The calc. field is still in the second TDE connection.
So where is everything being stored? This behaviour, I'm sure, makes perfect sense logically, but it seems a little too unpredictable for me to be comfortable connecting to an extract.
Yes, this is a bit tricky.
I think the point is that the new connection created by connecting directly to the TDE initially derives it's list of fields from the extract - but that is a snapshot of the state of that extract at the time of creating the connection.
If you subsequently add more calculated fields to the original connection and then either optimise or refresh the extract of that connection, those fields may or may not become available to the connection you made directly to the TDE by selecting Data->Refresh. Whether or not they do seems to depend on the nature of the calculated field.
Some calculated fields are evaluated and stored as derived columns within the extract (these are referred to as "materialised calculated fields"). I'm not 100% sure of the rules for what is and isn't materialised - I think dimensions generally are - unless the calculation depends on a parameter, measures generally aren't. The key phrase there was "I think"! The easiest way to tell is to create a calculation and then optimise the extract. It will say something like "Removed 0 unused and optimized 1 new calculations" if it materialises it - or "0 new calculations" if it didn't.
It seems that refreshing the connection to the TDE after adding new calculated fields does pick up new materialised calculated fields, but not new calculated fields that have not been materialised.
Note that this is all by experimentation - I may not have got the whole picture.
That approach definitely makes sense (and works). The only issue with this approach, though, is that it creates distinct data sets vs. allowing me the flexibility of having three levels of filter. For example, I may have 3 fields that I want to use as global filters on all of my views, but then I'll have 2 fields that I only want to act as global filters on a single dashboard tab, and then of course there will be fields that I want to use as local filters. This won't work if I create another data connection, but does work when I use my parameter approach.
One thing I've noticed about my .tde files is that, even if I specify a "normal" folder location when it I first create the extract, Tableau subsequently places the refreshed extracts into my temp folder. Is this standard practice?
Yes, I agree, this is not a perfect solution, and having another kind of filter - Dashboard Local would be very nice and enable your use case.
If you are dealing with a packaged workbook, a .twbx file, then you will see things placed in a temp directory. I am not aware of reasons for a .twb to place things in a temp directory.
I just want to throw my support for having dashboard filters that apply to all the viz's on a dashboard. I've managed to workaround Tableau's all-or-only-one approach to filters using either actions or Joe's most excellent Parameter trick, but for my most recent project this simply is not cutting it. Thanks.
Yeah likewise. There are obviously a bunch of workarounds (thanks guys!), but I would hope this gets built-in.
Inspired by Mike's 'workaround', I find a solution to eliminate the impact of Global filter on other dashboard and the constraint of multi-select.
1. Create a set in the worksheet that is going to be in the secondary dashboard. For example, if my primary dashboard is about the sales of all regions in US and my secondary dashboard is one of the region (Northeast as an example), I would create a set named Northeast and select the value of Northeast from Regions under Dimentions.
2. Drag the set (Northeast) to Filters in the sheets that would be in the second, third.....dashboard.
In these ways, the set at the local filters defines the Region which you want in the specific sheet and won't be impacted by the global filter even though it's still in the filters shelf.
Hope it helps.
Don't be hesitate if you have any question.
My apologies for digging this old post up.
I am aware that Tableau 8 has a better filtering option to "Filter to selected sheets", but I still need to use this trick for a calculated date field which can't seem to trigger the "Apply this filter to" feature. I am not sure if the "Show" and "Hide" logic will work on a date field, which is in range rather than category.
Any suggestion on making this work for a date field/ continuous field?
Thanks in advance!