Permissions

Permissions define what capabilities a user is allowed or denied, controlling what they can see and do with content such as workbooks and data sources.

Permissions are set in the Permissions dialog box. At the top, permission rules configure capabilities for groups or users as allowed, denied, or unspecified. Below, the permissions grid displays the effective permissions for users.

Permissions fundamentals

Tableau sites use projects to organize content and groups to organize users. Permissions are applied to content or projects and determine how users or groups interact with pieces of content.

Permissions are made up of capabilities, the ability to do things 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. The exceptions are administrators, who have all capabilities on all content, and content owners, who have all capabilities on their own content.

For each user, there must be a final resolution of allowed or denied for each capability, known as effective permissions. The interplay between license level, site role, and permission rules also factor into the final determination of what a user can or cannot do. To ensure users have the correct access to content, it’s important to understand all the pieces that go into the final effective or resulting permissions for a user. 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.

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.

Permissions, site roles, and licenses

Adding a user to a Tableau Server requires a license. For each site the user belongs to they have exactly one site role, restricted by their license. A user has permissions for content on the site, restricted by what their site role allows. Licenses and site roles apply to users. Permission capabilities apply to content.

Licenses are assigned to a user when they are created on the Tableau Server or Tableau Online site. Users are licensed as a Creator, Explorer, or Viewer.

  • License levels determine the maximum site role a user can have on that server.
    • Server Administrator, Site Administrator Creator, and Creator site roles require a Creator license.
    • Site Administrator Explorer, Explorer (can publish), and Explorer site roles require at least an Explorer license.
    • Viewer site role requires at least a Viewer license.
  • For Tableau Server, a user consumes only one license per server, even if they are a member of multiple sites. If a user is a member of multiple sites, their required license level is determined by their highest site role. (For example, if a user has a Creator site role in one site and a Viewer site role in two others, they must have a Creator license.)

Site roles are assigned to a user when the user is created, and again any time they are added to another site. Users have a site role for each site they are a member of.

  • Site roles determine the maximum capabilities a user can have in that site. (For example, a user with a site role of Viewer will never be able to download a data source even if that capability is explicitly granted to them on a specific data source.)
  • Site roles do not inherently grant any capabilities in and of themselves—with the exception of the administrator site roles. Administrators always have all capabilities applicable to their license level.

Permissions consist of capabilities, things like the ability to save to a project, web edit a workbook, connect to a data source, etc. They apply to group or user on a specific piece of content (project, data source, workbook, view, or flow).

  • Permission capabilities are not given to a group or user in a vacuum but rather in the context of content. A user can have different capabilities for different content assets.
  • Permissions are evaluated based on the interplay of a user’s site role and the permission rules for that user or any groups they are members of.
  • Some actions such as web authoring might require combinations of capabilities.
Site Roles and their maximum capabilities

These tables indicates what capabilities are available to each site role. There may be other ways for a user with a site role to perform an action. For example, although Viewers cannot be given the Share Customized capability, they can share views by copying the URL. See General capabilities allowed with each site role for more information on what each site role can do.

Projects

Capability Creator Explorer (can publish) Explorer Viewer
View
Save
Project Leader
View

Workbooks

Capability Creator Explorer (can publish) Explorer Viewer
Save
Download Image/PDF
Download Summary Data
View Comments
Add Comments
Filter
Download Full Data
Share Customized
Web Edit
Save
Download Workbook/Save As
Move *
Delete
Set Permissions

*Although the Explorer role can be given the Move capability, they cannot have the Save capability on a project and therefore there is no place for them to move content to. The Move capability should therefore be considered not possible for Explorer site roles.

Data Sources

Capability Creator Explorer (can publish) Explorer Viewer
View
Connect
Save
Download Data Source
Delete
Set Permissions

Flows

Note that Flows are part of the Data Management Add-on.

Capability Creator Explorer (can publish) Explorer Viewer
View
Run Flow
Save
Download Flow
Move *
Delete
Set Permissions

*Although the Explorer role can be given the Move capability, they cannot have the Save capability on a project and therefore there is no place for them to move content to. The Move capability should therefore be considered not possible for Explorer site roles.

Data Roles

Note that Data Roles are part of the Data Management Add-on.

