13 Replies Latest reply on Apr 26, 2018 6:19 PM by david tanner

    Best Practices? Tableau Sever Site Structure

    Luke Johnson

      I'm a site admin on a server running several sites.  We are migrating to a new server and are considering modifying the current site structure to operate on a single site.

       

      What are the most important considerations while planning the site structure of a tableau server?  For scale my site has about 150 users.  We have 500+ users across all the sites our on current server (many users access multiple sites.)  We are part of a large organization leveraging tableau server across many functional teams: Sales, Operations, Product, Finance, etc

       

      Is there any good documentation on the subject?

       

      To start of the conversation here are what I see as some pro and cons of using a single sites structure:

       

      Pros:

      No user duplication across sites

           Users and User groups must be maintained on each site. (Putting as both Pro and Con)

      Lends itself to shared data sources (Still possible across sites, just less convenient as it requires signing into each site.)

       

      Cons:

      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.  

      Users and User groups must be maintained on each site.  (Putting as both Pro and Con)

      Additional layer of permission and view-ability.  Project > Workbook vs. Site > Project > Workbook

      Additional steps to connect to published data source on another site.

       

      Thanks!

        • 1. Re: Best Practices? Tableau Sever Site Structure
          Patrick A Van Der Hyde

          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.

           

          Patrick

          • 2. Re: Best Practices? Tableau Sever Site Structure
            Luke Johnson

            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:

            Tableau Zen: Implementing Tableau Server: Top 10 Pitfalls

            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? 

             

            Luke

            • 3. Re: Best Practices? Tableau Sever Site Structure
              Patrick A Van Der Hyde

              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. 

               

              Patrick 

              2 of 2 people found this helpful
              • 4. Re: Best Practices? Tableau Sever Site Structure
                Luke Johnson

                I just found a great blog post on the subject of tableau server sites: How To Use Tableau Sites from Mark Wu

                 

                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?

                • 5. Re: Best Practices? Tableau Sever Site Structure
                  Donna Coles

                  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!

                  Donna

                  • 6. Re: Best Practices? Tableau Sever Site Structure
                    Luke Johnson

                    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?

                     

                    Thanks,

                    Luke

                    • 7. Re: Best Practices? Tableau Sever Site Structure
                      Donna Coles

                      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 :

                      Query which objects a user and/or group has connector/viewer/interactor privileges to?

                      Re: Using Postgres To Examine Permissions

                       

                      Good luck!

                      • 8. Re: Best Practices? Tableau Sever Site Structure
                        Toby Erkson

                        Luke Johnson wrote:

                         

                        ... To start of the conversation here are what I see as some pro and cons of using a single sites structure:

                        Pros:

                        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.)

                         

                        Cons:

                        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.

                         

                        Thanks!

                        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.

                         

                        Regarding...

                        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.

                        • 9. Re: Best Practices? Tableau Sever Site Structure
                          Toby Erkson

                          Luke Johnson wrote:

                           

                          ...Is there any way to allow a "publisher" access to the native tableau site usage reporting without making them a site admin?

                          No.  But you can publish those views to the Tableau Server and set permissions to only allow certain people to view them.

                          • 10. Re: Best Practices? Tableau Sever Site Structure
                            Toby Erkson

                            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.

                            • 11. Re: Best Practices? Tableau Sever Site Structure
                              Mark Wu

                              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

                              • 12. Re: Best Practices? Tableau Sever Site Structure
                                Bob Nims

                                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.

                                • 13. Re: Best Practices? Tableau Sever Site Structure
                                  david tanner

                                  I'm strongly in the use Projects not sites camp. and with nested projects even more so now.

                                   

                                  Why?  Customer Experience, I have a person with access to two sites they have to actively change from one to the other, browser bookmarks don't always work embedded content can become a problem.

                                   

                                  What's the con? Admin will need to create some good automation, a good thing in the long run anyway.  Tableau server API is easy to use and automate tasks.

                                  You can create much better and tailored for your user versions of the server admin dashboards ( much much better), against the readonly tableau workgroup database and even implement user level data access.