Configure Projects, Groups and Permissions for Managed Self-Service

Publishing to Tableau Cloud and Tableau Server is easy. For some organisations, it might be a little too easy. There is value in creating a controlled framework before letting creators publish their own content.

To keep things tidy and to make sure people can find and access the right content, it may be useful to configure your site for managed self-service. This means having guidelines and settings in place to ensure content is organised, discoverable and secure without having bottlenecks in the publishing process.

This article lays out a possible path for you as a site administrator to set up your site for managed self-service:

  1. Identify the types of groups and projects you’ll need
  2. Create groups
  3. Remove permissions that will cause ambiguities and establish default permission patterns
  4. Create projects
  5. Lock project permissions

Note: The information provided here is adapted and simplified from practices of Tableau Visionaries and customers who have shared their experiences.

Plan your strategy

Permissions in Tableau consist of rules that are applied to content (projects, workbooks, etc.) for a group or user. These permission rules are built by allowing or denying specific capabilities.

The permission rules interface showing various capabilties allowed and denied

Having a comprehensive plan for your projects, groups and permission rules is useful whether you’re starting anew or making changes. The details are up to you, but there are two important practices that we recommend for all environments:

  • Manage permissions on projects, not individual pieces of content.
  • Assign permissions for groups, not individual users.

Setting permissions at the individual user level and on individual content assets becomes unmanageable quickly.

Use a closed permissions model

General models for setting permissions are open or closed. In an open model, users get a high level of access, and you explicitly deny capabilities. In a closed model, users get only the access they need to do their jobs. This is the model security professionals advocate. The examples in this topic follow a closed model.

For more information on how Tableau permissions are evaluated, see Effective permissions.

Identify the types of projects and groups you’ll need

Designing a structure to accommodate content (in projects) and categories of users (as groups) can be the most challenging part of setting up a site, but it makes ongoing management much easier.

Projects: Projects function both as a unit for managing permissions and as an organisational and navigational framework. Try to create a project structure that balances how people expect to find content and allows for logical permissioning.

Groups: Before you create groups, it can be useful to find common themes in how people interact with content. Try to identify patterns you can use to create groups and avoid one-off permissions for individual users.

Example: Project and group structure

For example, let’s imagine an environment where there is company-wide content that everyone should be able to access, as well as some HR content that needs to be restricted.

Projects include:

  • Acme Corp Conference. This will include data sources and workbooks for ticket sales, dashboards for content strategy and project plans for the company conference.
  • Employee Success. This will include anonymised data sources and workbooks for the internal employee survey
  • Human Resources. This will include HR data sources and workbooks that should only be available to members of the HR team.

Then, groups should match what people need to do:

  • Core Content Creators. This group is for users who can publish to top-level projects and have broad access to data sources, but who don’t need to be able to move or otherwise manage content.
  • HR Content Creators. This group is for users who have access to HR data sources and can publish to the HR project.
  • Business Users. This group is for users who should be able to access the content created by the Core Content Creators, but shouldn’t even know the HR content exists.
  • HR Users. This group is for users who should be able to access content in the HR project but don’t have rights to create or publish content.
  • Core Project Leaders. This group is for users who should be given project leader status on the projects that aren’t HR.

Consider site roles

Remember that permissions are tied to content, not groups or users. This means that you can’t give a group Explore permissions in a vacuum. Rather, the group can be given Explore permissions for a project and its content. Site roles, however, are given to specific users and may define or limit the permissions they can have. For more information on how licences, site roles and permissions tie together, see Permissions, Site Roles and Licences.

Create the groups

While it might be tempting to create the groups and projects as soon as you identify what you need, it’s important to do things in a certain order.

Projects: Projects shouldn’t be created until after the Default project has been properly configured (see the next section). This is because top-level projects use the Default project as a template for their permission rules.

Groups: Groups need to be created before they can be used to build permission rules. Users do not need to be added to the groups yet, but they can be. For more information on creating groups, see Manage Users Using Groups.

For more information on adding users to groups, see Add Users to a Group.

Tip: Creating multiple groups and projects and setting permissions manually can get a little tedious. To automate these processes and make them repeatable for future updates, you can perform these tasks using REST API commands. You can use tabcmd commands for tasks such as adding or deleting a single project or group and adding users, but not for setting permissions.