Capability Creator Explorer (can publish) Explorer Viewer
View
Save
Move *
Delete
Set Permissions

*Although the Explorer role can be given the Move capability, they cannot have the Save capability on a project and therefore there is no place for them to move content to. The Move capability should therefore be considered not possible for Explorer site roles.

Set permissions

Permissions can only be established for existing users, groups, or content. Managing permissions is easier when permission rules are established for groups instead of individuals.

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.

For administrators and project leaders

Permissions can be set at the project level for both the project itself and for any content in the project. For example, if workbook permissions are configured at the project level, all workbooks published into that project inherit those default permissions. However, the Creator can choose to change the permissions during publishing, or certain users can change the permissions on published content. To enforce the permissions established at the project level, Content Permissions can be locked to the project. For more information, see Lock project permissions.

To set permissions at the project level:

  1. Navigate to the project
  2. Open the Actions menu (...) and click Permissions. The permissions dialog box opens.
  3. This dialog box has two main areas: permission rules at the top and the effective permissions grid below. Each section (Project, Workbooks, Data Sources, Flows, Data Roles) can be expanded () to reveal the capabilities for that type of content.

    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.

  4. To modify an existing permission rule, open the Actions menu (...) for that row and click Edit.
  5. To create a new rule,
    1. Select + Add a user or group rule.
    2. If necessary, use the drop-down box to the right to change between groups and users.
    3. Select a group or user from the drop-down box. This creates a row where you can configure the permission rule.
  6. In the row for the permission rule, choose an existing permission role template from the drop-down box for each section, or create a custom rule by expanding a section () and clicking the capabilities.
    One click sets the capability to Allowed, two clicks sets it to Denied, and a third click clears the selection (Unspecified).
  7. When finished, click Save.

For administrators, project leaders, and content owners

If project permissions are not locked, permissions for individual pieces of content can be modified.

Warning: Tableau recommends managing permissions at the project level within the Tableau site. These steps are relevant only for content in projects where permissions are managed by the owner.

Set permissions on content

  1. Navigate to the content (workbook, data source, flow, data role)
  2. Open the Actions menu (...) and click Permissions. The permissions dialog box opens.
  3. This dialog box has two main areas: permission rules at the top and the effective permissions grid below.

    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.

  4. To modify an existing permission rule, open the Actions menu (...) for that row and click Edit.
  5. To create a new rule,
    1. Select + Add a user or group rule.
    2. If necessary, use the drop-down box on the right to change between groups and users.
    3. Select a group or user from the drop-down box. This creates a row where you can configure the permission rule.
  6. In the row for the permission rule, choose an existing permissions role template from the drop-down box or create a custom rule by clicking the capabilities.
  7. One click sets the capability to Allowed, two clicks sets it to Denied, and a third click clears the selection (Unspecified).

  8. When finished, click Save.

Set permissions on a view

In some situations, it may be valuable to specify permissions on a view independently from the workbook that contains it. To set permissions on a published view, navigate to the view within a published workbook and follow steps above.

Warning: While it is possible to set view-level permissions within a workbook, we strongly recommend managing permissions at the project (or workbook) level as much as possible. For views to inherit permissions, the project must be locked or the workbook must be published with Show Sheets as Tabs. See Show or Hide Sheet Tabs for more information.

For content publishers

If project permissions are not locked, permissions for data sources or workbooks can be set when publishing from Tableau Desktop.

Warning: Tableau recommends managing permissions at the project level within the Tableau site. These steps are relevant only for content in projects where permissions are managed by the owner.

  1. From the publish dialog box, 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 box 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.

  3. Note that effective permissions cannot be inspected from the publishing dialog box.

  4. When finished, click OK and resume publishing.

Note: Permissions cannot be set while publishing flows from Tableau Prep Builder. To set permissions on a flow, refer to the steps for Set Project Permissions or Set Content 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 edit the All Users group to remove any permissions (set the permission role template to None). This will help prevent any ambiguity down the road by reducing the number of rules that apply to any given user and therefore making effective permissions easier to understand.

Permission capabilities

Permissions are made up of capabilities, or the ability to perform a given action on a piece of content (project, workbook, view, data source, or flow). Each type of content has a series of permission role templates to make it easier to assign capabilities quickly, but these can be modified to create custom capability combinations.

