Share dashboard with external customers

[RJ1]

I’m new to Databricks and still exploring the platform. One of our requirements is to share a Databricks dashboard with multiple external customers (for example, Customer 1 and Customer 2).

The key requirement is data isolation:

• When a user from Customer 1 logs in, they should only see Customer 1’s data in the dashboard.
• When a user from Customer 2 logs in, they should only see Customer 2’s data.
• We do not have control or prior knowledge of which specific user from each customer will log in.

I’ve received a few suggestions so far, including:

• Row-Level Security (similar to how it’s implemented in Power BI or Tableau)
• Service Principals
• Delta Sharing

How to share the dashboard with user who have Databricks account vs who don't?

I’m trying to understand:

• What is the best and recommended approach for this use case in Databricks?
• What are the pros and cons of each option?
• Has anyone implemented a similar setup and can share guidance, architecture patterns, or documentation links?

Thank you!

[KrisJohannesen]

So just to clarify here, you want to control what the users can see but you don’t know who the users are? 
how do you know if a user is coming from customer1 or customer2 in this case? Would you rely on the domains?

users need to be added in UC to see data. So somehow you need to know who they are.

in general, for sharing dashboards I would most likely embed them in a simple app. In the app, make sure that users are not relying on principal permissions but on the users own permissions.

For data control I would rely on ABAC policies with row-filters on the data to let users only see data from their own domain (assuming this is the setup)

[Ashwin_DSA · Accepted solution]

Hi @RJ1 -  Welcome to Databricks Platform!

Great question. This is a very common requirement.

At a high level, you’ll want to separate the concerns:

1. How users authenticate and are identified (who is the user / which customer are they from?)
2. How data is filtered so they only see their own rows (row-level security/ABAC)
3. How the dashboard is actually exposed (inside Databricks vs embedded in your own app)

Identifying which customer a user belongs to: You said you don’t always know in advance which specific user from a customer will log in. In practice, you still need some way to map a user to a customer. That could either be based on email domain mapping or SCIM/identiity providers such as Entra, Okta where groups are managed and you sync those into Databricks/Unity Catalog. Without such mapping, Databricks (or any platform) can’t reliably enforce Customer 1 vs Customer 2 isolation.

Enforcing row-level security: Once you can identify a user’s customer, you can enforce row-level security at the data layer so dashboards work as expected. You can use Unity Catalog with attribute-based access control (ABAC) and row filters on the base tables, or centralise row-level security at the table or view level, which means any downstream dashboards, SQL queries, or notebooks automatically respect that isolation without custom logic per dashboard. This is generally the most scalable and "Databricks-native" approach.

Options for sharing dashboards: A few patterns you can consider depending on whether your external users have Databricks accounts:

a) If your external users have Databricks accounts, you can create then as users in your Databricks account and assign them to the right groups with appropriate entitlements. You can then use ABAC or row filters so that the dashboards are filtered to their customer based on that. You can share Databricks SQL dashboards with those users/groups directly...

b) If your external users don't have Databricks accounts, you can typically introduce an application layer where you can build a lightweight web app/portal (e.g. using your preferred framework) and Use embedded Databricks dashboards. You can authenticate users into apps and determine which customer they belong to and show the bdashboards they are entitled to see. This gives you more control over branding, multi-tenancy, throttling, and you’re not giving direct Databricks UI access to every external user.

c) Delta Sharing is best when you want to share data, not dashboards, with external parties so they can consume it in their own tools (Power BI, Tableau, their own Databricks workspace, etc.). This offloads visualisation to them, but you still centrally manage which rows they get.

Hope this helps. 

If this answer resolves your question, could you mark it as “Accept as Solution”? That helps other users quickly find the correct fix.