Membership in multiple groups

It’s possible to include the users in the HR Content Creators and HR Users groups in the Business Users group. This would make it easy to assign permissions to Core Content Users versus Business Users for the majority of content. However, in that scenario, the Business Users group couldn’t be denied any capabilities in the Human Resources folder without denying the HR users as well. Instead, the Business Users group would have to be left as unspecified, and the specific HR Content Creators and HR Users groups would be given their applicable capabilities.

This is because Tableau permissions are restrictive. If the Business Users group was denied certain capabilities, that Deny would override the Allow of another permission rule for users in both groups.

When deciding how group membership should be assigned, it’s important to understand how permission rules are evaluated. For more information, see Effective Permissions.

Remove permissions that will cause ambiguities and establish default permission patterns

Every site has an All Users group and a Default project .

All Users group: Any user added to the site becomes a member of the All Users group automatically. To avoid any confusion with permission rules set on multiple groups, it’s best to remove the permissions from the All Users group.

Default project: The Default project works as a template for new projects in the site. All new top-level projects will take their permission rules from the Default project. Establishing baseline permission patterns on the Default project means you will have a predictable starting point for new projects. (Note that nested projects inherit the permission rules from their parent project, not the Default project. )

Remove the permission rule for the All Users group on the Default project

  1. Select Explore to see the top-level projects on the site.
  2. On the Default project’s Action (…) menu, select Permissions.
  3. Next to the All Users group name, select , and then select Delete Rule….

This lets you establish permission rules for the groups that you have full control over without any conflicting permissions assigned to All Users. For more information on how multiple rules are evaluated to determine effective permissions, see Effective Permissions.

Create permission rules

Now you can set up the basic permission patterns for the Default project that all new top-level projects will inherit. You may choose to keep the Default project’s permission rules empty and build permissions for each new top-level project individually. However, if there are any permission rules that should apply to the majority of projects, it can be helpful to set them on the Default project.

Remember that the permissions dialog for a project contains tabs for each type of content. You must set permissions for each type of content at the project level, or users will be denied access to that content type. (A capability is only granted to a user if they are expressly allowed it. Leaving a capability as Unspecified will result in it being denied. For more information, see Effective Permissions.)

Tip: Every time you create a permission rule at the project level, make sure you look through all the content-type tabs.

Create permission rules as desired:

  1. Click + Add Group/User Rule and start typing to search for a group name.
  2. For each tab, choose an existing template from the drop-down or create a custom rule by clicking the capabilities.
  3. When finished, click Save.

For more information on setting permissions, see Set Permissions.

Example: Project level permissions for each content type

For our example, the majority of projects should be available to most people. For the default project, we’ll use the permission rules templates to give the core content creators publishing rights and everyone else the ability to interact with workbooks and not much else.

GroupProjectsWorkbooksData Sources(Other content)
Core Content CreatorsPublishPublishPublishView
HR Content CreatorsViewExploreViewNone
Business UsersViewExploreViewNone
HR UsersViewExploreViewNone
Core Project LeadersSet as project leadern/an/an/a

This pattern follows a closed model and limits permissions to basic usage for most content for most users. As new top-level projects are created, these rules are what will be inherited by default, but the permission rules can be modified per project as needed. Remember that the Human Resources project should have these permissions removed and its own pattern established.

Create projects and adjust permissions

After the Default project is set with your custom permissions templates, you can create the rest of your projects. For each project, you can adjust the default permissions as appropriate.

To create a project

  1. Select Explore to see the top-level projects on the site.
  2. From the New drop-down, select Project.
  3. Name the project and, if desired, give it a description.

It can be useful to establish a naming convention. For example, a basic structure might be <DepartmentPrefix><Team> - <ContentUse>; such as DevOps - Monitoring.

The description appears when you hover over a project thumbnail and on the Project details page. A good description can help users know they’re in the right place.

  1. Adjust permissions as necessary.
    1. Open the new project.
    2. From the Action menu (...), select Permissions
    3. Modify any permission rules as desired. Remember to check all the content tabs.

Lock content permissions

