One big Tableau’s success factor is its self-service – Business dashboard creators can publish their workbooks in self-serve manner without IT’s involvement. Although IT may be involved for some data readiness, data ETL and data preparations. By large, most  Tableau implementations empower business users to create and release their dashboards directly.

When you drive more and more Tableau adoptions, you soon will realize that you need some good governance as well to make sure single source of truth,  data access policy consistence (among multiple self-service publishers), workbook style consistence, and avoid duplications of content, etc.

How to control or govern the publishing? There are multiple ways to go, depends on the nature of dashboards (data sensitivity, audience, purpose) and how much control you wanted to have:

1. Stage vs Official project : Only approved publishers can publish to Team Official project while a lot more people can publish to Team Stage project.
2. Landing page area within Tableau: The landing page is actually another workbook that your end users go to.  The workbook is more like ‘the table of contents’, it uses URL actions to go to each separate workbook, and only dashboards listed in this landing page workbook are official ones.
3. Portal embedding Tableau views outside Tableau: Most audiences will not go to Tableau server directly for dashboard but they go to portal that has all ‘approved’ dashboard embedded. The governance/control process happens at the portal since only approved content will be available to end users via embedded  portal access.
4. Test vs Prod server: You don’t allow publishers to publish to Prod server directly. Instead you find a way for them to publish to a Test server, then with proper approvals, the dashboards will be ‘pushed’ to Prod server.

The control level and difficulty level are as followings : Test vs Prod server > Portal embedding > Landing page > Stage 

There are many blogs about Staging, Landing page and portal embedding, this blog focuses on the Test vs Prod.

How to automate Test vs Prod server migration? It is common to have test env but it is also common that a publisher has publish access directly to both Test and Prod so self-service publishing can be done. However for some special use cases (like external dashboards, etc) where you absolutely do not want anyone to publish directly to the Prod server w/o approval at each workbook level and you want to automate the process, here is how to:

1. The best way is to use Tableau’s new Deployment Tool that is part of 2019.3 beta now but available for Windows now.  Deployment Tool enables the governance of Tableau server workbook and data source migrations. Admins and technology groups can finally automate and scale the distribution of workbooks/data sources between development, staging and production environments. It needs additional Server Management license which is new add-on feature.
2. Custom scripts using API for workbook and data source migrations. The high level approach is to download the workbook and data source from source server (using API) and then publish them to target server (using API). Sounds easy but the most difficult part  is to handle the embedded password. It has a few scenarios :   embedded password for live connections, for embedded data sources and for separately published data sources.  Good news is that it is all doable. Bad news is that it is very very difficult and it is more like ‘password hack’. I will not recommend this approach unless you work with Tableau’s Professional Service team. My organization had this done by working with Tableau’s Professional Service team and it works great for us.

I am still testing Tableau’s new Deployment Tool to understand what it offers.  My quick sense is that Deployment Tool should work with most of the organizations for content migration purpose. However I am not sure about it scalability – for very large enterprise customers that you have a lot workbooks/data sources to migrate from one server to another continuously, customer scripts with multi-threads will  give you better scalability.