Permissions

Permissions determine how users can interact with content such as workbooks and data sources. Permissions are set in the permission dialog or via the REST API(Link opens in a new window). At the top of the dialog, permission rules configure capabilities for groups or users. Below, the permissions grid displays the effective permissions for users.

Project permissions dialog showing the workbook tab

There are several interrelated topics that discuss how to think about, set and manage permissions. The main topics are:

  • This topic, which covers the fundamentals, how to set permission rules for projects and other content and permission considerations for specific scenarios.
  • Permission Capabilities and Templates, which covers in detail the various capabilities that are used to build permission rules.
  • Manage Permissions with Projects, which covers using projects to manage permissions and how nested and locked projects impact permissions.
  • Effective permissions, which covers how permission rules are evaluated and how final permissions are determined.
  • Permissions, Site Roles and Licences, which covers how permissions interact with site roles and licences to determine what a user can do on a site.

Additionally, if the Data Management Add-On is present, permissions for external assets have additional considerations. For more information, see Manage Permissions for External Assets.

Permissions fundamentals

Projects and groups

Tableau sites use projects to organise content and groups to organise users. Managing permissions is easier when permission rules are:

  • Set at the project level instead of on individual pieces of content.
  • Established for groups instead of individuals.

Permissions can only be established for users, groups, projects or content that already exist. For more information about creating users and groups, creating projects and publishing content, see Manage Users and Groups, Use Projects to Manage Content Access, and Publish Data Sources and Workbooks(Link opens in a new window).

Capabilities and permission rules 

Permissions are made up of capabilities – the ability to perform actions like view content, web edit, download data sources or delete content. Permission rules establish what capabilities are allowed or denied for a user or group on a piece of content.

Note: When talking about permissions in general, it’s common to see a phrase like “a user must have the delete permission”. This is easy to understand in a broad context. However, when working with permissions at a technical level like in this article, it’s more accurate to say “the delete capability”. In this topic we’ll use the more precise term capability, but you should be aware that you might see permission in other places.

The permission dialog showing several permission rules with some capabilities allowed, denied or left unspecified

The interplay between licence level, site role and potentially multiple permission rules factor into the final determination of what a user can or can’t do. For each user, this becomes their effective permissions. For more information, see Effective permissions.

Some tasks such as creating new workbooks from a browser (web authoring) or moving content might require specific configurations of several capabilities rather than being captured in a single capability. For more information, see Permission settings for specific scenarios.

Set permissions

Permission rules are set differently at the project level, at the content level or when publishing content from Tableau Desktop.

Note: The phrase “project permissions” can have two meanings. There are the permission capabilities for a project itself – View and Publish – that control how a user can interact with a project. There is also the concept of project-level permission rules for other content types. In this article, “project-level permissions” means permission rules for workbooks, data sources and the other content that are configured in the permission dialog for a project. This is in contrast to “content-level” permission rules that can be set on a specific workbook, data source, etc.

For administrators, project owners and project leaders

To set permissions at the project level:

  1. Navigate to the project
  2. Open the Actions menu (...) and click Permissions.

    Actions menu

    The permissions dialog opens. This dialog has two main areas: permission rules at the top and the effective permissions grid below. Each content type has a tab. The image below shows the Workbook tab.

    Project permissions dialog showing the workbook tab

    With a row selected at the top, the effective permissions grid populates. Use this to verify permissions. Hovering provides information about why the capability is allowed or denied for that specific user.

  3. To modify an existing permission rule, select the appropriate tab for that content type and click a capability.
  4. To create a new rule, click + Add Group/User Rule and start typing to search for a group or user. For each tab, choose an existing template from the drop-down box or create a custom rule by clicking the capabilities.
  5. One click sets the capability to Allowed, two clicks sets it to Denied and a third click clears the selection (Unspecified).

  6. When finished, click Save.

Tip: Permission rules set at the project level act as a default for content saved in that project and any nested projects it contains. Whether those project-level default rules are enforced or only preliminary depends on the content permission setting. This setting can be configured in two ways, either Locked or Customisable. For more information, see Lock content permissions.

For administrators, project leaders and content owners

If project content permissions are customisable, permissions for individual pieces of content can be modified. The information below is not relevant to content in locked projects. For more information, see Lock content permissions.

Tip: While it is possible to set permissions on individual content in customisable projects, we recommend managing permissions at the project level.