In addition to permission rules, projects have a content permission setting. This setting can be configured in two ways, either Locked (recommended) or Customisable.

Locking a project is a way of maintaining consistency and ensuring that all content in the project has uniform permissions (per content type). A customisable project permits authorised users to set individual permission rules on pieces of content. For more information, see Lock content permissions.

Regardless of the content permission setting, permissions are always enforced on content.

Possible project structures

Some organisations find it useful to have projects that serve specific purposes. Here are some example projects and their intended uses. Note that these are example templates and you should always test the configuration in your environment.

For information about what capabilities are included with each content type’s permission rule templates, see Permission capabilities.

Examples: permission settings for specific purposes

Workbooks shared for open collaboration on the server

Anyone in the department can publish to the open-collaboration project while their content is in development. Colleagues can collaborate using web editing on the server. Some people call this a sandbox, some call it staging, and so on. On this project you can allow web editing, saving, downloading, and so on.

Here you want not only to enable collaboration, but also to enable people who don’t have Tableau Desktop to contribute and provide feedback.

GroupProjectsWorkbooksData Sources(Other content)
Data StewardsPublishPublishPublishTBD
Business UsersPublishPublishExploreTBD

Remember that some capabilities in the Publish template (such as Overwrite) may be prevented by a user’s site role even if they are allowed that capability.

Note: "TBD" indicates these permission rules aren't easily determined by the scenario and can be set however makes sense for a given environment.

Shared reports that cannot be edited

This could be a project that people who create workbooks and data sources (Analysts and Data Stewards) could publish to when they want to make content available to business users for viewing, with confidence that their work cannot be “borrowed” or modified.

For this type of project, you would deny all capabilities that allow editing or getting the data off of the server for reuse. You would allow viewing capabilities.

GroupProjectsWorkbooksData Sources(Other content)
Data StewardsPublishTBDPublishTBD
Business UsersViewViewNoneNone

Vetted data sources for Analysts to connect to

This would be where Data Stewards publish the data sources that meet all your data requirements and become the “source of truth” for your organisation. Project leaders on this project can certify these data sources, so that they rank higher in search results and are included in recommended data sources.

You would allow authorised Analysts to connect their workbooks to data sources in this project, but not download or edit them. You would deny the view capability to the Business Users group for this project, so those users would not even see this project.

GroupProjectsWorkbooksData Sources(Other content)
Data StewardsPublishTBDPublishTBD
Business UsersNoneNoneNoneNone

Inactive content

Another possibility is to segregate workbooks and data sources that the site’s administrative views show haven’t been used for a period of time. You could give content owners a time limit before their content is removed from the server.

Whether you do this or delete directly from the working projects is up to your organisation. In an active environment, don’t be afraid to be intentional about removing content that is not being used.

GroupProjectsWorkbooksData Sources(Other content)
Data StewardsNoneNoneNoneNone
Business UsersNoneNoneNoneNone

Source for workbook templates

This is a project that people can download from but not publish or save to, where authorised publishers or project leaders make template workbooks available. Templates that have your organisation’s approved fonts, colours, images and even data connections built in can save authors a lot of time and keep your reports looking consistent.

GroupProjectsWorkbooksData Sources(Other content)
Authorised AuthorPublishPublishPublishTBD
Data StewardsNoneNoneNoneNone

Template: Explore

Capability: Download Workbook/Save a Copy

Business UsersNoneNoneNoneNone

Next steps

Besides projects, groups and permissions, other data governance themes include:

User education 

Help all of your Tableau users become good data stewards. The most successful Tableau organisations create Tableau user groups, have regular training sessions, and so on.

For a common approach to orienting users to the site, see Dashboard-based Custom Portals.

For publishing and data certification tips, see the following topics:

Optimise extract refresh and subscription activity

If you use Tableau Server, create policies for extract refresh and subscription schedules, to avoid them dominating the site’s resources. The TC customer presentations by Wells Fargo and Sprint address this subject in detail. In addition, see the topics under Performance Tuning.

If you use Tableau Cloud, see the following topics to become familiar with the ways people can refresh extracts:


Use administrative views to keep an eye on the site’s performance and content use.

Administrative Views

Thanks for your feedback!Your feedback has been successfully submitted. Thank you!