When Tableau Desktop users publish content to a site on Tableau Cloud, they can select a project to publish it to.

Projects can be used for navigation, organization, and access management for content like workbooks, data sources, Ask Data lenses, and nested projects.

The following image shows content within the top-level Operations project in the web authoring environment. The Operations project contains a few nested projects (highlighted) and published workbooks. A project can also contain other content types, such as data sources and flows.

Why use projects

Projects help you to create a scalable process for managing access to the content published to Tableau Cloud. Advantages they have include:

  • They enable administrators to delegate content management to project leaders who work with the content more closely, without having to give them administrator access to site or server settings.
    • Project leaders can create nested projects under their top-level project, enabling them to maintain their team’s content within a single hierarchy.
    • Note: Project owners can delete top-level projects they own. Project leaders cannot delete top-level projects.
  • They can make the site easier to navigate for self-service users.
    • They segment the Tableau Cloud site into areas that give users access based on how they use the data published to those areas, or on the Tableau user group they work with.
    • You can hide projects from groups who don’t need to use them, create a distinguishable project-naming scheme, and take advantage of project descriptions to clarify how to use the project.
  • They enable you to track permissions effectively.
    • You can create groups based on the level of content access users in the group need, and set default permissions on projects. This enables you to know exactly which capabilities new users get by default, and likewise which capabilities all users get when a new project is created.

When to create project hierarchies (example)

Many organizations have several or more distinct groups of Tableau users, each with its own priorities and leaders. These groups might share some organization-wide content (or even draw from an org-wide pool of data sources), but primarily they use data and reports that are specific to their team. In this or similar scenario, an example for using project hierarchies might look as follows:

  1. You, as a site or server administrator, can create top-level projects for each of your distinct Tableau teams.
  2. On each top-level project, you assign the Project Leader status to team leads, and change project ownership. Project leaders effectively are the content administrators, so it’s important that they understand how permissions work in Tableau, along with Tableau content management best practices.
  3. Each project leader can manage their project, creating the structure within the project that works for their team. That is, they can create child projects they need, based on how their team members collaborate and share data and reports.

The benefit to you as the site administrator is that you can focus on system health. The benefit to your Tableau users is that people who know the best practices for working with Tableau and data can manage these things for their teams, without having to submit IT requests to change permissions or add projects.

Project-level administration

For more information about administering projects, see Manage Permissions with Projects.

Thanks for your feedback!