Easy Table for Tableau Server Site Roles

Making sense of Tableau permissions can be difficult without a solid guide and a consistent plan on how to execute them. That is because there are several places where we can control the permissions, sometimes even using settings that may not seem immediately obvious that influence the permissions. So let's examine this common topic and demystify the permissions.

Tableau Version Matters

We should start from quickly discussing the changes to the permissions. The main point to know here is: Are we running a pre- or post-2020.1 Tableau Server? In 2020.1, Tableau released important changes to the permissions. This article will describe those and explain how to handle all the new options without getting lost. Let us quickly take a look at those new features below.

Set Permissions for Nested Projects

We can now separately control projects and their content. That gives us a possibility to lock some parts of a project and set other parts to Customizable, which allows the content owners (we will discuss those later) to change them. In short: this is a new possibility to delegate:

Improved Permissions Dialog

Now that we have more intuitive permission settings, we can select groups or users and apply template or custom permissions to each individually. We can set those up for the following: Project, Workbooks, Data Sources, Data Roles, Flows and Metrics. In short: you have more detailed control.

How to Create the Tableau Permission Setup

There are several levels of permissions that come in a hierarchy you should understand before you decide to start giving all your users and groups different privileges. It all depends on the correct combination of the permissions. Tableau explains this part the best by creating a simple hierarchy. Here it is from a bird's-eye view.

1. Everything starts at the License level. A user that has a Viewer license cannot be an administrator; however, one with a Creator license can be just a Viewer. Tip: it is a waste and such a user should have a lower-level license.*

2. The site role (one per site) can be chosen from seven different roles, and it limits what a user can do with the content. For example, a Viewer role cannot edit content even if explicitly given a permission. However, an Explorer role can be explicitly denied editing or any other action for specific content.

3. Content permission can be applied to multiple different object types. That is the lowest level, and in many circumstances, changing this one may not change anything if any of the above prohibits it.

*Users can have different roles across the sites. You can check it as a server admin and make sure that the license is correct for the highest role.

Above: Image courtesy of Tableau

It may seem counterintuitive that the only difference between the Explorer and Creator is the last part: creating data sources. In reality, there are two additional differences: Creator can use Tableau Desktop and Tableau Prep while Explorer cannot. However, from the Tableau Server point of view, the only difference is that Explorers cannot create data sources. In short: If you are trying to assign any of the permissions to a user, make sure that his/her license allows that permission.

Site Roles and Their Capabilities

As showed on the first image, the second level is site role. Depending on a user's license, we may be limited to give him/her only certain roles. We will go a step further and add those site roles to our table, along with a few additional capabilities that depend on the Site Role only:

*not available in Tableau Online
**if a Creator license is available on the Server, Server Administrator role will take it automatically

Please mind that unlike the license, which is assigned one per user, Site Role is assigned (like the name suggests) per site. One might be a Viewer on one site and a Site Administrator Creator on another.*** In short: Make sure that the capability you want to grant to a user is aligned with his/her license and site role.

***License would have to be adequate to the highest Role

Lastly, you should make sure that each user has the correct capabilities assigned to each project, workbook, data source, data role, flow and metric.

Understanding Permissions and Hierarchy

Now, let's have a look at formatting and the marks we can assign to every group/user. When you try to edit permissions, you probably noticed that we have three options, so what exactly do they mean?

Denied permission means the user will not be able to perform the action. Logically, the Allowed permission means that the user will be able to perform the action. Unspecified relies on other level permissions to decide whether a user can or cannot perform an action, i.e. group/individual (see the Groups section further down). Here's a quick example of those two rules. This rule applies to any feature, i.e. View or Web Edit:

Above: User is allowed to use workbook 1 but not workbook 2

Above: User is allowed to use workbook 1 but not workbook 2.
User must have a direct link to workbook 1 as they cannot see the Project.

Note: Please mind that these examples assume comparing only individual or only group privileges, not a mix of both. See Groups.

When we speak about the hierarchy, we should know all its levels. You can think about these as folders on your computer, and at some level, there are files (workbook, data source, etc.). It is important to understand that denying one object does not mean denying all the underlying ones, which we saw in the previous examples.

Example 1: User is denied seeing a project; however, they may see workbooks within it. If such a user has a link to the workbooks, he/she might access them (see the third picture above).

Example 2: User is allowed to see a workbook but denied interacting in any way with the data source that this workbook is live connected to. Said user can still use said workbook.

Example 3: User is allowed to see a Project but not objects within it. This user can open a Project and will see it empty:

Exploring Permissions and Groups of Users

Now you know that each object can be controlled individually for each user. We also have groups of users that have assigned permissions.

