I’ve had the pleasure of working with a large number of Tableau Server users and administrators, and by far the most common phrase I hear is “What the [expletive redacted] is up with permissions?!”

Permissions in Tableau Server are very simple, given two conditions:

1. Forget everything you know about any other permissioning system ever, and
2. Read the below VERY carefully.

Edit: Version 9.2+ Gives Us Options

Tableau Server versions 9.2 and newer give us an option that makes permissions seem a little more familiar. In 9.2, Tableau introduced the ability to Lock Content Permissions to the Project. When you configure your project with these locked permissions, all content will use the project permissions. In a sense, this is very similar to inheritance, and allows the server administrators to have complete control over content permissions. While still super-valuable if you’re locking permissions, the remainder of this article assumes you’ve NOT locked the content to the project. 

Inheritance Is Not A Thing

Tableau Server is laid out in this hierarchy:

• Sites
  • Projects
    • Data Sources
    • Workbooks
      • Views

When you’re consuming data or visualizations on Tableau Server, the only permissions that ever matter are the object-level permissions. Specifically, permissions are evaluated for:

• Data sources
• Workbooks (if published with Show Sheets As Tabs selected)
• Views (if published without Show Sheets As Tabs selected)

The permissions set at the project level do not matter once the workbook or data source has been published. On that note …

Projects Are Templates

Every site comes with a default project. When a new project is created, whatever permissions the default project contains are copied to the new project. If the default project’s permissions are too … permissive … then such will be the case with each new project until you edit them.

Permissions at the project level are used as a template when publishing. When you publish a workbook, you have View Permissions on the left-hand side of the Publish Workbook window:

View permissions are populated from the project permissions. You can modify them here if you want, but whatever is in the left-hand side of this window is what the effective permissions will be on the object. This is the only place where project permissions affect the workbooks or data sources.

When you change project permissions, it does not alter the permissions of the objects within the project. In order to do that, you’d need to click the Assign Permissions To Contents button [Edit: from 9.2 on, this has changed to a selector that can choose whether to lock permissions to the project or not. To Assign Permissions to Contents, lock the permissions, and then unlock them again].

Rules, Roles and Capabilities (Oh, My!)

This one’s pretty easy, other than the fact that “rules” and “roles” sound too much alike.

• Capabilities – These are the actions that users could do, such as view, filter or download
• Roles – A role is a grouping of capabilities. For instance, the Interactor role should be able to view, edit, filter, etc.
• Rules – A role assigned to a user or group.

I like drawing this picture to help explain that concept:

You can see that the rule ties it all together.

Admin and Site Roles

It’s worth mentioning that there are a few special roles to call out before we get into how permissions are evaluated:

• Server Admin – This user can see and control all the things on Tableau Server, regardless of any other permission.
• Site Admin – This user can see and control all the things on the site for which they are an admin, regardless of any other permission.
• Project Leader – This user can see and control all content in their projects, regardless of any other permission.
• Content Owner – This user can see and control all of their own content, regardless of any other permission.

I’m sure you noticed the repetitive “regardless of any other permission,” but it’s important enough to call out a fifth time. In these roles, no other permissions matter.

Site roles give administrators a little more flexibility. These roles are configured for each user at the site level and are the maximum allowable permission that users can have on the site. For example, if a workbook permission allows Jane Doe to filter, but Jane’s site role disallows it, Jane will not be able to filter.

Now that you’re armed with this bit of final information, let’s look at how permissions are evaluated!

How Permissions Are Evaluated

This is the last component to understanding how permissions work in Tableau Server. We’ve already reviewed these major points:

• No concept of inheritance [Edit: except that excellent 9.2+ lock feature!]
• Projects are templates
• Rules, roles and capabilities
• Admin and site roles

When accessing a piece of content, Tableau Server will determine whether you are allowed each capability in this order:

1. Are you a server admin, site admin, content owner or project leader for this content? If so, you get all the things.
2. Has your user been explicitly denied the capability? If so, you’re denied the capability.
3. Has your user been explicitly allowed the capability AND does your site role allow it? If so, you’re allowed the capability.
4. Is your user a member of a group that has been explicitly denied the capability? If so, you’re denied the capability.
5. Is your user a member of a group that has been explicitly allowed the capability AND does your site role allow it? If so, you’re allowed the capability.
6. If none of these things apply, you’re denied the capability.

Remember that this “flowchart” is executed at the object level (data source, workbook or view) and not any other level of the object hierarchy (project, site). [Edit: again, except for that fantastic 9.2+ lock feature]

Finally, a word about this confusing little area:

In this sense, “inherit” actually means “unspecified.” You’ll notice that the terminology in Tableau Server’s permissions viewer states Unspecified but Tableau Desktop still says Inherit. If this is selected, it’s neither allowing nor denying that capability. 

Pop Quiz

I know this is just a blog post, and I have no right to ask you to validate your knowledge. But, I’m a Tableau trainer, and I can’t help myself! Say that you’re a user who belongs to both Group A and Group B. In determining whether you can view a worksheet, you see that permissions are set like this:

For each question, determine your effective permission. Assume that you are not an admin of any sort and that you are not restricted by any site role.

Reveal Answers

1. Deny – The user Deny trumps group permissions.
2. Deny – Group B takes precedence here.
3. Allow – Nothing denies this, and Group A and Group B allow it.
4. Deny – Nothing allowed it.
5. Allow – The user Allow trumps group permissions.
6. Deny – Permissions are only set for Group A, and it’s Deny.
7. Allow – Permissions are only set for Group B, and it’s Allow.

If you have any questions, feel free to comment below or contact us!