What Is Tableau Row-Level Security? Restricting Data Access by User

Tableau row-level security (RLS) restricts which rows of data each user can see when they view a dashboard. A sales manager who opens the Revenue dashboard sees only their region's revenue; a finance analyst sees all regions. The same workbook, connected to the same data source, delivers different data to different users based on who they are.

Without RLS, organizations typically solve the problem by creating separate workbooks for each audience — a Northeast workbook, a Southeast workbook, a national workbook. This works until workbook sprawl makes maintenance untenable: every change to a shared visualization requires updating dozens of copies. RLS solves the problem at the data access layer instead, maintaining one workbook that adapts to each user.

The Three Core RLS Patterns

Pattern 1: User filters on published data sources

The simplest RLS pattern uses Tableau's USERNAME() function in a calculated field on a published data source. A calculated field like IF USERNAME() = [sales_rep_email] THEN TRUE ELSE FALSE END returns TRUE for the row where the logged-in user's username matches the row's assigned rep. Setting this calculated field as a data source filter (Hide When: FALSE) restricts each user to only their own rows.

This approach works well when:

- Data has a simple one-to-one user assignment (each row belongs to exactly one user)

- The user identifier in the data matches Tableau usernames exactly

- The user list is small enough to manage without a separate entitlement system

Limitations: fragile with username changes, does not handle hierarchical access (a manager who should see their team's rows plus their own), and does not easily handle users who need access to multiple assigned values.

Pattern 2: Entitlement tables

A more robust pattern uses a separate entitlement table — a table that maps each user to the data they are permitted to see. The data source joins the base data to the entitlement table on the user identifier, and a filter on USERNAME() = [entitlement_user_column] restricts rows to those with the current user's entitlement record.

Structure:

- entitlements table: user_email, region (or sales_territory, or account_id, or any dimension the access is based on)

- base data: joins to entitlements on the dimensional key

- filter: USERNAME() = user_email

This approach handles:

- Multiple assignments per user (a manager assigned to three regions has three rows in entitlements)

- Hierarchical access (a VP with the 'All' value can be assigned a sentinel value that the filter treats as "see everything")

- Centralized management: entitlements are managed as data, not as workbook configuration

Pattern 3: Data source permissions and virtual connections

Tableau Cloud's virtual connections and data policies provide server-side row-level security — RLS enforced at the data source level rather than at the workbook level. Data policies are defined on virtual connections by administrators; every workbook connecting to that virtual connection inherits the RLS policy without any workbook-level configuration.

This is the most enterprise-grade approach:

- RLS is centrally administered, not embedded in individual workbooks

- Policy changes propagate to all workbooks immediately

- Workbook developers do not need to implement or maintain RLS logic

- Applicable to Tableau Cloud with licensed virtual connections

Implementing RLS with CONTAINS(USERNAME()) for Group-Based Access

For role-based access where groups of users see the same data subset, Tableau's group membership functions are useful. A user group "Northeast Team" in Tableau Server or Cloud contains all users who should see Northeast data. The filter checks ISMEMBEROF("Northeast Team") rather than USERNAME() = individual email.

Group-based access is easier to maintain than individual username assignments: adding a new user to the correct Tableau group grants access automatically, without modifying any data or workbook configuration.

RLS Performance Considerations

RLS filters execute on every query — the data source query includes the username condition on every view interaction. For live connections to large databases, RLS filters add to query complexity.

For extract-based workbooks, RLS over extracts requires using user-based filtering (not extract-level filtering) — Tableau cannot create a separate extract per user, so the full extract is loaded for each user but filtered in the VizQL layer when rendered. This means RLS does not reduce the extract size or the data transferred to the server; it only restricts what is rendered.

For very high-security requirements where the extract itself must not contain data the user cannot see, server-side row-level security via virtual connections or custom SQL-based filtering at the connection level (requiring separate data sources per user group) provides stronger guarantees.

Common RLS Mistakes

**Using Tableau username strings that do not match data.** The USERNAME() function returns the exact Tableau username — typically the email address used to log in. If the data stores a different identifier (employee ID, username without domain), the match fails and all rows are filtered out.

**Not testing with actual user accounts.** RLS logic is often tested using the "preview as user" feature in Desktop or Server admin, but not validated with actual user logins from the target accounts. Unexpected behavior only surfaces when a real user reports they are seeing the wrong data.

**Forgetting to include the data source filter in all relevant data sources.** A workbook that joins data from two data sources may implement RLS on one but not the other, allowing the unsecured source to expose data through filters or blending.

Our Tableau consulting and managed BI services practices design and implement Tableau row-level security architectures appropriate for organizational access requirements. Contact us to discuss your Tableau security requirements.

A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.