Queries as the user (Azure Databricks)

By default Qry reaches a database with one credential per datasource (a personal access token or a service principal), and Qry's own permissions decide what each person may read. With queries as the user — also called on behalf of (OBO) — a person's queries reach Azure Databricks with that person's own Microsoft Entra identity. Then:

• Unity Catalog's grants, row filters and column masks apply to each person, exactly as in Databricks itself.
• Databricks' audit log names the person, not Qry.
• Qry's permissions still apply on top. Turning it on never gives anyone more access than they had.

Today it is available for Azure Databricks with Microsoft Entra sign-in. Other engines keep the datasource's credential.

Before you start

1. Users sign in to Qry with Microsoft. Entra must be configured as the sign-in provider (OAuth single sign-on). Someone who signs in with a password or with Google cannot use a datasource that runs as the user.

2. The same people exist in the Databricks workspace. On Azure this is normally automatic (SCIM provisioning from Entra).

3. Qry's app registration may act for users in Azure Databricks. It needs the delegated permission AzureDatabricks › user_impersonation, with admin consent. From the Azure CLI, signed in as an administrator of the tenant:

   # Qry's app registration (the client id configured in Qry's Entra settings)
   APP=<application (client) id>
   # AzureDatabricks and its user_impersonation scope
   az ad app permission add --id $APP \
     --api 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d \
     --api-permissions 739272be-e143-11e8-9f32-f2801f1b9fd1=Scope
   az ad app permission grant --id $APP \
     --api 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d --scope user_impersonation

   az ad app permission admin-consent can return without creating the grant. permission grant does create it. Check it with az ad app permission list-grants --id $APP.

No second consent screen is shown to users: Qry uses the sign-in they already did.

Turn it on for a datasource

In Admin › Datasources, edit the Databricks datasource and set Run users' queries as to Each user (Microsoft sign-in).

• Keep the datasource's own credential (token or service principal). Qry still uses it for its own work, where no person is involved: reading the schema each night, profiling, search. Those features keep working, and the credential never runs a person's query.
• Test checks the credential, then connects as you and reports whom Databricks sees ("Running as you, Databricks sees ana@company.com").

A common setup is two datasources on the same workspace: one that runs as each user, for people, and one with a service principal for production jobs (see Production jobs).

How access is decided

Both Qry and Databricks have to allow something. Effective access is their intersection.

	Qry decides	Databricks (Unity Catalog) decides
Reading	Which datasource, catalogs, schemas and tables a person may use (Qry's grants)	Which of those they can actually read, with which rows and masked columns
Browsing the catalog	What the catalog browser may show	What it lists: the engine only returns what the person can see
Writing (Lakeflow sql tasks)	Whether the person may write at all (a write grant on the datasource)	Which objects they may create or modify

Admins in Qry are still subject to Databricks: a Qry admin who is not a workspace admin cannot read what Unity Catalog denies them.

What the assistant knows about tables comes from Qry's grants

The table and column names the assistant is given come from Qry's schema cache, which is read with the datasource's own credential and filtered by Qry's grants, not by Unity Catalog. A person granted a whole catalog in Qry, but only some of its tables in Databricks, can therefore see the names of tables Unity Catalog hides from them. Never their data: every query is still refused by Databricks. Until Qry reads that context as each person, keep Qry's grants as narrow as the Databricks ones where table names themselves are sensitive.

Qry's write grant is datasource-wide

For sql tasks Qry checks a write grant on the whole datasource. A write grant on one catalog or schema does not count. This is deliberate: Qry cannot reliably tell from a statement's text which objects it writes, so "which schema" belongs to Unity Catalog. Give write on the datasource to the people who build ETL, and limit what they can write with Databricks grants.

What runs as whom

Feature	Runs in Databricks as
Conversations (queries, the catalog tool, Unity Catalog tool)	The person asking
Notebooks (SQL and Python cells)	The person running them
Catalog browser, table sample and details	The person browsing
Dashboards	The person viewing — each viewer sees their own data
Public dashboard links	Nobody: they show a snapshot, taken by the owner as the owner
Scheduled notebooks and tasks	Their owner
Lakeflow sql tasks	Their author (see below)
Nexus data products	The product's owner (by design: a product is shared on the owner's terms)
Schema refresh, profiling, search index	The datasource's own credential

A feature that cannot run as a person yet refuses rather than using the datasource's credential: "… runs queries as each user, and this feature cannot do that yet. Use it from a conversation or a notebook."

Lakeflow sql tasks

A sql task runs its statements inside Databricks. On a datasource that runs as the user:

• Its author can run it without being a Qry admin, as long as they have write access to the datasource in Qry. The statements reach Databricks with the author's identity, so Unity Catalog decides what they may create or change, as if the author ran them in Databricks.
• With read access only, the task is refused ("needs write access to it in Qry").
• Anyone else running it (a job in triggering user mode started by somebody else, or a service account) still needs the owner and the runner to be admins, as on any other datasource. Nobody runs, with their own permissions, SQL they did not write.

On a datasource with a shared credential, sql tasks still need an admin owner and runner.

Production jobs

A job that runs as a person depends on that person's Microsoft account. It stops if the person leaves the company, their account is disabled, their sessions are revoked, or their sign-in goes unused for 90 days (each run renews it, so this only affects jobs that run very rarely). When that happens the job fails with "Qry cannot act for them now … If they have left, give the job another owner". It never falls back to another credential.

So, as Databricks itself recommends, production jobs should run as a service principal, not a person:

Use	Datasource	Identity	Owner
Exploration, conversations, personal and development jobs	… (as user)	Each person	The person
Production ETL	… (ETL)	A Databricks/Entra service principal (OAuth M2M)	An admin

Give the service principal only the Unity Catalog grants the pipeline needs (for example read bronze, write silver and gold). Databricks' audit then names it.

When a job fails because Qry cannot act for its person, the owner gets the usual failure notification and every admin gets one notification per job per day, so a job whose owner has left does not fail unnoticed.

Before a pilot

• Review the Unity Catalog grants. With this mode they are the real gate. A catalog where account users holds MODIFY lets every user with a write grant in Qry modify it.
• Ask which Conditional Access rules apply to Azure Databricks. Qry asks for each person's Databricks token silently. A rule that requires MFA, a managed device or a network at that moment can refuse it; the person is asked to sign in to Qry again, meeting the check. Test with a user subject to those rules.
• Grant access in Qry as usual. A new datasource appears in Admin › Access once it is created and its connection test passes.
• Test with a non-admin user who is not a workspace admin, and check that something Unity Catalog denies is denied in Qry too.

Troubleshooting

Message	Cause	What to do
Sign out and sign in again with Microsoft so Qry can do that.	The person did not sign in with Microsoft, or signed in before this was turned on	Sign out and sign in with Microsoft
Your Microsoft session has expired. Sign out and sign in again to Qry.	The stored sign-in expired (90 days unused) or was revoked	Sign in again
An Entra administrator has to grant consent to Qry's app.	The app registration lacks the AzureDatabricks permission or its consent	See Before you start, step 3
Your organization requires an extra check (such as MFA or a managed device)…	Conditional Access on Azure Databricks	Sign in again meeting the check; if it persists, review the rule for Azure Databricks
INSUFFICIENT_PERMISSIONS / PERMISSION_DENIED from Databricks	Unity Catalog denies it to that person	Expected: grant it in Databricks if they should have it
Access denied: You don't have permission to access this datasource	Qry's own grants	Grant access in Admin › Access
… needs write access to it in Qry (sql task)	The author has read access only	Give write on the datasource, if they should build ETL