Set permissions on content

  1. Navigate to the content (workbook, data source, flow, data role)
  2. Open the Actions menu (...) and click Permissions.

    Actions menu

    The permissions dialog opens. This dialog has two main areas: permission rules at the top and the effective permissions grid below. (Note the lack of tabs across the top – a content-level permissions dialog has no tabs.)

    Workbook-level permissions dialog showing permission rules and effective permissions

    With a row selected at the top, the effective permissions grid populates. Use this to verify permissions. Hovering over a capability square provides information about why the capability is allowed or denied for that specific user.

  3. To modify an existing permission rule, click a capability.
  4. To create a new rule, click + Add Group/User Rule and start typing to search for a group or user. Choose an existing template from the drop-down or create a custom rule by clicking the capabilities.
  5. One click sets the capability to Allowed, two clicks sets it to Denied and a third click clears the selection (Unspecified).

  6. When finished, click Save.

Set permissions on a view

Tip: While it’s possible to set view-level permissions within a workbook, we strongly recommend managing permissions at the project or workbook level.

If a workbook is published with Show Sheets as Tabs ticked, the views in that workbook will inherit all permissions set for the workbook. The permission dialog for a view will be read-only.

In some situations, it may be valuable to specify permissions on a view independently from the workbook that contains it. If the workbook is published with Show Sheets as Tabs unticked, the views will start with the workbook permissions but will be independent thereafter and can be set independently. Note that this means if the permission rules are modified for the workbook, those changes won’t be applied to the views – each view’s permissions will need to be managed individually.

See Show or Hide Sheet Tabs for more information.

For content publishers

If project content permissions are customisable, permissions for individual content can be set when publishing from Tableau Desktop. The information below is not relevant for content in locked projects. For more information, see Lock content permissions.

Tip: While it’s possible to set permissions on individual content in customisable projects, we recommend managing permissions at the project level.

  1. From the publishing dialog, click the Edit link for Permissions.
    If the Edit link is unavailable, permissions are locked to the project and can’t be modified except by the project owner, project leader or an administrator.
  2. The Add/Edit Permissions dialog shows any existing permission rules. Click Add to add a new permission rule or Edit to modify an existing permission rule
    1. Select the group or user from the left pane. You can expand a group to see which users it contains.
    2. Use the selector at the top of the right pane to choose an existing template, or use the radio buttons to create a custom rule.

    Add/Edit Permissions dialog seen when publishing from Tableau Desktop

    Note that effective permissions can’t be inspected from the publishing dialog.

  3. When finished, click OK and resume publishing.

Note: Permissions can’t be set while publishing flows from Tableau Prep Builder. To set permissions on a flow, refer to the steps for Project-level permissions or Content-level permissions.

Tip: By default, all users are added to an “All Users” group that has basic permissions for content. To start with a clean slate when building your own permission rules, we recommend that you delete the rule entirely or edit the rule for All Users to remove any permissions (set the permission role template to None). This will help prevent any ambiguity down the line by reducing the number of rules that apply to any given user and therefore making effective permissions easier to understand.

Permission settings for specific scenarios

Certain actions require combinations of permission capabilities and possibly site roles. The following are some common scenarios and their necessary permission configurations

Saving, publishing and overwriting

In the context of permissions, saving is essentially publishing. As such, the Overwrite and Save a Copy capabilities can only be given to users with a site role that allows publishing: Administrator, Creator or Explorer (can publish). Explorer or Viewer site roles can’t publish, overwrite or save a copy.

(Prior to version 2020.1, the Publish and Overwrite capabilities were called Save, and the Download Workbook/Save a Copy capability was called Download Workbook/Save As.)

  • The Publish capability for a project allows a user to publish content into that project.
  • The Overwrite capability allows a user to save over an existing piece of content; they become the owner.
  • The Save a Copy capability allows a user to save a new copy of the content. This is usually done in conjunction with web authoring and means the user can save their modifications.

It’s important to note that users aren’t able to Save or Save As a piece of content unless they have the Publish capability for at least one project, because all content must be published into a project. Without the Publish capability at the project level, the content can’t be published.

In web editing, the Save option in the File menu only appears to the content owner. If a user who is not the owner has the Overwrite capability (allowing them to save the content), they must use File > Save As and name the workbook the exact same name. This prompts a warning that they are about to overwrite the existing content, which they can do. Conversely, a user with only the Save a Copy capability trying to use the same name gets an error stating they don’t have permission to overwrite the existing content.