Permission Roles

When working in a project, there are content types: Projects, Workbooks, Data sources, and—if you have the Data Management Add-on—Flows and Data Roles. Expand each section to see what capabilities are available.

All content has permission role templates for None (which sets all capabilities to unspecified) and Denied (which sets all capabilities to denied), as well as permission role templates that allow specific groups of capabilities (leaving the rest unspecified). . Capabilities can also be granted or denied independently in a custom configuration.

To modify an existing permission rule:

  1. Click the Actions menu (...) next to the group or user name then click Edit
  2. If necessary, expand () each section to reveal its capabilities
  3. Click a capability in the rule once to set it to Allowed, twice to set it to Denied, or three clicks to clear it back to Unspecified
  4. Click Save when you are done (or Delete, if setting all capabilities to Unspecified)

Projects have three capabilities, View, Save, and Project Leader.

View Save Project Leader
View Save Project Leader
The Viewer permission role grants the View capability. The Publisher permission role grants the View and Save capabilities. The Project Leader permission role grants the Project Leader capability.
Details on project capabilities and permission roles

The image above shows a row for each of the permission role templates, illustrating which capabilities they grant or deny.

Capabilities: 

View allows a user to see the project. If a user has not been granted the view capability, the project does not appear for them. Note that granting the view capability for a project does not imply a user can see content in the project. This capability is only for the project itself.

Save allows a user to publish content to the project from Tableau Desktop or Tableau Prep Builder. The save capability is also required to save content to the project from web authoring. (Saving is the web editing equivalent of publishing).

Project Leader allows a user to manage the project, including: setting permissions on all content or the project itself, locking project permissions, changing content ownership, moving content, and running refresh schedules.
In a project hierarchy, a group or user with the project leader capability on a project will have that capability for any child projects nested in that project. Removing the project leader capability can only be done at the highest level where it applies.

Permission roles:

Viewer allows the user or group to connect to the data source on the server.

Publisher allows the user or group to connect to, download, delete, and set permissions on data sources on the server. They can also publish data sources, and as long as they are the owner of a data source they publish, they can update connection information and extract refresh schedules. (The latter two capabilities are no longer available if an administrator or project leader changes data source ownership.)

Workbooks have three groupings of capabilities: View, Interact/Edit, and Edit.

View Interact/Edit Edit

View

Download Image/PDF

Download Summary Data

View Comments

Add Comments

Filter

Download Full Data

Share Customized

Web Edit

Save

Download Workbook/Save As

Move

Delete

Set Permissions

The Viewer permission role grants all View capabilities. The Interactor permission role grants all View and Interact/Edit capabilities. The Editor permission role grants all View, Interact/Edit, and Edit capabilities.

Note: In a workbook that is configured to hide tabs, views (sheets, dashboards, stories) inherit the workbook permissions at publication, but any changes to permission rules must be made on individual views. We recommend showing sheet tabs whenever possible so views inherit their permissions from the workbook. See Show or Hide Sheet Tabs.

View capabilities are the same as those for workbooks, except for Save, Download Workbook/Save As, and Move which are only available at the workbook level.

Details on workbook capabilities and permission roles

The image above shows a row for each of the permission role templates, illustrating which capabilities they grant or deny.

Capabilities:

View allows a user to see the workbook or view. If a user has not been granted the view capability, the workbook will not appear for them.

Download Image/PDF allows a user to download each view as a PNG, PDF, or PowerPoint.

Download Summary Data allows a user to view the aggregated data in a view, or in the marks they’ve selected, and download that data (as a .CSV).

View Comments allows a user to view the comments associated with the views in a workbook.

Add Comments allows a user to add comments to views in a workbook.

Filter allows a user to interact with filters in the view, including keep only and exclude filters. Users lacking this capability will not see filter controls in the view.

Download Full Data allows a user to view the underlying data in a view, or in the marks they’ve selected, and download that data (as a .CSV).

Share Customized allows a user to shared saved customizations made to the view (such as filters and selections). These customizations appear as options for other users, they do not change the default state of the view for others.

Web Edit allows a user to edit the view in a browser-based authoring environment. Note that creating new content in the browser or saving views from the web edit interface (Web Editing and Web Authoring) requires a specific combination of capabilities.

