Tableau Server on Linux Help

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 and group sets
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.

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) or categories of groups (in group sets) 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 or group sets: 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 or group sets and avoid one-off permissions for individual users.

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 and group sets

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 about creating groups and adding users to them, see Groups and Add Users to a Group.

Group sets: 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, see Work with Group Sets.

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.

Impact of group sets

If assigned permissions are enabled at the group set level, permissions for every group in the group set must not be specified or not be denied to allow the capability.

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.

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.

4. 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.

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:

• Use Certification to Help Users Find Trusted Data

• Prepare for Publishing a Workbook(Link opens in a new window) (links to Tableau Help)

• Best Practices for Published Data Sources(Link opens in a new window) (links to Tableau Help)

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:

• Keep Data Fresh

• Use Tableau Bridge to Expand Data Freshness Options

Monitoring

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

Administrative Views