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

Projects can be used for navigation, organisation 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 Server. 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 Server 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 organisations have several or more distinct groups of Tableau users, each with its own priorities and leaders. These groups might share some organisation-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.

Why not use sites?

Sites work well when content can remain completely separate during all phases, and there is little to no user overlap. A good (and common) example for using multiple sites is to create a site for each of multiple external clients, whose published content you manage as a consultant or vendor.

Projects allow the flexibility you need to administer shared data and reports, and users who might belong to multiple groups. Projects work better than sites for evolving content from development to staging to production.

Project-level administration

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

Thanks for your feedback!