Tableau permissions: Guide and best practices

Security is essential in any data platform. Understanding how permissions are defined and evaluated it’s then also essential for information control.

Knowing and following best practices from the beginning can save us a lot of work in the medium and long term. One of the advantages of Tableau is it facilites a complete governance by differentiating between content governance and data governance. Aditionally, we can not only determine who is going to access the data, dashboards, projects, and other content. We can also define what capabilities each group or individual will have with those content elements.

This, although it gives a lot of flexibility, also generates confusion and especially when we are new to the platform. Following best practices for setting up permissions and security rules is key and much easier if we understand and follow those best practices from the beginning. So let’s review some basic but of very important points.

Basic best practices

#

Tableau recommends following a few basic principles to make permissions management as simple and scalable as possible. These principles are:

Modify permission rules for the Default project

#

It’s always recommended to modify the permission rules in the Default project and set them to None for the All Users group in all capabilities. Why? because when we create a new project, Tableau uses the Default project as a template. So when we create a new project Tableau will basically copy the permission rules of the Default project. By making this change and we will have a security model that restricts access by default and, when a new project is created, no user (except the project owner and administrators) will have access to the project and it’s content. Being able to decide, afterwards, who should have access.

Lock permissions at the project level

#

By default, Tableau allows users with permissions to do so (admins, project leads, Creators with permission to publish, etc.) to modify permissions for elements within a project, such as data sources or dashboards. This, although it offers a lot of flexibility, ends up generating great difficulties to undersntad who has access to what content.

A second best practice is to not allow permissions to be modified when users publish content to a project. To do this, Tableau allows to lock permissions at the project level. We can also do this in the Default project so that any new project is created with this default configuration as I explained in the previous section.

Set permission rules for groups instead of users

#

The reason for this is simple: when it comes to manage permissions, it’s much easier to do so for groups rather than setting rules for individual users. Individual user permissions should be used as less as possible. This will make it easier for admins and project leaders to manage permissions.

Permission rules, effective permissions and permission evaluation logic

#

One key aspect to understand of Tableau’s permissions is the difference between permission rules and effective permissions, as well as the importance of the permission evaluation logic and maximum capabilities per user type. Let’s dive deeper into these aspects.

Permission rules vs effective permission

#

One thing Tableau admins often find confusing is the difference between the permission rules set up and the effective permissions. This is because although we can create any type of permission rule, they are evaluated in order of priority and some times we will try to remove permissions to users but users will still have those capabilities due to the user’s role or other permission rules. Most common examples are:

• A user with the Administrator role will be able to view all content in Tableau. Independently of the permission rules we create that affect that user.
• A user with the “Viewer” role will never be able to edit a Workbook, even if we enable that capability.
• A user doesn’t have access to a concrete Project because they belong to two groups, one with permissions to access that group and one another one with denied access.

This examples showcase situations where we can set up permission rules that imply:

Deny access to dashboard Z to the User A.

But, even with that rule set up, user A might have access to dashboard Z. that’s why it’s key to review both the permission rules and the effective permissions, and understand how tableau evaluates permission rules, giving priority to some rules.

Tableau makes it easy to review effective permissions in the interface. If we select a specific permission rule, we will be able to see at the bottom the effective permissions for the user or group of users that rule applies.

In the image above, we can see how even though there is a permission rule that denies the user to see and publish to the project, that user actually has permissions for both capabilities since they the user is a Creator Administrator.

Key aspects about permission evaluation

#

With that in mind, here are some considerations to keep in mind to understand permissions in Tableau:

1. Is the capability we want to give to the user possible for that user’s license type and role? It’s important to remember that Administrators have permission for all capabilities across all Tableau content and data because they have to manage the platform.
2. The user will have all the capabilities that their role allows them for any content they own.
3. Rules set up at the user level take precedence over rules set up for a group of users.
4. Denial takes precedence over enablement.

Therefore, Tableau first reviews the user’s role, and that role determines the maximum capabilities that the user will be able to have. In other words, even if we give them permissions to do something, a user won’t have that capability if their user role doesn’t have that capability.

After that first role check, Tableau evaluates whether the user has an Administrator role or if the user is the leader of the current project or if he/she is the owner of the specific piece of content. Finally, it Tableau reviews whether the individual user has been denied or enabled the capability in question and, finally whether the capability has been denied or enabled to the groups that the user belongs to.

Maximum role and user type capabilities

#

As mentioned above, some user roles and license types will never be able to perform some tasks or have some capablities because it’s out of the scope of the license type or user role.

Some examples are:

A Viewer will never be able to create a new Project.

An Explorer will never be able to edit a data source.

For a detail review of the maximum capabilities of each license and role, I recommend checking the official documentation about roles and maximum capabilities.