topic Re: Databricks AI/BI Get Session User in Data Engineering

Databricks AI/BI Get Session User

mmsanteago — Wed, 23 Sep 2026 21:46:58 GMT

Hello everyone,

I am currently working with Databricks AI/BI Dashboards and I have a specific requirement regarding user context.

I need to dynamically capture the "session user" (the person who is currently viewing the dashboard) rather than the "execution user" (the owner/creator of the dashboard). My goal is to use this information to apply row-level security based on who is accessing the panel.

I know about the CURRENT_USER() function, but I would like to know:

Is there a specific built-in parameter or function to strictly get the viewer's email/username even if the dashboard is running with owner credentials?
If this is not currently possible, is there any known workaround, or is this feature on the product roadmap?

Thanks in advance for the help!

Re: Databricks AI/BI Get Session User

ivanvyd — Thu, 24 Sep 2026 03:09:06 GMT

@mmsanteago with Share data permissions, queries run using the publisher's permissions, so viewer-based RLS does not apply. Honestly, I'm not aware of a supported dashboard parameter or SQL function that exposes the actual viewer while keeping that execution model.

If per-user security is required, Individual data permissions is the supported approach. Each viewer then queries with their own credentials, and Unity Catalog row filters and column masks are enforced for that viewer.

Re: Databricks AI/BI Get Session User

datarich — Wed, 30 Sep 2026 14:15:09 GMT

Hi, good question. This comes down to how the dashboard is published.

Why current_user() returns the owner

When you publish an AI/BI dashboard you choose one of two data permission modes:

Share data permissions (default): every viewer's queries run with the publisher's credentials. current_user(), is_account_group_member() and any Unity Catalog row filters or column masks are evaluated against the publisher, not the viewer.
Individual data permissions: each viewer's queries run with their own credentials. current_user() returns the viewer, and Unity Catalog row filters and column masks are applied per viewer automatically. Compute access is still provided through the publisher, so viewers don't need permission on the warehouse, only on the data.

There's no separate built-in function or parameter that returns the viewer's identity while the dashboard runs with shared (owner) credentials.

Recommended approach: Individual data permissions plus a Unity Catalog row filter

Put the security logic on the table, not in the dashboard, so it also applies to anyone querying the table directly. For example, with a mapping table of user or group to region:

CREATE OR REPLACE FUNCTION sec.region_filter(region STRING)
RETURN is_account_group_member('finance_all')
  OR EXISTS (
    SELECT 1 FROM sec.user_region_map m
    WHERE m.region = region
      AND (m.principal = current_user() OR is_account_group_member(m.principal))
  );

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

is_account_group_member() checks account-level groups, so use groups synced from Entra ID or created at account level.

Grant viewers USE CATALOG, USE SCHEMA and SELECT on the table, plus SELECT on the mapping table (or wrap it in a view). Granting to a group is easiest. In individual mode, viewers without data access will see errors instead of results.
Republish the dashboard and choose Individual data permissions.
Share it with the relevant users or groups.

How to verify

Add a temporary dataset: SELECT current_user() AS viewer, is_account_group_member('finance_all') AS in_finance, and put it in a counter or table widget.
Open the published dashboard as a test user (or ask a colleague). It should show their email, not yours. If it shows the publisher, the dashboard is still published with shared data permissions.
Check that the row counts differ between two users with different mappings.
Draft dashboards always run with the viewer's permissions, so make sure you test the published version.

Things to avoid

Don't pass the user's email as a dashboard parameter or filter for security. Viewers can change it, so it's fine for convenience but not for access control.

If you need shared credentials (e.g. viewers must not have direct table access)

For dashboards embedded in your own app for external users, the supported pattern is __aibi_external_value. Your backend signs a viewer-specific value into the embed token, and your dataset SQL filters on it. Viewers can't tamper with it.
Otherwise, a common workaround is to keep individual permissions but point viewers at a secure view rather than the base table. The view filters on current_user() / is_account_group_member(), so users only get SELECT on the view.

Roadmap

I'm not aware of any public roadmap item that exposes the viewer's identity under shared data permissions. If it matters for your use case, raise it with your Databricks account team or through the Azure Databricks feedback portal so it's tracked.

Docs

Publishing modes and shared data permissions: https://learn.microsoft.com/en us/azure/databricks/dashboards/share/share
Row-level security in dashboards: https://learn.microsoft.com/en-us/azure/databricks/dashboards/manage/#row-level-security
Unity Catalog row filters and column masks: https://learn.microsoft.com/en-us/azure/databricks/tables/row-and-column-filters
Embedding for external users (__aibi_external_value😞 https://learn.microsoft.com/en-us/azure/databricks/dashboards/share/embedding/external-embed
Worked example of per-viewer security: https://www.databricks.com/blog/beyond-embedding-how-secure-aibi-dashboards-every-viewer

Re: Databricks AI/BI Get Session User

Islam_hoti — Wed, 30 Sep 2026 16:06:52 GMT

Hi,

Short answer: No. There's no built-in function or parameter that returns the viewer's identity while a dashboard runs on the publisher's credentials.

Why: When you publish with Share data permissions (the default, formerly called "Embed credentials"), every query runs as the publisher. So CURRENT_USER() and IS_ACCOUNT_GROUP_MEMBER() check the publisher, not the viewer. That's why row-level security (RLS) logic based on those functions sees the owner.

Workarounds, depending on who your viewers are:

1. Publish with Individual data permissions (best for internal users)

With this option, queries run as each viewer, so CURRENT_USER() returns the viewer. Compute still runs on the publisher's credentials, so viewers don't need access to the SQL warehouse. They only need access to the data. You can then enforce RLS in Unity Catalog:

sql
-- Mapping table: who can see which region
CREATE TABLE sec.user_region_map (user_email STRING, region STRING);

-- Row filter
CREATE OR REPLACE FUNCTION sec.region_filter(row_region STRING)
RETURN IS_ACCOUNT_GROUP_MEMBER('finance_all')
OR EXISTS (
SELECT 1 FROM sec.user_region_map m
WHERE m.user_email = CURRENT_USER()
AND m.region = row_region
);

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

Another option is a dynamic view that joins to the mapping table on CURRENT_USER(). Grant viewers SELECT on the view only, not on the base table. That way they can't get around the filter by querying the table directly.

Tips:

Test with a non-admin account.
Draft dashboards always use the viewer's own permissions, so check the published version.
IS_ACCOUNT_GROUP_MEMBER() looks at account-level groups, not workspace-local ones.

2. If you must keep Share data permissions

There's no supported way to get the viewer's identity in SQL in this mode. Don't use dashboard filters or parameters as a security control, because viewers can change them.

3. If you embed the dashboard in your own app

With external embedding, your backend creates a signed token that includes an external_value. Your dashboard SQL can read that value as __aibi_external_value, and viewers can't change it. Queries still run as the service principal, so CURRENT_USER() won't help here. But __aibi_external_value gives you a trusted per-viewer value to filter on, for example WHERE viewer_scope = __aibi_external_value against an entitlements table. Databricks published a full reference pattern for this in September 2026 (linked below), including internal users via Databricks Apps.

Roadmap: I'm not aware of any public commitment to add a viewer-identity function for shared-credential dashboards. I'd suggest raising it through the Databricks Ideas Portal or with your account team.

References:

Share a dashboard (Databricks docs)
Beyond embedding: How to secure AI/BI Dashboards for every viewer
How to embed AI/BI Dashboards in customer-facing applications

Hope this helps!