[I’m delighted to publish a guest post, from Miranda Osterheld, one of my super colleagues at Tableau. She works in Customer Consulting, helping to solve people’s challenges. Over to you, Miranda!]
Across my customers, I’ve noticed that the most effective and impactful data insights are often driven by a creative process that requires experimentation and iteration.
Data analysis can lead to exciting findings but often requires many “beta” workbooks that don’t pan out, aren’t production-ready, or are personal to a particular user. Data analytics experts and novices alike need a place to save their work-in-progress, so they can securely but confidently build on their insights before sharing with others (if they choose to!).
Where should I save my ad-hoc and temporary workbooks?
For users with Creator licenses, saving workbooks on their desktops can serve as that safe place, but often the ability to stage content in Tableau Server or Online is an invaluable part of the development process. Plus, explorers are server-only analysts, so they only have the option of saving their work in projects on Tableau Server – assuming they have the right site role and permissions. So, the result of these requirements is generally the creation of a “sandbox” project, a folder that attempts to support the balance between security and freedom mentioned above.
There are two main techniques I’ve seen administrators adopt to create these sandboxes. Both come with some caveats:
- Single open sandbox: Some have created a single, open project for all users to save content in which everyone has access to everything. This very open model can be effective for collaboration across teams, but there is risk of hindering content discovery because of all the “noise”. Plus, the high level of visibility might inhibit publication and experimentation by users not ready to share their content.
- Individual or team level sandbox projects: Other administrators manually create and permission personal sandboxes for each user. This generally results in a project request bottleneck as administrators are frequently tasked with project creation as every new user is onboarded. You can utilize Tableau APIs to automate many of the administrative steps, but many organizations are unable or unwilling to do this extra work.
There’s gotta be a better way!
Our customers usually weigh these two options by the tradeoff between security and administrative overhead. However, the great news is there’s a third option that many people haven’t considered that simply leverages how the permission model functions. You can set up a single sandbox project that behaves like a personal sandbox, with the benefits of both approaches!
How-to
- Create a new project called Personal Sandbox.
- Navigate to the project permissions, and lock permissions to the project. Locking the permissions to the project prevents content owners from overriding the project level permissions. This ensures that only way to share content is to move/publish it to a different project.
- Set permissions on the project for the “All Users” group. Under Project, set the group as Publisher. This gives users the ability to view and save to the project:
- Under workbooks, you have two options. The first way is to simply set the permissions to None, which effectively denies all users from seeing workbooks owned by other owners (workbook/data source owners will always be able to see content they own). If users aren’t specifically granted capabilities through a user or group permission rule, they will be implicitly denied.
- You also have the ability to explicitly deny all capabilities, but this isn’t any more secure than the implicit denial. Additionally, if you wanted to give a small group of designated “normal” users (non-admins and non-project leaders) the ability to tend to the sandbox and periodically remove stale content or promote content on people’s behalf, these denials can get in the way:
- For Data Sources, you have the same two options as above. I’d recommend you set permissions to None. As with Workbooks, this prevents users from seeing data sources owned by other owners:
Again, you have the option to explicitly deny all capabilities. Just keep in mind this will prevent administrative capabilities by anyone other than people with a project leader, site admin, or server admin role, as mentioned above:
- Invite users to use the Personal Sandbox by sending them a link and letting them know how to use it. For creators, it will immediately appear in their projects available to publish to from Tableau Desktop, and explorers will see it on their projects page in Server/Online.
- Monitor usage with list views. Personal Sandbox content is in a single location so administrators can use check how often content is viewed and suggest owners delete content that is stale; or check who is making the most use of the Personal Sandbox.
- Consider variations based on your group structure. Following these permissions for the All Users group will result in even Viewers being able to see an empty and potentially confusing Personal Sandbox Project. You might consider a slight alteration where you’re only granting permissions to a “Publishers Group”:
And, you might want to create a group of Sandbox Caretakers to be able to remove stale content:
Why does this work?
- Content owners can always see the content they own, even if it’s published in a project where they are denied the ability to view workbooks and data sources.
- Users can save workbooks to the Personal Sandbox project and use data sources that live in other projects (e.g., departmental projects for Sales, Marketing, and Finance).
- Creators can upload personal data sources to the Personal Sandbox, but just like workbooks, these will only be visible to the owner.
- When new users are added to the server, they are automatically added to the “All Users” group. This means they have access to save content in the Personal Sandbox without any additional set up.
- When users leave or lose their licenses, the content still lives in the Personal Sandbox project which allows administrators to reassign ownership.
- If you leave workbook and data source permissions set to none “None” as opposed to denied, you can create a small group of trusted users that are able to monitor sandbox usage and prevent this project from over-leveraging storage and resources on the server. If you deny workbook and data source permissions, you’ll have to manually grant each individually users explicit allowal (not particularly scalable), or need to grant those users the project leader capability to allow them to monitor the content. Keep in mind as Project Leaders they’ll also be able to control permissions at the project level.
The future of a personal data playground doesn’t end here
I’ve seen this solution work really effectively at organizations that want to enable their business users and analysts alike with the freedom to explore and create without judgement, but want to avoid any additional administrative burden. Obviously users can still leverage other staging projects to collaborate and elicit feedback from others before moving content to the production-ready project, but the Personal Sandbox ensures that everyone has a private staging area as well. Here at Tableau, we’ve seen time and time again the amount of value a true culture of self-service analytics can bring to any organization willing to empower their users.
Thanks to Miranda for a great post! You can get in touch with her on LinkedIn:
Recent Comments