If a user who is not the content owner overwrites content, they become the owner, with all the permissions that entails. The original owner’s access to the content is then determined by their permissions as a user rather than the owner.

Note: Download Workbook/Save a Copy is a joint capability for workbooks. Explorers can be given this capability but they are only able to download the workbook, not save a copy. Giving the capability to Explorer (can publish), Creator or Administrator site roles gives them both the ability to download workbooks and save a copy.

Web Editing and Web Authoring

Web editing and web authoring refer to the general ability for users to edit or create workbooks directly in the browser. The permission capability is called Web Edit and the site setting is called Web Authoring. This section will refer to any web-based editing or publishing action as web authoring.

To enable this functionality, there are several requirements.

  • User site role: The user must have the appropriate site role.
    • Viewers can never web edit.
    • Explorers can be given the web edit capability but can’t publish. Essentially, they can use web editing to answer deeper questions based on existing content on the fly, but can’t save their edits.
    • Explorers (can publish) or Site Administrator Explorers can publish, but they can only use data that is already published to the site.
    • Creators, Site Administrator Creators and Server Administrators can publish and create new data sources.
  • Permission capabilities: The user must have the necessary permission capabilities based on the desired functionality.

Required Permission Capability Settings

Desired functionality Minimum Site Role Web Edit Download/Save a Copy Overwrite (workbook) Publish (project) Connect (data source)
Web author without being able to save Explorer Allow Deny Deny Optional Allow
Web author and save as new content Explorer (can publish) Allow Allow Deny Allow Allow
Web author and save (overwrite) content Explorer (can publish) Allow Allow Allow Allow Allow
Web author with new data and save new content Creator Allow Optional Optional Allow Optional

Optional indicates this capability is not involved in the desired functionality

Data access for published Tableau data sources

Data sources published to a Tableau site can have native authentication as well as permissions within the Tableau environment.

When the data source is published to the Tableau site, the publisher can choose how to Set Credentials for Accessing Your Published Data which addresses how data source credentials are handled (such as requiring users to log into a database or enter their credentials for Google Sheets). This authentication is controlled by whatever technology holds the data. This can be embedded when the data source is published, or the data source publisher can choose to prompt the user for their credentials to the data source. For more information, see Publish a Data Source.

There are also data source capabilities that allow or deny users the ability to see (View) and connect to the published data source (Connect) in the context of Tableau. These capabilities are set like any other permissions in Tableau.

When a workbook is published that uses a published data source, the author can control how the Tableau authentication will behave for someone consuming the workbook. The author sets the workbook’s access to the published data source, either as Embed password (using the author’s Connect access to the data source) or Prompt users (using the Connect access of the person viewing the workbook), which may require data source authentication as well.

  • When the workbook is set to Embed password, anyone who looks at the workbook will see the data based on the author’s access to the data source.
  • If the workbook is set to Prompt users, the Tableau-controlled access is checked for the data source. The person consuming the workbook must have the Connect capability for the published data source to see the data. If the published data source is also set to Prompt user, the viewer must also enter their credentials for the data source itself.
Workbook authentication to the data source Data source authentication to the data How data access is evaluated for someone consuming the workbook
Embed password Embed password User sees the data as if they were the workbook author
Embed password Prompt user User sees the data as if they were the workbook author. (The author is prompted for data source authentication, not the user.)
Prompt user Embed password User must have their own Connect capability to the published data source
Prompt user Prompt user User must have their own Connect capability to the published data source and are prompted for their credentials to the underlying data

Note that this applies to consuming a workbook, not web editing. To web edit, the user must have their own Connect capability.

Move content

To move an item, open its Action menu (...) and click Move. Select the new project for the item, then click Move Content. If Move is unavailable or there are no available destination projects, verify the appropriate conditions are met:

  • Administrators can always move content and projects to any location.
  • Project leaders and project owners can move content and nested projects among their projects.
    • Note that non-administrators can’t move projects to become top-level projects
  • Other users can move content only if all three of the following requirements are met:
    • Creator or Explorer (Can Publish) site role.
    • Publishing rights (View and Publish capabilities) for the destination project
    • Owner of the content, or – for workbooks and flows – having the Move capability.

