--- schema_version: "1" id: 6ecebc05509b65b65c722c8af59460c91b6a74888c6d5d136b2cd2f89fc0d7c2 title: Overview of Row-Level Security Options in Tableau collection: tableau version: next locale: en-gb portal_url: https://docs.salesforce.com/tableau/next/en-gb/server/rls_options_overview.md canonical_url: https://help.tableau.com/v0.0/server/en-gb/rls_options_overview.htm source_site: help.tableau.com content_type: documentation content_hash: 16e716358840ff0fa7ab70b7813c00b54ba6c09ee94a8d780a3e7e81f517f79e description: Overview and comparison of row-level security options in Tableau. --- [Skip to main content](#main-content) # Overview of Row-Level Security Options in Tableau 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](https://help.tableau.com/current/pro/desktop/en-gb/publish_userfilters_create.htm#create-user-filter) 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](https://help.tableau.com/current/pro/desktop/en-gb/publish_userfilters_create.htm#dynamic) 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](https://help.tableau.com/v0.0/server/en-gb/dm_vconn_overview.htm). ## 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](https://help.tableau.com/v0.0/server/en-gb/rls_datasource.htm). ## Row-level security option comparison
RLS optionUseful whenProsCons
Manual user filter
  • You are doing a proof of concept or testing user filtering functionality
  • You are creating a static workbook to use with an unchanging group of users
  • You understand the data security risk of having the permissions set incorrectly
  • Simple at small scales
  • Easy to understand mapping
  • Good for testing
  • High-maintenance
  • Need to update filter and republish as user base changes
  • Permissions must be secured to prevent users from seeing unfiltered data
  • Must be replicated in every workbook
Dynamic user filter
  • You don't have a Data Management licence
  • The data contains information you can use to filter it
  • You understand the data security risk of having the permissions set incorrectly
  • Relatively easy to set up
  • Permissions must be secured to prevent users from seeing unfiltered data
  • Must be replicated in every workbook or data source
Data policy
  • You have a Data Management licence
  • The data contains information you can use to filter it
  • Ease of data security is a significant concern
  • Centralised
  • Secure
  • Low-maintenance
  • Responsibilities for security and analytics can be separated
  • Data Management licence required
RLS in the database
  • Your database has an existing RLS security built into the database
  • You’re not using extracts
  • Might already be built into your organisation’s database
  • Policies can be applied to database clients other than Tableau
  • Must use live queries
  • Might have limitations or requirements. Your IT team can identify them
## 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

↓ No ↓

  

See Use a dynamic user filter