Using projects can simplify permission management through features such as nested project hierarchies, hiding projects from certain users or groups, authorizing project leaders, and locking permissions.

Tip: 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 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 will therefore 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, 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. Note that this refers to project ownership. Content ownership can be changed by project owners, project leaders, and administrators.

Deleting: Content can only exist inside a project. (External assets can exist outside of projects, however. See External assets that are not in projects for information.) 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. External assets that were in the project are not deleted, but are removed from the project and continue to appear in External Assets. To delete a project without losing its content, move the content to another project first. Deleting projects can’t be undone.

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 cannot 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" will appear when Catalog needs to move new or existing external assets to it. Catalog puts new external assets that it discovers into this project, and moves external assets from deleted projects here too. The External Assets Default Project has no permissions rules defined on it by default, so server administrators and site administrators are the only users that can see it without changing the permissions. It cannot 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 will need 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.

Once a permission rule establishes a group or user as a project leader, the templates and capabilities are no longer editable because all capabilities are allowed for project leaders. If a project leader is established on a project that contains nested projects, they will 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 as above but select Remove as Project Leader from the action menu. Once a group or user has been removed as project leader, that permission rule will have all capabilities set to Unspecified. This may mean their access to and capabilities for that project will be removed if there is no other permission rule giving them permissions to the content. To keep their access to the project and its content, they will need to have capabilities set like any other group or user.

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, but nested projects can be configured independently with their own permission rules and 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, as well as 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 will override the existing permission rules and enforce the destination’s permissions.
• Moving assets into a customizable project will maintain the existing permission rules on the asset.

Note: Prior to Tableau Server 2022.3 and Tableau Cloud June 2022, external assets could not 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, above.

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 are not overwritten. Whether or not 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 are not overwritten but they are 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.