Permissions in Project Hierarchies

As an administrator or project leader, you can decide how permissions are set in a project hierarchy you manage. On the top-level project in a hierarchy, you can set the project to one of two available states: locked and managed by owner. Locking permissions can help you maintain a predictable permissions model within a project hierarchy. For example, it denies publishers the option to set explicit permissions on workbooks and data sources they own.

Project permissions states: locked and managed by owner

You can lock permissions in project hierarchies at the top level of the hierarchy. When you lock permissions, the top-level project’s permissions settings are applied to all workbooks, views, and data sources in the hierarchy.

In a locked project hierarchy, only administrators and project leaders with an appropriate site role can modify permissions, and they can do so only on the top level. Publishers cannot set permissions on their content during or after publishing from Tableau Desktop.

When permissions are managed by the owner (“unlocked”), they become editable by content owners and other users with the appropriate access level. During publishing, users have the option to set permissions explicitly on the workbook or data source they are publishing, unless you explicitly deny this capability on groups they are members of or individual users.

To clarify, owners always get full read, write, and other access to the content they publish, but in a locked state, they cannot change permissions on it.

Note: If a workbook, data source, or project with editable permissions is moved to a locked project, the permissions set on the locked project are applied to that content. The moved content’s permissions are then locked.

When to use each state

In general permissions are easier to manage when you lock projects. You need to go only to one place to see how they’re set for all content in that project’s hierarchy.

However, this requires that all child projects have the same permissions as set at the top level. The following common scenarios are possible only when you keep the project hierarchy unlocked

  • You want to create projects for different types of access your team needs for content in child projects. This strategy is described in Configure Projects, Groups, and Permissions for Managed Self-Service, and it requires setting unique permissions on each child project.

    If you keep permissions unlocked, you can still set permissions at a parent project level that you want all new child projects to take by default. You can use groups to set capabilities explicitly, including denying the Set Permissions capability, so that users cannot set permissions on content they don’t own. Users will always be able to set permissions on content they own within unlocked project hierarchies.

  • In web editing, you want to allow publishers to save changes to workbooks but not overwrite them.

    For more information, see Allow users who can publish to edit, save changes to, and download new workbooks, but not overwrite existing workbooks.

How permissions are evaluated in project hierarchies

The following diagram shows how ownership and Project Leader permissions are applied in a hierarchy.

  • PL = Project Leader
  • O = Owner
  • Dotted line indicates implicit permissions “inherited” at a parent level.
  • * = Owner was assigned explicitly by the owner of the parent project.

Diagram showing how permissions are applied in project hierarchies

How permissions are applied in locked project hierarchies

You can lock permission only at the top-level in a project hierarchy, and the following behavior applies:

  • All child projects you create within a top-level project use the default permissions set at that top-level project (not the Default project), and you cannot modify permissions at the child-project level.

  • Workbooks, views, and data sources also use the default permissions set on the top-level project.

  • Users, including content owners, cannot edit permissions for individual workbooks, views, or data sources.

    When users publish workbooks and data sources from Tableau Desktop, they cannot set permissions in the Publish dialog box, and their content gets the default permissions for the project they publish it to.

  • Users or groups that have an appropriate site role and are assigned the Project Leader permissions role at the top-level project get project leader access to all child projects and their workbooks and data sources.

  • Administrators and content owners can change ownership at any level in the hierarchy.

  • Administrators and project leaders can edit permissions at the top-level project, and those changes propagate to all child projects.

How permissions are applied in unlocked project hierarchies

If the top-level project’s permissions are not locked, you can set permissions on its child projects in the same way you can on top-level projects, with the exception of locking the child project.

When you create a child project, it takes default permissions from the parent project. Users implicitly get the same permissions they have on the parent project.

If you set permissions at the child level, those settings take precedence over permissions set at the parent level.

See also

For a couple of best-practice steps for how to implement permissions, see the following:

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