One user can be a member of many groups.
Every user is a member of a group called "All users".
Groups are lower in the hierarchy than individual permissions. This means that a user being allowed or denied a capability is more important than having it granted/denied on his/hers group level.
If user is a member of two groups (or more) and any single group denies a capability, this user will be denied it. Denied > Allowed in this case.

To further clarify these details, let's visualize them. For each object (project, workbook, etc.), we can change the permissions using the logic from above. Here, we have it summarized:

Nested Project Permissions

I know it seems like a lot of information … I promise we are almost done. There is an exception to the above rules for content owners. One becomes a content owner under these circumstances:

If assigned to be a content owner by:
- Server/Site administrator
- Higher-level content owner, i.e. a user is an owner of a Project and can change ownership of the objects within his project.
If publishing a workbook/object – this user automatically becomes an owner of such object.

A content owner always gets a full access to the content that he/she owns. However, just like described in the hierarchy, if a user cannot see a project, he/she must have a link that will lead directly to the object he/she owns. This rule does not have a priority above the role/license. If a user became an owner of a workbook and has a Viewer license or role, this user would not be able to Web Edit.

Content owners can also modify content permissions for users/groups if Content Permission is set to Customizable. If it is locked on a project level then the Project owner controls permissions for it and all of its underlying objects (nested-projects, workbooks, etc.):

Here, you can see an example of how Content Owner permissions are given the user (Role_Test) all the privileges, similar to to the admin* (Igor Garlowski), despite being explicitly denied access on the individual and group (All Users) levels:

*However, an admin (site or server) additionally has other rights across the site in comparison to Content Owners (see more in the Site Roles and Their Capabilities section).

Project Leaders

The actual reason Content Owners have all the privileges described above is because the Content Owner automatically becomes a Project Leader. The word Project refers to their title. One may be a 'Project Leader' of only one object. There are only two differences between those two titles:

Every object can have only one Content Owner, while it can have many Project Leaders.
The Content Owner controls who is and is not a Project Leader for the content they own.

What does it mean in practice?

Content Owners can share their full privilege to a Content Owner.
Project Leaders can make other users Project Leaders.
Project Leaders cannot change the Project Owner, unlike the Project Owner who can assign somebody else to this role.
Every Content Owner is automatically a Project Leader, but not every Project Leader is a Content Owner.

To summarize, when evaluating user's capability to a certain object, you should investigate it using the following hierarchy:

Some General Notes

There is a site role called "unlicensed." Such a user exists, but they cannot use Tableau Server (cannot log in) and has no capabilities. Such user can still own previously published content.
We cannot deny a Site/Server Admin capabilities. For example, denying all data source capabilities to a data source to a Site/Server Admin would make no difference for those users.
Web-edit and comments capabilities can be turned off for a whole site, preventing everybody from accessing it.
Prior to 2020, when we move objects while the permissions are unlocked (customizable), an object would retain its permissions. When locked, it would just inherit permissions from the place to which it was moved. From 2020 onwards, when it is unlocked (customizable) or locked, the object changes its permissions to those of a place it was moved to by default .
Removing a Project Leader from a project may not remove this person as a Project Leader from the nested-projects and objects within it (2020.2.2).

Use Case: Content Ownership and Redistributing Responsibility

Using Content Ownership can be very helpful if we recognize some users as our moderators. In this scenario, we will assume that we work in a company with multiple sales divisions. We have a project called Reporting – Sales within which we have nested-projects (a.k.a. subfolders) with names of each division.

Additionally, we do not want anybody, including the division managers, to see reports for other divisions. Instead of receiving emails about changes from each of them, we can make the following setup:

All sales representatives (including the managers) are members of a sales group; they also belong to a group of their division.
The sales group can see the Reporting – Sales project.
Each division group is unspecified for all of the nested-projects but their own where they are allowed.
The manager of each division is a Project Leader of their nested-project.
The Reporting – Sales project has a Content Permission set to Customizable (Project Leaders of lower-level objects can control the permissions based on their division needs).
Division nested-projects have Content Permission set to Locked (managers as Project Leaders of the nested-projects can control all permissions, but other members, including those that publish content inside, cannot overwrite it).
The above scenario gives us a clear hierarchy of responsibility (managers), while preventing a bottleneck of a Site Administrator or one Content Owner (i.e. Head of Sales) to manage this whole structure, which he/she is not involved in on a daily basis, in contrast to a division manager.

I'd like to especially thank Glen Robinson for all his help and feedback on this post. If you have any questions, feel free to contact us!

BONUS: Quiz Time

That was quite a lot of information. You can test your understanding of permissions by solving the quiz below and checking the answers.

Questions

Answers

newellfrus1939.blogspot.com

Source: https://interworks.com/blog/2020/09/29/tableau-server-permissions-a-complete-guide/