Sometimes, you want to filter data based on the user that is requesting it. For example:
- You want regional salespeople to see sales figures only for their region.
- You want sales managers to see statistics only for salespeople that report to them.
- You want students to see visualisations based only on their own test scores.
An approach to filtering data this way is called row-level security (RLS). There are multiple methods to accomplish row-level security both inside and outside of Tableau, each with its own pros and cons.
Create a user filter and map users to values manually
The simplest way to achieve row-level security in Tableau is through a user filter where you manually map users to values. For example, you could manually map a user named “Alice” to the value “East” so that she only sees rows in the data source where the “Region” column is “East”.
This method is convenient but high maintenance, and attention must be paid to security. It must be done per-workbook, and you must update the filter and republish the data source as your user base changes. When you publish an asset with this type of user filter, you need to set permissions so that users cannot save or download it and remove the filter, thereby gaining access to all of the data.
For more information, see Create a user filter and map users to values manually(Link opens in a new window) in the Tableau Desktop and Web Authoring help.
Create a dynamic user 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. For example, using a calculated field, the USERNAME() function and a “Manager” column in the data source, you could determine if the user requesting the view is a manager and adjust the data in the view accordingly.
Because filtering is defined at the data level and automated by the calculated field, this method is less error prone than mapping users to data values manually. When you publish an asset with this type of user filter, you need to set permissions so that users cannot save or download it and remove the filter, thereby gaining access to all of the data.
For more information, see Create a dynamic filter using a security field in the data(Link opens in a new window) in the Tableau Desktop and Web Authoring help.
Use a data policy
Starting in Tableau 2021.4, when Data Management is enabled in Tableau Server or Tableau Cloud, users with a Creator licence can implement row-level security through data policies on virtual connections. Because virtual connections are centralised and reusable, you can manage row-level security for each connection in one place, safely and securely, across all content that uses that connection.
Unlike the above solutions for row-level security in Tableau, this method doesn't carry the same risk of exposing information if an author neglects to properly secure permissions on the workbook or data source, because the policy is enforced on the server for every query.
Row-level security through virtual connection data policies was developed to address shortcomings of other row-level security solutions. We recommend this solution in most situations where it's an option.
For more information on row-level security using data policies on virtual connections, see About Virtual Connections and Data Policies.
Use existing RLS in the database
Many data sources have mechanisms for RLS built in. If your organisation has already put effort into building row-level security in a data source, you may be able to take advantage of your existing RLS.
It is not necessarily easier or better to implement a built-in RLS model vs building it with Tableau in mind; these techniques are generally leveraged when an organisation has already invested in these technologies and they want to take advantage of that investment, or when they need to apply the same security policies to other database clients in addition to Tableau.
The main benefit of using built-in RLS is that administrators can implement and control their data security policy in one place: their databases.
For more information, see Row-Level Security in the Database.
Row-level security option comparison
|RLS option||Useful when||Pros||Cons|
|Manual user filter|
|Dynamic user filter|
|RLS in the database|
Which row-level security option should I use?
|Does your organisation have a preferred RLS solution in the database that works for this project?||→ Yes →||See Row-Level Security in the Database|
↓ No ↓
Do you have a Data Management licence?
|→ Yes →||See About Virtual Connections and Data Policies|
↓ No ↓
|Is this a proof of concept, a basic user filter test or a static workbook with unchanging users?||→ Yes →||See Use a manual user filter(Link opens in a new window)|
↓ No ↓