Save allows a user to overwrite the content asset on the server.
When allowed, the user can re-publish a workbook, data source, or flow, or save (overwrite) a workbook in web authoring, thereby becoming the owner and gaining access to all permissions. Subsequently, the original owner’s access to the workbook is determined by their permissions just like any other user.

Download Workbook/Save As allows a user to download a packaged workbook (as a .twbx). Allows a user to save (publish) a copy from the web edit interface as a new workbook.

Move allows a user to move workbooks between projects. For more information, see Move content .

Delete allows a user to delete the workbook.

Set Permissions allows a user to create permission rules for the workbook.

Permission roles:

Viewer allows the user or group to view the workbook or view on the server.

Interactor allows the user or group to view the workbook or view on the server, edit workbook views, apply filters, view underlying data, export images, and export data. All other permissions are inherited from the user’s or group’s project permissions.

Editor sets all capabilities for the rule to Allowed.

Data sources have two groupings of capabilities, Use and Edit.

Use Edit

View

Connect

Save

Download Data Source

Delete

Set Permissions

The Connector permission role grants all Use capabilities. The Editor permission role grants all Use and Edit capabilities.
Details on data source capabilities and permission roles

The image above shows a row for each of the permission role templates, illustrating which capabilities they grant or deny.

Capabilities:

View allows a user to see the data source on the server

Connect allows a user to connect to a data source in Tableau Desktop, Tableau Prep Builder, or web editing.

Note: If a workbook author embeds their credentials to a published data source in a published workbook, they are essentially embedding their Connect capability. Therefore, users can see the data in the workbook regardless of their own Connect capability for that data source. If the workbook author does not embed their credentials to the published data source, the user needs their own Connect capability to the data source in order to consume the workbook. For more information, see Data access for published Tableau data sources.

Save allows a user to publish data sources to the server and overwrite data sources on the server

Download Data Source allows a user to download the data source from the server (as a .tdsx)

Delete allows a user to delete the data source

Set Permissions allows a user to create and edit permission rules for the data source

Permission roles:

Connector Allows the user or group to connect to the data source on the server.

Editor Allows the user or group to connect to, download, delete, and set permissions on data sources on the server. They can also publish data sources, and as long as they are the owner of a data source they publish, they can update connection information and extract refresh schedules. (The latter two capabilities are no longer available if an administrator or project leader changes data source ownership.)

Note that Flows and Data Roles are part of the Data Management Add-on.

Flows have two groupings of capabilities: Run and Edit.

Run Edit

View

Run Flow

Save

Download Flow

Move

Delete

Set Permissions

The Runner permission role grants all Run capabilities. The Editor permission role grants all Run and Edit capabilities.
Details on flow capabilities and templates

The image above shows a row for each of the permission role templates, illustrating which capabilities they grant or deny.

Capabilities:

View allows a user to view the flow.

Run allows a user to run the flow.

Save allows a user to publish flows and overwrite published flows.

Download flow allows a user to download the flow (as a .tflx).

Move allows a user to move flows between projects. For more information, see Move content .

Delete allows a user to delete the flow.

Set Permissions allows a user to create permission rules for the flow.

Permission roles:

Runner allows the user or group to run the flow on the server.

Editor allows the user or group to publish and manage flows.

Data Roles

Data Roles have one grouping of capabilities: View/Edit.

View/Edit

View

Save

Move

Delete

Set Permissions

The Interactor permission role grants the View capability.

The Editor permission role grants all capabilities.

Details on data role capabilities and templates

The image above shows a row for each of the permission role templates, illustrating which capabilities they grant or deny.

Capabilities:

View allows a user to view data roles.

Save allows a user to publish data roles and overwrite published data roles.

Move allows a user to move data roles between projects. For more information, see Move content .

Delete allows a user to delete data roles.

Set Permissions allows a user to create permission rules for data roles.

Permission roles:

Interactor allows the user or group to view and apply data roles on the server.

Editor allows the user or group to connect to, delete, and set permissions on data roles on the server. They can also publish data roles, and as long as they are the owner of the data role they publish.

Project permissions

Projects organize content and setting permissions at the project level can simplify access management. Characteristics of projects that make them useful for managing content include the ability to create nested hierarchies, hiding projects from certain users or groups, authorizing Project Leaders, and locking permissions for straightforward permissions management.

