In Tableau, is a data source filter enough to stop users seeing rows they shouldn't?

## What a data source filter does A data source filter is defined on the data source rather than on a worksheet. Every sheet using that data source inherits it, and it is incorporated into the query Tableau generates, so it also reduces the work the source does. That makes it the right tool for scoping — this data source is the EMEA sales mart, so exclude everything else — and for keeping analysts from accidentally pulling five years of history when the report covers one quarter. ## Why it is not a security boundary The filter is part of the workbook or data source **definition**, and definitions travel with the artifact. If a user can download the workbook, they open it in Desktop and delete the filter. If they can web-edit, they edit it in place. Either way the connection's credentials — often embedded, often broad — then return every row. Nothing about the filter is enforced by a component the user cannot reach. The same reasoning applies to the older **user filter** approach, where a calculated field compares `USERNAME()` against a hard-coded mapping. It restricts what the view shows, not what the user is entitled to fetch, and it is editable by anyone who can edit the workbook. Tableau's own guidance has long been that these are not a security mechanism unless permissions prevent editing and downloading. ## Mechanisms that actually restrict rows **Filter at extract creation.** An extract filter is materially different from a live data source filter: rows failing it are never written into the `.hyper` file. Remove the filter afterwards and the rows still are not there, because they were never extracted. This is the simplest genuine restriction — one extract per audience, at the cost of maintaining several extracts and refreshing each. **Enforce it in the database.** With a live connection and per-user credentials — not one embedded service account — the database's own row-level security decides what each query can return. Tableau then cannot show what the database will not send, no matter what filters the workbook carries. The cost is a live connection, real per-user authentication into the source, and the concurrency that implies. **Entitlement table plus a user function.** Publish a data source that relates the fact data to an entitlement table mapping users or groups to permitted values, and filter on `USERNAME()` or `ISMEMBEROF()`. Because the rule lives in the **published data source**, and viewers are given connect-only permissions with download denied, the rule cannot be edited by the people it constrains. This is the classic governed pattern and it scales, because entitlements are data you can load rather than filters you hand-edit. **Data policies on virtual connections.** Tableau Server and Cloud support virtual connections carrying data policies that apply row-level rules centrally, so the rule is defined once and applied to every workbook built on that connection rather than repeated per data source. Availability depends on your version and deployment, so confirm before designing around it. ## Permissions are the part people forget Every approach above still depends on the permission model. If viewers can **download** the workbook or the data source, or can **web-edit** it, they can reach around a definition-level rule and can often extract the underlying data wholesale. A row-restriction design is complete only when the accompanying permissions deny download and web-edit for the audience being restricted, and when the credentials embedded in the published connection are scoped no more broadly than the least-privileged audience requires. ## How to answer this in an interview The wrong answer is a confident "yes, use a data source filter." The right answer names the distinction — filters shape queries, permissions and source-side rules control access — then offers the graded options: extract filters for coarse separation, entitlement tables with a user function in a published data source for the general case, database-enforced rules when the source can authenticate each user, and a central data policy when the platform offers one. Mentioning that the design is incomplete without denying download and web-edit is what marks the answer as coming from someone who has actually shipped it.