Posted by Peder Enhorning
September 20, 2016
Client dashboards are rarely ever “done” and evolve over time from one version to the next. When dashboard functionality or information changes, the descriptive contents of the dashboard have to be manually updated. Also, Tableau dashboards often link to other dashboards, and when they are moved between Tableau sites or Tableau Servers, the links need to be changed.
Most organizations have a formal process to upgrade and distribute Tableau dashboards with Tableau Server configured for multiple sites (i.e., staging, production, etc.) to support this.
For example, let’s say:
This is not an uncommon scenario for many organizations using Tableau. Assume that IT requires all dashboards be published from the analyst’s workstation up to a staging site and once approved it can be published to the production Tableau Server.
In this scenario, the following changes have to be made to move from version 1 to version 2 on the staging Tableau site:
The total number of changes to publish from a local analyst workbook up to the Tableau Server staging environment? 38 changes. And if you forget any of those, the dashboard will be out of synch with the content which results in very confused dashboard users.
When the dashboard is finally approved and moves to production? Another 12 changes to make the hyperlinks work in the production environment instead of staging.
That’s 50 changes that have to be kept in synch for just one Tableau dashboard. And absolutely none of this can be automated via Tableau Server command scripts (e.g., tabcmd).
Each set of changes requires the analyst to open the workbook, manually make the changes, then publish the revised version to the new Tableau site… an entirely manual process.
Furthermore, in many organizations there are hundreds of Tableau workbooks that all have the same requirements. So even if we’re conservative and say 100 workbooks, that means almost 5,000 manual changes by different teams, different analysts, in different Tableau sites; and all of this has to stay properly synched up or end-users get confused and analysts spend all of their time maintaining the dashboards instead of analyzing data. For some large organizations, there are thousands of users viewing thousands of dashboards, so multiple this times ten or more.
(One client estimates it takes them 150 hours per month to manage this process!)
The problem in this case is that basic visual elements such as view titles, help text, button tooltips, hyperlinks, and other such user interface content is spread across so many workbooks, analysts, and teams. There is no easy way to centralize all of this very basic content. We’re not referring to centralizing chart types or data sources… rather about widely distributed basic text that cannot be automated.
To solve this problem, we have implemented a set of tables that categorize and classify basic UI content and centralize it in a way that minimizes maintenance overhead.
In most cases, you can simply change the environment that a workbook is designed for, and all of the basic text and hyperlinks within the workbook will automatically update to the correct revision without requiring any maintenance within the Tableau workbook. All maintenance of basic text and hyperlinks can be accomplished through a centralized interface. We now offer a custom service to put this centralized interface in place.
Let’s take the example from above. Once the analyst defines the help text, button tooltips, etc. for version 2 within the interface, all they have to do when they publish the Tableau workbook is change the “environment” value from “development” to “staging”.
So instead of making those 50 changes to move from development to staging to production, there are two changes – one from development to staging and one from staging to production. What if the version number changes from version 2 to version 3 a few months later? There are still only two changes to make when publishing the new version 3 workbook. And fewer changes means less chance of errors when updating workbooks.
Display text and hyperlinks are no longer spread across hundreds of Tableau workbooks. Instead, they reside in a single, centralized database. Basic display text and hyperlinks are now database driven – not manual text fields within every single workbook.
Here’s another challenge for most Tableau implementations. What happens when the Tableau Server name changes? Perhaps the staging Tableau Server used to be “staging.tableau.acme.com” but now the hardware has changed, the server has been relocated, and the new domain name for the staging Tableau Server is “tabstg.acme.com”.
What would you have to do in the typical organization? Firstly, all Tableau dashboards in the staging environment with hyperlinks in them would break. End-users that click on a hyperlink in Tableau would find the browser opens up with a 404 “not found” error. Then the dashboard publishers all have to go back into all of their workbooks and update hundreds of hyperlinks in hundreds of dashboards. What a nightmare!
Alternatively, when using this interface, you go into the created database, change one value in one field, and all of the hundreds of dashboards automatically update to point to the new server. No publishing necessary, no broken hyperlinks, no maintenance. One field in one table controls all hyperlinks in all Tableau workbooks.
What are your experiences and thoughts?
Explore Posts By Category