Skip to the page
Tecyfy

Databricks interview question · medium

You publish a Databricks AI/BI dashboard for 12 regional managers, and each should see only their own region. After publishing, a manager in the North tells you they can see every region's numbers. What went wrong, and how do you set it up correctly?

The short answerThe dashboard was published with the default Share data permissions, so every viewer's queries run with your permissions, and you can see all regions.

The full answer

The dashboard was published with the default Share data permissions, so every viewer's queries run with your permissions, and you can see all regions. A dashboard filter is not security either: a viewer can change it. Put the rule on the data with a Unity Catalog row filter on region, give each manager access to the table, and publish with Individual data permissions so each manager's own identity is applied when the queries run.

1. Why the manager saw everything

Publishing optionWhose permissions run the queriesResult here
Share data permissions (default)The publisher'sEveryone sees what you see: all 12 regions
Individual data permissionsEach viewer's ownEach manager sees what their grants and row filters allow

Compute always runs on the publisher's credentials, so managers do not need warehouse access in either mode. The draft dashboard always uses the viewer's permissions, which is why your testing in draft may have looked correct.

2. Put the rule on the table

-- 1 group per region, or a mapping table of manager to region
CREATE FUNCTION sales.security.region_filter(region STRING)
RETURN is_account_group_member('sales-admins')
    OR is_account_group_member(concat('region-', lower(region)));

ALTER TABLE sales.gold.orders SET ROW FILTER sales.security.region_filter ON (region);

Now any query on orders by a member of region-north returns only North rows, whether it comes from this dashboard, a notebook, Genie or an export. Keep the function simple; row filters run for every row, and simple SQL expressions are the fastest. If many tables need the same rule, an ABAC policy on a governed tag applies it to all of them; a dynamic view is the option when managers should only ever see a curated, joined version.

3. Grant and publish

  1. Grant the managers' groups SELECT on the table (and USE CATALOG, USE SCHEMA).
  2. Publish with Individual data permissions.
  3. Share the published dashboard with the managers' groups.
  4. Test as a manager, not as yourself: open the published version with a test account in region-north.

4. When Share data permissions is the right choice

For a company-wide dashboard where every viewer may see the same numbers, including people with no access to the tables, Share data permissions is simpler: nobody needs grants, and you can publish with a service principal's credentials so it does not depend on your personal account. It is the wrong choice whenever viewers must see different data.

What interviewers want: the difference between the 2 publishing options, why a dashboard filter is not access control, a row filter enforced in Unity Catalog for every tool, testing as the viewer, and when shared permissions are appropriate.

Last updated 16 October 2026

Sources

Where each fact comes from

  1. 1Share a dashboard
  2. 2Row filters and column masks