Tableau Row-Level Security in Databricks: Unity Catalog Row Filters and Publish Modes
September 9, 2026
In Databricks, a Tableau user filter has no direct import. The rule is rebuilt in Unity Catalog as a row filter, a column mask or a dynamic view, and it evaluates per viewer only when the AI/BI dashboard is published with Individual data permissions. Publish mode, not the filter, decides whether row-level security reaches the person reading the dashboard.
Why the publish mode decides whether row-level security works
Every AI/BI dashboard is published one of two ways. Under Share data permissions, the default, viewers "run queries using the publisher's data permissions", an arrangement that "might expose data to users who have not been granted direct access to it". Under Individual data permissions, "Viewers run queries using their own credentials" and "their data permissions determine what results they can see". Unity Catalog filters separate viewers only in the second mode; in the first, everyone sees the publisher's slice.
| Question | Shared (default) | Individual |
|---|---|---|
| Who runs the query | Publisher or service principal | Each viewer |
| Whose filters apply | The publisher's | The viewer's |
| Viewer needs data access | No | Yes |
| Result cache | Shared | Per user |
Three details save arguments later. Individual data permissions need each viewer to have access to the underlying data, though not workspace membership. Drafts always apply the viewer's own permissions even when the published copy uses shared ones, so an author testing a draft sees per-user filtering published viewers will not get. And the publisher credential can be a service principal rather than a person, which keeps a dashboard off one employee's grants; the API calls it embed_credentials.
How a Tableau user filter is rebuilt in Unity Catalog
Tableau offers two routes to row-level security: map users to values by hand in each workbook, which its own help calls "convenient but high maintenance", or build a dynamic filter from a security field in the data, usually an entitlements table. The dynamic route survives the move, with its logic already next to the data.
| Tableau | Databricks | What changes |
|---|---|---|
Dynamic user filter on USERNAME() | Row filter comparing the column to session_user() | Bound to the table with ALTER TABLE ... SET ROW FILTER, not the workbook |
ISMEMBEROF('Managers') | is_account_group_member('managers') | Account-level groups, not Tableau site groups |
| Entitlements table in the data source | Row filter or dynamic view on the same table | The mapping table becomes a lookup inside the filter function |
| Columns hidden from some users | Column mask via ALTER TABLE ... ALTER COLUMN ... SET MASK | Each column can have one mask |
| Project and workbook permissions | Dashboard ACLs: CAN VIEW, CAN RUN, CAN EDIT, CAN MANAGE | Content and data access become separate |
| Viewer site role | Account user without workspace access, or consumer access | View-only, "with the added benefit of not requiring a special license" |
Unity Catalog gives three mechanisms. Row filters and column masks are SQL user-defined functions bound to one table. Dynamic views gate rows and columns by group membership. For consistent rules across many tables, Databricks documents ABAC policies, which attach at the catalog or schema level through governed tags, as of September 2026. Two limits shape the design: filters and masks cannot apply to a view, and Databricks Runtime below 12.2 LTS does not support them.
The function names change too. Use session_user(), documented as the replacement for current_user() on Databricks SQL and Databricks Runtime 14.1 and above. For group tests, is_account_group_member() is recommended against Unity Catalog data, because is_member() reads workspace-level groups. An ISMEMBEROF("Group Name") calculation becomes a group test inside a filter function, once the group exists at account level.
Who can view a dashboard without a Databricks workspace
A Tableau Viewer site role has three landing places in Databricks. Account members can be granted a view-only copy of a published dashboard, signing in by one-time passcode or single sign-on; users without workspace access are capped at CAN RUN and cannot read workspace-bound catalogs. Consumer access covers people who run dashboards and Genie Agents in a workspace without creating anything.
External embedding is the third, and has the most moving parts: a service principal issues scoped tokens, an admin keeps an approved-domain list, and per-viewer filtering travels in a value dataset SQL reads as __aibi_external_value. It is rate limited to 20 dashboard loads per second, as of September 2026.
What Genie does to your row filters
Published dashboards include a Genie Agent by default, and it inherits the publish mode; the partner-powered AI features page still labels companion Genie Agents Public Preview. One documented behavior deserves a decision rather than a discovery: "When viewers use Genie, their questions are answered from the full dataset query results. If a dataset query includes sensitive columns or rows, that data becomes available to Genie even if it is not shown in visualizations." Trim dataset SQL to what the dashboard needs, and rely on Unity Catalog masks rather than invisibility.
Downloads are a separate switch. Admins can turn off SQL results download and dashboard email subscriptions workspace-wide, a decision to take alongside the publish mode, not after it.
Why Unity Catalog comes first in the plan
Dashboards move first, Unity Catalog is not ready, so old workbooks keep their user filters while new dashboards run on shared permissions, and the rule lives in two systems for months. Every discrepancy then has two suspects. Sequencing the other way costs less: inventory which workbooks carry user filters and which entitlements tables feed them, agree the group model, write and test the filters, then convert dashboards into that.
Access is the change users feel first. A missing chart type gets a workaround; a manager who suddenly sees the whole country files a ticket that morning. Filters and parameters travel a different path, on Tableau parameters in Databricks AI/BI. Feature-level differences are on Databricks AI/BI vs Tableau, and the same problem on a Tableau to Power BI move in Tableau to Power BI for financial services.
What Antares does with row-level security
Access rules are the one layer where a BI migration tool should hand work back rather than finish it. On the Tableau to Databricks AI/BI route, which Antares ships, the Converter is deterministic-first with guardrailed, validated AI steps and flags what it cannot verify instead of guessing. Mapping Tableau users and site groups onto account-level Databricks groups stays a project task, because only your team knows which identity is which.
The Analyzer reads metadata only, never business data, changes nothing in the source environment, and is fully deterministic, with no LLM involved. Antares runs as SaaS or inside your own environment, and where the Converter uses LLM steps your own private endpoints can serve them. Run the free Analyzer to see which workbooks carry user filters.
Sequencing Unity Catalog against the dashboard work is on the migration guide. Sources: Databricks on publish modes, row filters and column masks, external embedding and Genie in dashboards, plus Tableau on user filters and permissions.
← Back to the Tableau to Databricks Migration guide
Related Migration Resources
Frequently asked questions
Is there a Databricks equivalent of ISMEMBEROF?
Yes. Use is_account_group_member() inside a Unity Catalog row filter or dynamic view. It returns true when the connected user belongs to the named account-level group. Databricks recommends it over is_member(), which reads workspace-level groups. The group has to exist at the account level before a filter can reference it.
Which publish mode do we need for row-level security to apply per viewer?
Individual data permissions. In that mode viewers run queries with their own credentials, so Unity Catalog row filters, column masks and dynamic views evaluate against each person. Share data permissions, the default, runs every query as the publisher, so all viewers see the same rows regardless of the filters.
Can someone without a Databricks workspace open a filtered dashboard?
Yes, with limits. Account users granted a view-only copy sign in by one-time passcode or single sign-on and are capped at CAN RUN. They cannot read workspace-bound securables such as workspace-bound catalogs. For viewers outside your account, external embedding passes a per-viewer value that dataset SQL reads as __aibi_external_value.
How do we stop viewers from downloading dashboard data?
Through workspace admin settings rather than dashboard permissions. Admins can turn off SQL results download and dashboard email subscriptions across the workspace. Decide both alongside the publish mode, because a viewer who can run a dashboard can otherwise export its results and share them outside your Unity Catalog rules.