Note: How permissions are set at the project level is very important, especially for the Default project. When a new top-level project is created it inherits its default permission rules (for all content types)  from the Default project. When a new project is created nested inside another project, the child project inherits its default permission rules from the parent project.

Project administration

Projects are containers used to organize and manage access to content. By giving non-administrators privileges to manage projects, certain content administration tasks can be handled at the project level.

Project Leaders: Projects can have project leaders, users who have been given the Project Leader capability. This capability automatically grants a user their maximum capabilities—depending on their site role—for that project. Project Leaders with site role of Explorer (can publish) and above will have all capabilities. This essentially creates local admins for the project while denying access to site or server settings to users who shouldn’t have it.

Hierarchy: Only administrators can create top-level projects. Project owners and project leaders can create nested projects inside their projects. Project owners and leaders have full administrative access to the project and its content, as well as any nested projects it contains. In a hierarchy, project leaders are implicitly given project leader access to all child content. To remove project leader access, you must do so at the level in the hierarchy where the role was explicitly assigned.

Ownership: A project can have multiple project leaders, but each project has exactly one owner. By default, a project is owned by the user who created it. A project’s owner can be changed (by the existing owner or an administrator, but not a project leader) to any user with a site role of Explorer (can publish) or Creator, or an administrator site role. Project ownership can be changed regardless of whether the project permissions are locked.

Content ownership can be changed by project owners, project leaders, and administrators.

Deleting: Content can only exist inside a project. Only administrators can create and delete top-level projects, but project leaders can create or delete nested projects. Deleting projects also deletes all the content and nested projects they contain. To delete a project without losing its content, move the content to another project first. Deleting projects cannot be undone.

For more information, see Use Projects to Manage Content Access and Add Projects and Move Content Into Them.

Lock project permissions

Whether or not a project’s permissions are enforced for its content is controlled by the Content Permissions in Project setting. This setting can be configured in two ways, either Locked to the project (recommended) or Managed by owner.

  • When permissions are locked to the project, the permission rules set on the project are enforced for all content in the project. Effective permissions are enforced.
  • When permissions are managed by owner, the permission rules set on the project are applied to all content by default but can be modified during or after publication. Effective permissions are preliminary.

Note: it is strongly recommended to lock project permissions to ensure a consistent and clear permission strategy.

To configure the Content Permissions in Project setting:

  1. You must be logged into the site as an Administrator, Project Owner, or Project Leader
  2. Open the permissions dialog box for a top-level project
  3. Click the Edit Content Permissions button and select the desired option in the dialog box that opens

New top-level projects inherit all initial permission rules from the Default project, except for Content Permissions, which is set to Managed by the owner. This can be changed to Locked to the project if desired. Any child project has the same Content Permissions setting as its parent project.

When permissions are locked to the project:

  • The top-level project permission rules are applied to all content and nested projects.
    When locking a project that was previously managed by the owner, any custom permissions on content are overwritten with the permission rules from the project. This cannot be undone once applied. Unlocking the project (converting back to Managed by the owner) leaves the project’s permission rules in place but anyone with the correct capabilities can set new permission rules on content.
  • Content moved into a locked project acquires the project’s permission settings.
  • Only administrators and project leaders can modify permission. Any changes to the top-level permission rules propagates to all content in the project.
  • Content owners lose the Set Permission capability but retain all other capabilities on their content.

When permissions are managed by the owner:

  • The top-level project permission rules are applied by default when content is published into the project or nested projects are created, but permissions can be modified during publication or after the content is created.
  • Content moved into the unlocked project retains its permission rules.
  • Any user with the Set Permissions capability can modify permission rules for that content.
  • Content owners have all capabilities on their content.

Effective permissions

Permission rules establish who is impacted (a user or group) and what capabilities they are granted or denied for content. Permissions are evaluated in a specific order, yielding effective (sometimes called resulting) permissions on a piece of content.

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.

Here are some common examples of why effective permissions—what the user can or cannot 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 does now 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).

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) setting the All User group’s permission rule to None.

A permission rule establishes each capability as Allowed, Denied, or Unspecified. The permissions grid shows the effective permissions for users, which is always either Allowed or Denied. Selecting a group rule above displays all users in that group below in the grid.

