How Permissions are Evaluated

Permissions in Tableau Server are assigned to content assets—projects, workbooks, data sources, and occasionally to individual views. You use permissions rules to specify who can work with a content asset.

Each user’s level of access to content published to a site is determined by the following:

  • Site role. A user’s site role determines whether a user can publish, interact with, or only view content assets. For more information, see Set Users’ Site Roles.

  • Content permissions. Every project, workbook, data source, flow, or view theoretically can have a unique set of permissions rules.

    A permissions rule includes the user or group, and the set of capabilities you want to grant users for an asset or set of assets. An example of a capability is Download Data Source.

    Each permissions role template (such as Editor, Interactor, Viewer) specifies a predefined set of capabilities.

    Available capabilities vary depending on the content type. Capabilities can be set to Allowed, Denied, or Unspecified. Denied always takes precedence over Allowed; Unspecified results in Denied if no other permissions rules allow a capability for a user.

  • Ownership. Content owners always get full access to the content they've published, including setting permissions on it. In locked project hierarchies, you can prevent content owners from modifying permissions on their workbooks and data sources. For information, see Set Project Default Permissions and Lock the Project.

A user’s effective permissions for a given content asset are determined by the following:

  • The maximum capabilities allowed through the site role.

  • Whether the user owns the content item.

  • The result after Tableau evaluates permissions rules applied to that user and all groups the user is a member of.

You can set permissions rules for an individual user or group for each content asset. This diagram illustrates how permission rules are evaluated in Tableau Server.

Notes on permissions

  • You cannot set permissions at the site level; permissions are assigned to only to content.

  • Individual user permissions take precedence over group permissions.

  • Workbook permissions serve as templates for view permissions. In a locked project, when a workbook uses tabbed views, views inherit workbook permissions. In an unlocked project, when a workbook is saved without tabs, the workbook and view permissions can be edited independently.

  • For each content item, every site user is automatically included in the All Users group. As a result, when you create additional group permissions rules for a content item, the All Users permissions rules affect how permissions are evaluated. For more information, see 2. Remove permissions that will cause ambiguities in the topic “Configure Projects, Groups, and Permissions for Managed Self-Service.”

The order of precedence in which Tableau evaluates permissions

Tableau steps through the following rules, continuing to the next rule if the current one evaluates to “denied.” If any rule evaluates to “allowed,” the capability is allowed, and Tableau stops evaluating.

  1. Administrator site roles: Users who have the Server Administrator (Tableau Server only) site role, the Site Administrator Creator site role, or the Site Administrator Explorer site role can access all site content with full permissions, regardless of the permissions set on projects or individual content assets.

  2. License denies capabilities: If a user’s license type explicitly denies the capability, the user is denied. For example, a user with a Viewer license cannot connect to data sources.

  3. Project Owner: If the user owns a project that contains a content asset, the capability is allowed.

  4. Project Leader: If the user has, or is in a group that has, the Project Leader permissions role on a project, the user has administrative access to content in that project.

  5. User is content owner: If a user is the owner of a content asset, they are allowed all access. However, in locked projects, administrators or project leaders can deny capabilities at the project level, such as setting permissions on content the user owns. In locked project hierarchies, content assets inherit permissions set on the top-level project.

  6. User - capability denied: If the user has been explicitly denied the capability on a content asset, they are denied.

  7. User - capability allowed: If the user has been explicitly allowed the capability for the content, they are allowed.

  8. Group - capability denied: If the user belongs to a group that has been explicitly denied the capability for the content, they are denied.

  9. Group - Capability Allowed: If the user belongs to a group that has been explicitly allowed the capability for the content, they are allowed.

  10. The user is denied access to the content.

Thanks for your feedback! There was an error submitting your feedback. Try again or send us a message.