Restrict Access at the Data Row Level

Applies to: Tableau Desktop

When you share workbooks with others by publishing them to Tableau Server or Tableau Cloud, by default, all users who have access to the workbooks can see all of the data shown in the views. You can override this behaviour by applying a type of filter that allows you to specify which data “rows” any given person signed in to the server can see in the view.

This approach for securing data at the row level applies to data sources with live connections and extract data sources whose tables are stored as multiple tables. For more information about storing extract data using multiple tables, see Extract Your Data.

Note: For information on the alternatives you can use to implement row-level security in Tableau, see an Overview of Row-Level Security Options in Tableau(Link opens in a new window) in the Tableau Server Help.

For additional related information, see the whitepaper Best Practices for Row_Level Security with Entitlement Tables(Link opens in a new window).

How user-based filtering works

Suppose you created a quarterly sales report for a set of products over several years, in different geographic regions.

When you publish this report, you want to allow each regional manager to see only the data relevant to his or her region. Rather than creating a separate view for each manager, you can apply a user filter that restricts access to the data based on users’ characteristics, such as their role.

Restricting access to data in this way is referred to as row-level security (RLS). Tableau offers the following approaches to row-level security:

  • Create a user filter and map users to values manually.

    This method is convenient but high maintenance, and security can be tentative. It must be done per-workbook, and you must update the filter and republish the data source as your user base changes.

  • Create a dynamic filter using a security field in the data.

    Using this method, you create a calculated field that automates the process of mapping users to data values. This method requires that the underlying data include the security information you want to use for filtering.

    The most common way to do this is to use a reference (“look-up,” "entitlements," or "security") table that contains this information. For example, if you want to filter a view so that only supervisors can see it, the underlying data must be set up to include user names and specify each user’s role.

    Because filtering is defined at the data level and automated by the calculated field, this method is more secure than mapping users to data values manually.

Adding user filters to data sources

The two methods in the previous section describe ways to add filters to data embedded in workbooks. If multiple workbooks connect to the same data, instead of wrangling filters on each workbook, you can filter the data source, and then connect the workbooks to the data source after you publish it.

Workbooks that connect to your filtered data source expose only the data the user signed in to the server is allowed to see. In addition, all connected workbooks show data refreshes as they occur.

Extracts vs. live connections with user filters

Generally, when using one of the methods described above, RLS with extracts are faster to create and have better performance than RLS with data sources that use live connections.

Requirements for RLS with extract data sources

As mentioned earlier, the first requirement to using RLS with extracts is that the data in the extract should be stored using multiple physical tables. You can configure your extract to have its data stored using multiple physical tables by following Extract Your Data.

In addition to the above requirement, there are some additional considerations to make if you plan to use RLS with your extract. Because extract data stored using multiple tables do not support extract filters and some other functionality that help reduce the amount of data in the extract, you might consider using one of the following suggestions:

  • Connect to data using custom SQL

  • Connect to a database view that already has the appropriate level of filtering

For more information about these suggestions, see Extract Your Data.

Recommended practices for RLS with extract data sources

To effectively perform RLS with extracts, Tableau recommends keeping the number of tables (or database views or custom SQL queries) in your extracts to two. In other words, Tableau recommends that the tables in your extract be comprised of the following types of tables:

  • A data table – this is the "object" table that contains all the data you want to show.

  • A reference table – this is the "look-up" or "entitlements" table that contains the user information and the security groups the users belong to.

By minimising the tables in your extract to these two, you ensure that the only join that Tableau has to perform is between these two tables and thus avoid any duplication of data or "join explosion."

About RLS and previous versions of Tableau

Previously, Tableau was unable to support RLS workflows with extracts because of complications around row duplication and performance. Ultimately, these complications derived from the extract whose data could only be stored and queried as a single table. However, beginning in Tableau 2018.3, you can choose to store the data in your extract using multiple tables and thus enabling a workflow for RLS with extracts as you might have previously done with data sources with live connections.

For a comprehensive discussion about RLS with extracts in Tableau, read the blog maintained by a Tableau Sales Consultant who has extensive experience in this area.

Disclaimer: Clicking these links will take you away from Tableau.com. Although we make every effort to ensure links to external websites are accurate and relevant, Tableau cannot take responsibility or provide support for the external content.

See also

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