For example, here we have a group called “Site Roles” with a user for each site role. A permission rule gives this group Editor capabilities on Workbooks. In the rules area above, we see green checks for every capability. However, in the User Permissions area below, we see that several site roles are missing capabilities. Hovering over a capability brings up a tooltip that explains the effective permission. Here, Explorer, Unlicensed, and Viewer are missing capabilities that are granted by the permission rule because their site role prohibits those capabilities.

A capability is allowed for a user if and only if:

  • that capability is within the scope of their site role
  • AND

  • 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
    • they have been allowed the capability as a user OR
    • 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

    AND

  • there is no conflicting permissions settings at another content level that takes precedence

Any other situation denies the user the capability.

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:

  1. Site role: If a site role does not permit a capability, the user is denied. If the user's site role does permit the capability, then specific user scenarios are evaluated.
  2. 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 will not have the Set Permissions capability in projects where permissions are locked. Only administrators and project leaders can set permission rules in locked projects.

  3. 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.
  4. 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.
  5. 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 project content permissions are managed by owner, 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 only impact new content, they 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 does not show sheet tabs, any changes to the workbook-level permissions will not be inherited by the views and any changes to permissions must be done on the view.
  • Configuring the workbook to show sheet tabs will override existing view-level permissions and sync them with the workbook-level permissions. See Show or Hide Sheet Tabs.

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

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

Save and Download/Save As

In the context of permissions, saving is essentially publishing. As such, the Save and Save As capabilities can only be given to users with a site role of Administrator, Creator, or Explorer (can publish). Explorer or Viewer site roles cannot save or save as.

  • The Save capability for content can be thought of as both publish and overwrite.
  • The Save As capability can be thought of as publishing a copy of that content with any changes made.

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

In web editing, the Save option in the File menu only appears to the content owner. If a user has the Save capability (allowing them to overwrite the content), they need to 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 As 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 saves (overwrites), 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 As is a joint capability for workbooks. Explorers can be given this capability but they are only able to download the workbook, not save as. Giving the Download Workbook/Save As capability to Explorer (can publish), Creator, or Administrator site roles gives them both the ability to download workbooks and save as.

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 cannot publish. Essentially, they can use web editing to answer deeper questions based on existing content on the fly, but cannot save (publish) their edits.
    • Explorers (can publish) or Site Administrator Explorers can save (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. See Set Web Edit, Save, and Download Access on Content.

Required Permission Capability Settings

Desired functionality Minimum Site Role Web Edit Download/ Save As Save (workbook) Save (project) Connect (data source)
Web edit without being able to save Explorer Allow Deny Deny Optional Allow
Web author and save 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 chose 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 cannot 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 Save capabilities) for the destination project
    • Owner of the content, or—for workbooks and flows—having the Move capability.

When a project or content is moved, permissions might change. Project leaders or project owners always gain permissions for items moved into their projects.

  • When items are moved into a locked project, the permission templates for the locked project are enforced on the moved item. Note that this might strip the user moving the item of their ability to move it again if they don’t have the correct permissions in the locked project.
  • When items are moved into an unlocked project (managed by the owner), the existing permissions are retained for the moved item. If the project leader capability on the moved item has only implicitly been granted (from a higher-level project), that capability is removed, though any explicitly set project leader capabilities is retained

Show or Hide Sheet Tabs

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, two conditions must be met. (1) The workbook must be published into an unlocked project and (2) the workbook cannot show sheets as tabs.

When a workbook shows sheets as tabs, all views inherit the workbook permissions and any changes to the workbook permissions affect all of its tabbed views. When a workbook is published without showing sheets as tabs, 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. View-level permissions can be set only on views that are already published, not during the publishing process.

Changing the configuration of sheets as tabs on a published workbook 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.

  • To configure sheets as tabs on a published workbook, open the Actions menu (...) for the workbook and select Tabbed Views. Choose Show Tabs or Hide Tabs as desired.
  • To configure sheets as tabs during publishing, refer to Show sheets as tabs.
  • To set view-level permissions, see Set permissions on content.

Remember, in an unlocked project, any modifications to the workbook-level permissions will not be applied if sheet tabs are hidden.

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