Dashboard Security Control

pragya17
New Contributor III

While creating Databricks Dashboard , can we control the access like a manager can see all employee performances and kpi metrics under it , but an employee can see only its own performance dashboard and its related metrics .

Thanks,

Pragya Sharma

GabFernandes
Contributor

Hi @pragya17,

Yes, this is absolutely possible! Databricks AI/BI Dashboards support Row-Level Security (RLS) natively through Unity Catalog Row Filters — no dashboard-level configuration needed.

How it works:

Create a mapping table defining who can see what:

CREATE TABLE hr.security.manager_access (
  manager_email STRING,
  employee_id  STRING
);
-- Managers have rows for ALL their reports; employees have only their own row

Create a row filter function using CURRENT_USER():

CREATE FUNCTION hr.security.performance_filter(emp_id STRING)
RETURN
  -- Managers: see all employees under them
  EXISTS (
    SELECT 1 FROM hr.security.manager_access m
    WHERE m.manager_email = CURRENT_USER()
      AND m.employee_id = emp_id
  )
  OR
  -- Employees: see only their own record
  emp_id = CURRENT_USER();

Apply the filter to your table:

ALTER TABLE hr.gold.employee_performance
SET ROW FILTER hr.security.performance_filter ON (employee_id);

Publish the dashboard with "Individual data permissions" (not "Shared"). This ensures each viewer's identity is used to evaluate the row filter.

Key points:

  • CURRENT_USER() and IS_ACCOUNT_GROUP_MEMBER() are evaluated per viewer automatically
  • If you publish with Shared data permissions, all viewers see the publisher's data (RLS is bypassed)
  • You can also use IS_ACCOUNT_GROUP_MEMBER('managers') for group-based logic instead of a mapping table
  • No changes needed in the dashboard queries themselves — filtering is transparent at the data layer

If my answer was helpful, please consider marking it as accepted solution!

View solution in original post

adnan_alvee
Databricks Employee
Databricks Employee

Yes, you can Dynamic Views for that. Putting an example below:

Steps:
1. Create an employee-access mapping table containing:
viewer_email
employee_email

2. Create a secured view or apply a Unity Catalog row filter:

CREATE OR REPLACE VIEW hr.employee_performance_secure AS
SELECT p.*
FROM hr.employee_performance p
JOIN hr.employee_access a
  ON p.employee_email = a.employee_email
WHERE lower(a.viewer_email) = lower(current_user());

3. Build every dashboard dataset from this secured view. KPIs and aggregations will automatically reflect the rows authorized for the current viewer.

4. Grant users access to the secured view and dashboard, but do not grant them direct access to the unrestricted base table. Dynamic views can use current_user() and is_account_group_member() for identity- or group-based rules

5. Publish using Individual data permissions, not Share data permissions. With shared permissions, queries run using the publisher’s identity, so viewer-specific row-level security does not apply.