Hello Luke Johnson,
Hopefully a few of our admins jump in here with their suggestions but in my use the ability to partition areas of Tableau Server for a select group of users is the reason that we have implemented Sites. For instance, our community team has access to a Community related site on our external facing servers to support setting up Guest access to some of the views used here in the forums. We have control of this site but our setup and configuration does not impact the other users of the same server.
The Information Lab has cover the topic briefly on their web site as well - Understanding Tableau Permissions - The Information Lab
I hope that helps.
Thanks Patrick A. Van Der Hyde, I appreciate you sharing that use case for sites.
This is one of the article I read while investigating this topic:
The #2 pitfall is "Misuse of Sites," couple quotes below:
- "It creates problems like the inability to access data sources across sites, which usually leads to duplication of data on each site and all the synchronization issues that creates."
- "Sites are for multi-tenancy situations where you need complete isolation of data and workbooks for different user groups. If there is any situation where user needs overlap, don't even consider using sites."
In practice I have not found these to be true. I regularly connect to published data sources on separate tableau server sites, although it does take a few more clicks to connect and publish. I also have many users who access multiples sites on the server without issue, they just need to be added as users to each site.
Have you experience the pain points mentioned above? Do you share data sources across server sites? Am I misunderstanding the potential issues?
2 of 2 people found this helpful
the multi site and connecting to each separately is something I see. We use different sites to switch between 'live' and 'sandbox' as well and that's a situation where you want all of the users to appear in both but use the different sites for testing on the one hand vs live on the other.
I do not personally connect to tableau data sources across sites because - I tend to do this sandbox/testing site thing to a live site swap/dance and I configure and use them slightly differently with the sandbox not utilizing extract refreshes during business hours.
This is some of the ways we use.
Calling out Matt Coles since he might want to chime in with some of his findings/experiences.
Good read, lots of information. Clearly the answer is not one size fits all. As a current site admin I'm afraid of losing visibility to site usage. Is there any way to allow a "publisher" access to the native tableau site usage reporting without making them a site admin?
HI Luke - you can get the workbooks that serve the native site usage reporting. Where they are differs depending on what version of Tableau you have. Following our upgrade to Tableau v10.1.1 I used Russell Christopher's blog post here to get the relevant twbx which I then repointed to use our repository and published to a location on our Server accessible to all. I personally only chose to publish one of the dashboards for now (Stats for Load Times) as that's what people were asking to see following the upgrade.
Hope that helps!
Hi Donna, thanks for the info and the link! Currently I'm not a server admin (only site admin) so I don't believe I can connect to the Tableau Server file system, but I will certainly share with our server admin.
In my experience the "traffic to views" report has been very valuable, but I've often wished I could expand the scope. I imagine this would make it possible.
Another use case I'd be interested in is permission management. I wonder is this data could show which projects/workbooks are available for viewing based on a particular user or user group?
Hi Luke - I'm server admin from a UI perspective but don't have the rights to get onto the actual live server boxes themselves, but hopefully you've got someone who can help. I actually was able to pull them off a PoC server I have sitting under my desk which I do have full access to.
Once you've got them, then yes you'll be able to make adjustments to the views as you desire. Indeed I did this myself with the stats for load times view, adding a ref line on the timelilne to show the date we upgraded to give an inidcation if there had been any impact post upgrade.
Regarding permission management, I don't believe the screens that show this through the admin UI are available in workbook format like the above. You'll probably need to get under the bonnet and query the postgres db directly to serve the data you need. I haven't ever tried this myself, but here are a few threads that might get you going in the right direction :
Luke Johnson wrote:
... To start of the conversation here are what I see as some pro and cons of using a single sites structure:
1p) No user duplication across sites
Users and User groups must be maintained on each site. (Putting as both Pro and Con)
2p) Lends itself to shared data sources (Still possible across sites, just less convenient as it requires signing into each site.)
1c) Granting site admin privileges will need to be limited, as admin would be unrestricted. (Currently partitioned by site structure.)
Current site admins likely need to be publishers due to data access, and will lose visibility into native tableau site usage.
2c) Users and User groups must be maintained on each site. (Putting as both Pro and Con)
3c) Additional layer of permission and view-ability. Project > Workbook vs. Site > Project > Workbook
4c) Additional steps to connect to published data source on another site.
My perspective: Our environment has four Sites along with the Default and my own Admin I user for Tableau Server reporting. I did this to relieve my workload, giving Site Admin rights to only a couple of advanced Desktop users for their particular Site. They are responsible for maintaining it (Projects, Groups, Users, permissions, etc.). In keeping with the "self-service" concept this allows them to not be reliant on me to get stuff done (for example, add users to Groups). This paradigm works really well.
1p and 2c: Site Admins do this for their own Sites so it's no hassle for me It's not a big deal if someone is in multiple Sites, that's how it can be, and it's nice since you can pretty much treat each Site as if it was its own Server
2p: Are you sure multiple Projects -- even Sites -- will be using the EXACT data source information? We have several large data sources that are used by a variety of people in the different Sites but none of the data is the same between Projects, let alone Sites.
3c: For me, our HR has their own Site and I have my Admin Site. The inherent security of excluding Users from a Site works great. When people log on to the Server they won't see Sites that they aren't in. Same thing happens when publishing from Desktop. I cannot see how this is a negative Additional security is a positive thing.
4c: Uhm, okay...I think I'm missing something here. How is this a problem?
< edit > Ignore my 4c.
Luke Johnson wrote:
No. But you can publish those views to the Tableau Server and set permissions to only allow certain people to view them.
Oops, my bad, I mis-read your 4c. For some reason I read it as "additional steps to publish a data source to another site", meaning a couple more clicks. That's why I did a strike-through on it.
I have updated my blog of using Tableau site and added Site Request Questionaries.... Read here and let me know your comments SCALING TABLEAU (4/10) – USE SITES - Silicon Valley Enterprise Tableau User Group
Hi Luke... I just came across your question and am curious about the path you took and was it a good one to take?
We are very much a self service group and sites are created as necessary. Here are the pros...
We like the separation of duties
We like the added security
The cons are...
Management of little used sites can be a burden
Published datasources requires rights across sites to consume
The biggest con is the extract burden from multiple sites consuming similar data
Training multiple site admins can be time consuming but we have that pretty streamlined
We are now considering a hybrid version where the majority of the current sites would be under a single site with sites outside of the single site being the exception rather than the rule.