When you publish, you get to specify a NAME and which views/dashboards/sheets to share, and which USERS/GROUPS get that publication. (I just publish dashboards, for the record. Tableau still pulls in all the necessary sheets.)
So you can have one wrkbook, and publish to three separate names, selecting the appropriate stuff for each respective user set.
Set up separate dashboards for different users, publish the appropriate dashboards for this-or-that user/group, and name the separate publications accordingly.
Thanks for the reply Joe. When publishing different names...can you use different filters for the different ones you publish?
So in my case...i publish the main, then publish asset using 'A' as my class filter. Or does that have be changed each time?
Not sure what you mean... Different filters.
On sheets? You mean on one sheet you have a filter set to "A", and for a different group you want to publish that sheet so that the filter is set to "B"? If that's the case consider this:
There are functions that can look at your user. ISMEMBEROF will tell you if the user is a member of "Assets" user group, or "Executive" user group, and then you can set filter values (within the same single sheet) based on who the user is. (There is also ISUSERNAME and ISFULLNAME.)
So a calc can look like this:
IF ISMEMBER("Asset Group") then "A" elseif
ISMEMBER("Executive Group) then "E" elseif
And then use FILTERVAL_CALC to do user-targeted filters.
Thanks again Joe. I think this is what I am looking for. Just so i understand correctly...
Within the workbook, i have a sheet called Cashflows and it has a filter called Class
The cashflow would be published three times with the three different filter codes...data source is the same and the sheet itself does not change.
So i can use th ISMEMEBEROF function to accomplish this?
Right. You would have only one sheet. You would have a calc field that looks as ISMEMBEROF or ISUSERNAME or ISFULLNAME to determine who the user is at the time. And then one way or another you would make your filter give these-records to these-users, and those-records to those-users, and other-records to other-users.
I'm using this myself to grant access (by group, so I use ISMEMBEROF) to a special set of records -- and even to whole sheets -- only to members of a superuser group. All the rest just get the basic set of data. In fact, on one sheet the superusers get access to filters that the basic users do not get.
And it's all triggered off one calc field:
if ISMEMBEROF('BroadcastPowerViewers' ) then 1 else 0 end
Then I filter for value of 1. If the value is 1, then I do/show/allow special things.
I not only use it in filters but in other calcs.
He'll still be maintaining 3 different workbooks, correct? I also have to maintain several versions of similar workbooks based on the same data sources, and have not been able to successfully use Tableau Server to host extracts or other data sources, so local extracts or live connections are connected to each workbook, requiring all changes to be made to each version.
What I'm describing is one, single workbook.
I'm picturing that Matt has one datasource, with data mixed in it from multiple user groups. (Or maybe multiple data sources, but the same "mixing" of data in each.) He doesn't want Group-A to see data for Group-B, for instance. But it's all piled into one place.
And I'm imaginging that the sheets and dashboards Group-A uses might have some differences from what Group-B uses.
All that stuff can be developed in one workbook. Sheets that are unique to one-or-another group would remain so, but sheets that both would use (except for the filters) could be managed by conditional programming based on ISMEMBEROF.
Maybe he would have separate dashboards (all within the same workbook). When he publishes for Group-A, he would name the publication on the server something like "Group A Applicaion", and when he publishes it, he would select only those dashboards that are pertinent to Group-A use. Likewise "Group B Application": uncheck the Group-A dashboards, check the Group-B dashboards, and then publish it with the Group B Application name. that would result in two separate publications, two separate URLs to get to them. Etc.
All one workbook.
Yes, you'd start with one workbook. But that becomes several workbooks (three different versions) when you start publishing to different projects for different group permissions, and each would have to be maintained on its own schedule, each would have its own extract or its own live connection, etc. What would be nice is if we could control all of the different versions we publish from one central workbook. The only way I know of to do that currently is by publishing data sources to Tableau Server, and switching to use that as the data source. Then, one data source can be refreshed to control multiple workbooks with the same data -- however, there are several limitations that make this very difficult to use at an enterprise level, in my experience.
Am I missing something? We are really struggling with this, so I'd love to know if I am making it more difficult than it needs to be.
If they have their own extracts, I don't consider them having the same data source.
Example: A school district. One database might have records for every kid, kindergarten through high school. But I might want one group of users to see only K-4, and another 5-8, and the last 9-12. So bunch the users into groups, and then my filters on my sheet would display records only pertinent to each group. And the K-4 users wouldn't want to see college-prep dashboards, nor would the 9-12 users want to see the dashboard for daycare options, so each publication would have those level-specific dashboards pertinent to each group. Common sheets would have special filtering; for instance the workbook would put the same attendance sheet on the K-4 dashboard as it would on the 9-12 dashboard.
When I publish, I would name one publication "Elementary", one "Middle" and one "High", and just select the dashboards for each that are pertinent to each.
And yes, if they have their own project, and their own data source, and their own production cycles, sure, you'd have 3 workbooks.
I'm picturing that this is not the case for Matt, based on the way he asked the question.
And it's not the case for me in the way I'm using the method I'm describing.
Well, extracts are mentioned in the OP.
I understand what you are saying, but don't see how its possible to control each version from one workbook--even with a live connection, I'm not sure how well this will work. I may be missing something.
Right, but they use the same extracts. (at least the way I read it.)
At this point, Matt has the idea I suggested. He can try it and report back how it works for him.
Even so, all extracts are local to a workbook (unless the Extract is published to Tableau Server and shared across workbooks)--so three separate published workbooks equals three separate local extracts. A change in one will not be reflected in the other workbooks.
My use case is complicated by publishing to multiple sites, not always being able to utilize live connections, etc. I feel the OP's pain.
Matt Clarkin: Please do report back to us with your findings. Cheers and thanks for posting!
And Joe, I'm not trying to debate you, I'm trying to learn! A live connection may make what you are suggesting possible--I am hoping to test that soon, and will certainly share my experience. I'm not sure how it would be possible when extracts are involved, even if they are exactly the same.
Just to piggyback here a little bit, but we are about to release an Enterprise Deployment Tool which may be able to solve most if not all of the issues from this thread. It allows for custom workbook transformations from plugins we are developing based on client needs. One of those needs being what is described here. 1 Workbook, small changes, deployed to multiple clients/sites/projects, etc..
Check out the EDT and all the other tools here:
Also, we are also constantly looking for pain points we may have not been exposed to as well. If you have something that you are consistently running into, that you think could be better, feel free to email me those ideas.