Organising Your Tableau Server

Many organizations which use Tableau find themselves with hundreds of reports sitting under dozens of projects which in most cases doesn’t make sense, even if you created the best dashboard with amazing visualization it will have limited value if it’s difficult for staff to find them.

As trivial as this task might sound, in fact, it can have huge impact on your organization and how it use its data.

In this article I’ll share with you some of the steps we took to create a useful and clean Tableau server at Envato and how it went from a “graveyard” of reports into a tidy, governed, self-service tool that is being used massively throughout the organization.

Step 1 – Cleaning 

This is the most important and time consuming stage in this entire process, if you have more than 100, 500 or even 1000 dashboards it means (in most cases) that you have a problem.  You need to get to a point where only verified and useful dashboards remain on the server. We did that by first of all archive all the workbooks that hasn’t been in use in the last 3 months.

This brought us from ~1100 workbooks to less than 400. 

Step 2 – Interview Main stakeholders 

This stage has two purposes:

1. Understanding how your users find content on Tableau server and how they use it – this will give you a sense on how to structure it and where to put your efforts (better browsing experience, better tags definitions for search, more self service options etc.)
2. Understand which workbooks they are currently using in order to reorganize the projects folder in a manner that best suits their needs and also continue the cleanup stage – After doing the initial cleanup you would still probably going to be left with a fair chunk of dashboards, those who had only limited number of views were noted in a list to go over with the relevant stakeholder to see if it is still required, if not, it was archived as well, if yes, it was classified as public/private and to which product/department it belongs.

This brought us from ~400 workbooks to less than 200. 

Step 3 – Defining relevant structure + corresponding user groups

This stage is very much depend on your organization structure and usage, now that you have a bit more sense on how your stakeholders are using the server and what content it has, you need to think carefully what would make sense to you, start by asking these questions for example: is your organization more product oriented? Department oriented? Who are your main stakeholders? Etc..

We chose to use a mixed structure of product and department, meaning, each product, which is relevant to many departments, will have its own project and this project would be considered “Public” meaning all the user groups will have access to this project. Moreover, each department will have its own project, but, these projects will be private, meaning only the relevant user group would be able to see this project. This way, when a user logs into the server he will see only limited number of projects (only the public and his own department private one).

Permissions can be set at the site, project, workbook and even a view level, but we chose for the ease of governance to keep it on a project level. Therefore, after creating the projects, all the users were divided into user groups based on their departments (Finance, Marketing, Analytics, HR etc.) and using the permissions options, each user group got permissions to her own department project + all the public projects.

 Step 4 – Re org content

For each project we created 3 nested projects, Production, Sandbox and Under review.

All current used workbooks were moved to ‘Under Review’ folder in the relevant project, for example product related workbooks were put under the relevant public project. Then, after reviewing them and approving them they were moved to ‘Production’ folder within the same project.
All personal workbooks + those under ‘working in progress’ state were moved to ‘Sandbox’ folder.

Step 5 – Defining publishing processes 

In order to maintain the new order you must define clear rules and processes on who can publish, to where and follow some basic design principles so your users would feel comfortable browsing new dashboards.

Once that has been defined, only the Analytics / BI departments had the permissions to publish into ‘Production’ and ‘Under Review’ while the rest of the users had permissions to save reports only to the ‘Sandbox’ area.

Some rules that we follow:

1. Workbook can be moved to ‘production’ from ‘Under Review’  only after it has been reviewed by another team member, it has documentation and it follows the basic design principles we defined. 
2. Each workbook in the sandbox area which hasn’t been used for more than 60/90/120 days (you choose) would be archived automatically (We collected usage information using the Tableau server database.

Step 6 (Optional) – Build personalized Experience

Now that the server is clean and tidy and the users can find easily different workbooks, the next level is to build a “Welcome” dashboard which is showing for each user it’s activity as well as new content that was added.

Conclusion

This process is not easy and can take a long time (few months) as during the process new dashboards are being built and new users are being added so this needs to be handled seriously in an organized manner. However, the result is amazing and your stakeholder would be grateful for that. Good luck!