Ever get stuck trying to grant a Tableau user or group permissions to a project, workbook or data source and find yourself going in circles? In this post, we'll cover definitions, how different permissions interact with each other, and best practices, so you can configure your environment optimally and set permissions like a champ. If you want to take a step back and access users/groups, check here.
Users = Each individual accessing the system must be setup as a user. This is similar to a user account for logging into your computer.
Groups = A group is a way to organize similar users and grant them identical permissions.
Site Role = This is a system definition that represents the maximum amount of permissions for a user. That means a user defined with a site role of Interactor can never publish content. A highly detailed walk through of each role is available here. In short, in decreasing order of power are: Server Administrator, Site Administrator, Publisher, Interactor, Viewer, Viewer (can publish), Unlicensed (can publish), Unlicensed.
Permissions Rules = These out of the box configurations are available for selection when assigning permissions to content. Examples are Project Lead and Interactor. When selected, a default set of capabilities are provided.
Permission Capabilities = This is the most granular level of control over permissions assigned to content. For example, if the Publisher permission rule is applied, you grant a user project access to view and save. However, you can override any of them (although in this case you likely wouldn’t want to do that).
In this image, the user "Harry" is assigned the Publisher permission rule for the project and has the capabilities to view and save the project. The third icon is for a project leader.
Recapping the above definitions, a user is assigned a site role, and a user or group is assigned permission rules to THE CONTENT with each permission rule being customizable to the permission capability. Remembering that distinction of assigning permission rules to the content (not users) will help wrap your head around implementation of permissions.
Helpful Tips for Configuring Tableau Environments
Following are some helpful tips and best practices when configuring your association’s Tableau environment.
- Always assign a user to a group. Always set permissions to projects, views, and data sources using a group.
- Never assign a user directly to a project, view or data source. Assign a group instead.
- Think about applying permissions from the perspective of allowing instead of denying. In fact, use None instead of deny everywhere possible. Keep in mind an administrator site role will overrule any deny permission, however it will otherwise overrule any accept or unspecified rule.
- Using the Project Leader rule on a project supersedes other rules applied to that user/group for that project because it grants administrator type permissions for the project and the content it contains.
- If you want to use the Project Leader rule, then make sure the group to receive it has the Interactor or Publisher site role. For completeness, the admin site roles work too, but there isn’t an advantage to doing that.
- Using the Site Administrator role yields that user access to everything within the site which means not other sites or a few system settings that only a Server Administrator can modify.
- It will be less burdensome to organize your groups by Role (maximum permissions) and not strictly organizational based. That means put all the publishers in a group and don’t worry so much about dividing events and membership. However, if you do need to keep departments separate by their data access, then create multiple groups like Event – Interactors and Membership – Interactors to combine organizational and functional into groups.
Most importantly, don’t publish anything to the Default project. You can’t delete it, but you can leverage its baseline functionality of how it acts as a template. When a new project is created, it copies the permissions from the Default project. So set the All Users group to None on the default as well as configuring all your other standard groups. Some training is required for your publishers to instruct them not to publish to it. Lastly, notice when changing to None the save button turns to the phrase Delete, but you’re really just deleting previous permissions and when you click it the result will be a save action.
Once you get everything setup for your users, groups, and content, you can set each project permission to be locked. This means that publishers can’t override the original permissions of the project which is otherwise possible when publishing workbooks from Tableau Desktop. It is strongly recommended to use the project locking feature to reduce the administrative burden and provide additional simplicity to your publishers to avoid having unique permissions all over the environment.