When a project is moved, the permissions for its content might change.

  • Project leaders or project owners always gain permissions for items moved into their projects.
  • When a project is moved into a locked (including nested) project, the permission templates for the locked project are enforced on the moved project and all its content and nested projects. (Note that this might strip the user moving the project of their ability to move it again if they don’t have the correct permissions in the locked project.)
  • When a project is moved into an unlocked project (customisable), the existing permissions are retained for the moved project and its content. If the project leader status has only implicitly been granted (from a higher-level project), that status is removed, though any explicitly set project leader status is retained.

Metrics

Metrics are created from views in published workbooks. A user can create metrics if they:

  • Are a Creator or Explorer (can publish) site role
  • Have the Publish capability on a project
  • Have the Download Full Data capability for the relevant view or workbook

For more information, see Create and Troubleshoot Metrics and Set Up for Metrics.

Permissions for metrics

Because metrics are independent content, it’s important to note that the permissions for metrics are managed independently from the view they were created from. (This is unlike data-driven alerts and subscriptions, where the content of the alert or subscription can only be seen if the user has the correct permissions for the view itself.)

Although the capabilities for metrics are straightforward, the View capability should be considered carefully. It may be possible for a workbook with restricted permissions to be the basis for a metric with more open permissions. To protect sensitive data, you might want to prevent metric creation for specific workbooks.

Prevent metric creation

The ability to create a metric cannot be directly disabled on a per-workbook level (only per-site), but permissions can regulate access between metrics and workbooks.

To prevent metrics for a specific workbook, deny the Download Full Data capability on the workbook.

To ensure this capability cannot be changed, deny Download Full Data at the project level for all workbooks in the project, and lock the content permissions for the project.

Show or Hide Sheet Tabs

In the context of published content, sheet tabs (also referred to as tabbed views) is a distinct concept from sheet tabs in Tableau Desktop. Showing and hiding sheet tabs in Tableau Desktop refers to hiding sheets in the authoring environment. For more information, see Manage Sheets in Dashboards and Stories.

Showing and hiding sheet tabs (turning tabbed views on or off) for published content refers to navigation in a published workbook. When sheet tabs are shown, published content has navigational sheet tabs along the top of each view.

comparison of view navigation with tabbed views on and off

This setting is also impacts how permissions function and may have security implications (see note).

Note: It is possible to have the View capability for a view without the View capability for the workbook or project that contain it. Normally, if a user lacks the View capability for a project and workbook, they would not know those assets exist. If they have the View capability for a view, however, a user may be able to see the project and workbook name when looking at the view, such as in the navigational breadcrumb. This is expected and accepted behaviour.

Turn off tabbed views to allow independent view permissions

Although it is not recommended as a general practice, there are times when it can be useful to set permissions on views independently of the workbook that contains them. To do so, three conditions must be met:

  1. The workbook must be published – there is no way to set view permissions during publishing.
  2. The workbook must be in a customisable project.
  3. The workbook can’t show sheets as tabs (tabbed views must be hidden).

When a workbook shows sheets as tabs, all views inherit the workbook permissions and any changes to the workbook permissions affect all of its views. When a workbook in a customisable project does not show tabbed views, all views assume the workbook permissions upon publication, but any subsequent changes to the workbook’s permission rules will not be inherited by the views.

Changing the configuration of sheets as tabs on a published workbooks will also impact the permission model. Show Tabs will override any existing view-level permissions and reinstate the workbook-level permissions for all views. Hide Tabs will break the relationship between the workbook and its views.

Important: In a customisable project, any modifications to the workbook-level permissions will not be applied if navigational sheet tabs are hidden (aka tabbed views are off). Changes to permissions must be made on individual views.

Collections

Unlike projects, which contain content, a collection can be thought of as a list of links to content. Project permissions can be inherited by the content in the project, but permissions for a collection have no affect on the content added to the collection. This means that different users might see different numbers of items in a collection, depending on which items they have permission to view. To make sure that users can see all items in a collection, adjust the permissions for those items individually.

Permissions for a collection can be changed either by using the permissions dialog or by granting access upon sharing a collection, if you’re an administrator or the collection owner. For more information, see Manage Collection Permissions.

Private collections

When a collection is created, it is private by default. A private collection appears on the owner’s My Collections page, but it doesn't appear in the list of all collections on a site. Private collections are simply collections with no permission rules added. Unlike other types of content, collections don't have the “All Users” group added by default. When you add permission rules to a collection, it is no longer flagged as private. To return a collection to a private state, remove the permission rules.

Private collections can be viewed by the collection owner as well as by administrators, whose site role gives them effective permissions to view all collections.

Thanks for your feedback!