Manage Permissions with Projects

Projects can simplify permission management with features such as nested projects, project visibility, non-admin project leaders, and locking permissions.

Tip: How permissions are set at the project level is 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 set as a project leader. This setting automatically grants a user their maximum capabilities—depending on their site role—for that project and all content in that project. Project leaders with site role of Explorer (can publish) and above have all capabilities. Project leaders are essentially local admins for the project without access to site or server settings.

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. (Project leaders can't change project ownership, only content ownership). Projects can be owned by users with a site role of Explorer (can publish), Creator, or administrator. Project ownership can be changed even if a project is locked.

Deleting: Most 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 Tableau content and nested projects they contain. To delete a project without losing its content, move the content to another project first. Deleting projects can’t be undone.

External assets are handled differently. They don’t have to be in a project. External assets aren’t deleted if their project is deleted and continue to appear in External Assets. See External assets that aren’t in projects for more information.

For a deeper dive into project administration, see Use Projects to Manage Content Access and Add Projects and Move Content Into Them.

Special projects

Default: The project named "Default" is a special project. When other top-level projects are created, they use the Default project as a template, and copy all their permissions rules from it (but not the Asset permissions setting). The Default project can’t be deleted, moved, or renamed, but its description can be changed. It has no owner by default, but one can be assigned.

External Assets Default Project: If you have the Data Management license with Catalog enabled, the project named "External Assets Default Project" appears when Catalog needs to move new or existing external assets to it. Catalog puts new external assets and external assets from deleted projects in the External Assets Default Project. The project has no permissions rules by default, so server administrators and site administrators are the only users who can see it unless permissions are added. It can’t be deleted, moved, or renamed, but its description can be changed. It has no owner by default, but one can be assigned.

Set a project leader

Project leaders are users who have administrator-like access for a specific project or project hierarchy.

To assign project leader status to a group or user

1. Open the permission dialog for the appropriate project.
2. Select an existing permission rule, or click + Add Group/User Rule and chose the desired group or user.
3. Open the action menu (...) for that permission rule and select Set Project Leader....

Note: If the action menu includes an option for Enable "Set Project Leader", this needs to be selected before the group or user can be set as a project leader. This option only appears when that group or user was denied the Project Leader capability (prior to 2020.1). That denied capability needs to be removed before they can be set as a project leader.

After a permission rule establishes a project leader, the templates and capabilities can't be edited because all capabilities are allowed for project leaders. If a project leader is established on a project that contains nested projects, they have inherited project leader status on all nested projects and their content.

Project leader status is always applied downward through the entire project hierarchy and can only be removed from the level where it was set. To remove project leader status, follow the same steps but select Remove as Project Leader from the action menu. After a group or user has been removed as project leader, that permission rule has all capabilities set to Unspecified. This may mean their access to and capabilities for that project is removed if there’s no other permission rule giving them permissions to the content. To keep their access to the project and its content, they need to have capabilities set like any other group or user.

Note: Project leaders can refresh extracts in their projects in most circumstances. They can't refresh extracts if they're only the project leader of a nested project (instead of a top-level project) and the top-level project is locked (including nested projects).

Lock asset permissions

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 Asset permissions setting. This setting can be configured in two ways, either Locked (recommended) or Customizable. Locking a project removes the ability for content owners to modify the permission rules on their content. Locking permissions can be applied to nested projects or just to the parent project itself.

• When Asset permissions is Locked (including nested projects), permission rules set at the project level are enforced for all assets in the project and all nested projects.
• When Asset permissions is Locked (not including nested projects), permission rules set at the project level are enforced for assets in the project. Nested projects can be configured independently with their own permission rules and set as locked or customizable.
• When Asset permissions is Customizable, permission rules set at the project level are applied to all assets in the project by default. However, permission rules can be modified for individual assets during or after publishing.

Note: Whether permission rules are locked or customizable, the permissions on content are always applied. Locked and customizable refer only to how project-level permissions are inherited by content in the project and who can change them. Even in a project with customizable permissions, only specific users can modify permissions (content or project owner, project leader, admins, or those with the Set Permission capability).

In a locked project:

• The project permission rules per content type are applied to all assets.
• Only administrators, project owners, and project leaders can modify permissions.
• Content owners lose the Set Permission capability but retain all other capabilities on their content.
• Permissions are predictable for all content in the project.

In a customizable project:

• The 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.
• Any user with the Set Permissions capability can modify permission rules for that content.
• Content owners have all capabilities on their content.
• Permissions can be different across content in the project.

Set asset permissions (lock a project)

New top-level projects inherit all initial permission rules from the Default project but not the Asset permissions setting, which is set to Customizable. This can be changed to Locked if desired.

To configure Asset permissions:

1. You must be logged into the site as an administrator, project owner, or project leader
2. Open the permissions dialog for a project
3. Next to Asset permissions in the upper left, click the Edit link and select the desired option in the Asset permissions dialog

Note: If the upper left corner doesn’t show an Edit link in step 3 above, you may be on the permissions dialog for a (a) nested project or a piece of content in a locked project, in which case the link should bring you to the managing project, (b) piece of content in a customizable project, which won’t show anything, or (c) view, which will indicate how the view permissions are tied to the workbook. For more information on the interplay of permissions for views and workbooks, see Show or Hide Sheet Tabs.

Change asset permissions

When the Asset permissions setting for a project is changed, the outcome depends on the new setting. Changes to permission rules in a locked hierarchy must be done at the level of the managing project.

Changing from	Changing to	Outcome
Locked (including nested projects)	Locked	Doesn’t modify existing permission rules. Any nested projects become customizable.
	Customizable	Doesn’t modify existing permission rules, though they become customizable. Any nested projects become customizable.
Locked	Locked (including nested projects)	Overwrites existing custom permission rules for all nested projects and their content. This can’t be undone.
	Customizable	Doesn’t modify existing permission rules, though they become customizable. Any nested projects retain their content permission settings and permission rules.
Customizable	Locked (including nested projects)	Overwrites existing custom permission rules for content in the project, and all nested projects and their content. This can’t be undone.
	Locked	Overwrites existing custom permission rules for content in the project. This can’t be undone. Any nested projects retain their permission rules and remain customizable.

Move projects and content

Move Tableau content and external assets

When Tableau content or external assets are moved between projects with different permission settings, Asset permissions settings determine the logic of how permissions are applied.

• Moving assets into a locked project overrides the existing permission rules and enforce the destination’s permissions.
• Moving assets into a customizable project maintains the existing permission rules on the asset.

Note: Prior to Tableau Server 2022.3 and Tableau Cloud June 2022, external assets couldn’t be in projects, and permissions on tables were managed through the Table permissions setting of the parent database. Beginning with Tableau Server 2022.3 and Tableau Cloud June 2022, external assets can be in projects. If a database or a table is moved into a project, older settings to control table permissions through the database are ignored, and the database or table permissions follow the logic of other assets.

Move projects

When a project is moved into another project, the permissions settings on the item being moved are maintained unless the destination project is scoped to include nested projects. (Project permissions in this case mean the View and Publish capabilities for the project itself.)

• If the destination project is set to locked (including nested projects), the permissions for the project being moved and its content are overwritten.
• If the destination project is set to locked (not including nested projects), the permissions for the project being moved aren’t overwritten. Whether the moved project is locked or customizable is preserved from its original setting.
• If the destination project is set to customizable, the permissions for the project being moved aren’t overwritten but they’re now editable.

If the project being moved was previously nested under a parent that was locked (including nested projects), when moved, the project takes on the setting of locked (including nested projects) and becomes the managing project for any projects it contains. Note: This is the same outcome if a project is moved to become a top-level project.