Does any of this feel familiar?
- Users struggle to find the dashboards they are looking for.
- Users aren’t sure which dashboard versions are up to date.
- There is a lack of clarity around who has access to what.
Without governance there are multiple truths. Information is difficult to find. Ill-informed decision making occurs. Silos exist. Lack of governance causes poor Tableau Server performance, resulting in a poor user experience across the organization.
Project Leaders should follow these best practices to manage unit projects.
Step One: Create a sandbox space within project folder
In technology, a sandbox refers to a secure, isolated environment that a limited number of people have access to explore, experiment, test, and collaborate without jeopardizing the main (production) environment.
In the university’s Tableau environment, all users have access to the ‘My Sandbox’ project. This is a relic from when Tableau first launched at the university. It is not recommended for users.
It is recommended that project leaders create one sandbox within their unit’s project. For the sake of reporting, it helps if the project sandbox name follows similar naming conventions to the project (ex. A&P – Sandbox or OSEM – Sandbox).
Step Two: Project permissions
Sandbox permissions should be restricted to only those with one of the following:
- Creator capabilities
- Web Authoring capabilities
- Users involved in testing the dashboard.
Production permissions should be broad – in other words, the users who need to see the data have access to the dashboards.
Resources around permissions include Tableau Permissions and Access, Understanding Tableau Server Permissions, and a short video around Understanding Tableau Permissions. If using an Enterprise data source, please review Using Enterprise data sources and permissions.
Step Three: Extract Refresh Schedules
Workbooks, flows, and data sources in a project sandbox should NOT have scheduled refreshes. Refreshes may be manual.
Objects in production folders should have extract refreshes scheduled.
Step Four: ‘Official’ vs. ‘Unofficial’ data sources
‘Unofficial’ data sources should exist only in the project’s sandbox. These are data sources that are currently being worked on.
Once the data source has been validated, it should be moved to a different location outside of the project’s sandbox. Some teams have separate data source folders for the project. These production data sources can be certified. Certification will give the data an ‘official’ label within Server and promote it in search results.
Step Five: Metadata
All production content needs metadata. At a minimum, descriptions should be used for projects, data sources, and workbooks. Questions to consider and sample templates are available in the ARC. To review how to add descriptions, please see the Tableau Tips video.
In addition to adding descriptions to objects, it can be helpful for your future self and other developers to add descriptions to the fields themselves.
Step Six: Content Maintenance
Once a project sandbox has been created, permissions checked, objects sorted, and metadata added, it’s important to make sure the environment remains tidy. Below is a sample to do list:
- Establish a cadence at which group membership should be evaluated. If S4 data exists in the project, it must be quarterly. All other groups may be monitored on an annual basis.
- Create a project archive folder. Move stale content to the folder. The university’s policy to tag content as ‘stale’ that has not been accessed in 90 days. Move this stale content into the archive folder.
- Hint: if you go to a project folder and search for stale (or hover over objects) you can see which content has been tagged as stale. There are also dashboards in the [Creator Toolkit] project on Server to see stale content.
- Establish a cadence at which content should be evaluated. Is it still relevant? Is it being used? Does it still meet the needs of the end user?