Effective permissions

A permission rule establishes who is impacted (a group or user) and what Capabilities they are Allowed, Denied or Unspecified. While it seems straightforward to simply set a permission rule and have that be the whole story, whether a user has a capability may be unclear because of membership in multiple groups and the interplay of site roles and ownership with permission rules.

Multiple factors are evaluated in a specific order, yielding effective permissions on a piece of content.

Tip: To help keep things as straightforward as possible, we recommend (1) setting permission rules for groups instead of users, (2) managing permissions locked at the project level instead of setting permissions on individual content and (3) deleting the All User group’s permission rule or setting all capabilities to None.

A capability is allowed for a user if and only if the following three conditions are all met:

The capability is within the scope of their site role.
They have that capability:
- based on a specific user scenario (such as being the content owner or a project leader, or they’re an administrator site role),
  OR
- because they have been allowed the capability as a user,
  OR
- because they are both in a group that has been allowed the capability and no rules deny them the capability as a user or member of another group.
There is no conflicting permissions settings at another content level that takes precedence.

Any other situation denies the user the capability.

Hovering over a capability brings up a tooltip that explains the effective permission. Here are some common examples of why effective permissions – what the user can or can’t do in actuality – might appear different than what a given permission rule states:

A user might have a capability they are denied in a permission rule because their site role includes it (administrators).
A user might have a capability they are denied in a permission rule because their user scenario allows it (because they own the content or are a project owner or leader).
A user might lack a capability they are allowed in a permission rule because their site role doesn’t allow it.
A user might lack a capability they are allowed in a permission rule because a conflicting group or user rule denied it.
A user might lack a capability they are allowed in a permission rule at one level of content (such as a workbook) because another level of content denied it (such as a view).

Evaluate permission rules

Permissions in Tableau are restrictive. Unless a capability is granted to a user, they are denied permission. The following logic evaluates if a capability is allowed or denied for an individual:

Flow chart of the rules for how permissions are evaluated

Site role: If a site role doesn’t permit a capability, the user is denied. If the user's site role does permit the capability, then specific user scenarios are evaluated.
- For example, a Viewer site role can’t web edit. See General capabilities allowed with each site role for more information on what each site role can do.
Specific user scenarios:
- If the user is an admin they have all capabilities on all content.
- If the user is a project owner or project leader, they have all capabilities on all content in their projects.
- If the user is the content owner, they have all capabilities* on their content.
- If these scenarios do not apply to the user, then user rules are evaluated.
*Exception: Content owners won’t have the Set Permissions capability in projects where permissions are locked. Only administrators, project owners and project leaders can set permission rules in locked projects.
User rules: If the user is denied a capability, it is denied. If they are allowed a capability, it is allowed. If a capability is unspecified, then group rules are evaluated.
Group rules: If the user is in any group that is denied a capability, it is denied. If the user is in a group that is allowed a capability (and not in any groups that are denied that capability), it is allowed.
- That is to say, if a user is a member in two groups, and one is allowed a capability and one is denied the same capability, the denial takes precedence for that user and they are denied.
If none of the above conditions apply, the user is denied that capability. In effect, this means that capabilities left as unspecified will result in denied.

A final effective permission of Allowed therefore occurs in three circumstances:

Allowed by site role (Server Administrator, Site Administrator Creator, Site Administrator Explorer)
Allowed because the user is the content owner, project owner or project leader
Allowed by a group or user rule (and not denied by a rule of higher precedence)

Denied occurs in three circumstances:

Denied by site role
Denied by a rule (and not allowed by a rule of higher precedence)
Not granted by any rule

Evaluate permissions set at multiple levels

If Asset permissions are set to Customisable, it’s possible to configure permission rules in multiple places. There are specific rules that determine what permissions are applied on the content.

If there are nested projects, permissions set at the child level take precedence over permissions set at the parent level.
Changes to permissions at the project level are not enforced for existing content.
If there are permissions set on content (workbook, data source or flow) during or after publication, these take precedence over rules set at the project level.
If a workbook doesn’t show navigational sheet tabs, any changes to the workbook-level permissions won’t be inherited by the views and any changes to permissions must be done on the view.
Configuring the workbook to show navigational sheet tabs will override existing view-level permissions and sync them with the workbook-level permissions. See Show or Hide Sheet Tabs.

Flow chart of the rules for how permissions are evaluated with nested projects

This image shows how capabilities are evaluated through multiple levels of content.

Permissions on views

In a workbook that is not in a locked project and does not show sheets as tabs for navigation, views (sheets, dashboards, stories) inherit the workbook permissions at publication, but any changes to permission rules must be made on individual views. View capabilities are the same as those for workbooks, except for Overwrite, Download Workbook/Save a Copy and Move which are only available at the workbook level.

We recommend showing navigational sheet tabs whenever possible so views continue to inherit their permissions from the workbook. For more information, see Show or Hide Sheet Tabs.