SCIM API shows only databricks-sql-access,but Workspace Access is still displayed (grayed out) in UI

Sainath368
Contributor

3 weeks ago

Hi Team,

I'm testing Databricks entitlement automation using the Workspace Groups SCIM API.

I have an Entra ID group that is synchronized to the Databricks Account via SCIM. I'm using a Service Principal authentication to manage workspace-level entitlements through the SCIM Groups API.

I patched the group with the following entitlement:

Sainath368_0-1784035197931.png

When I retrieve the group through the SCIM API, I get the following response:
Sainath368_1-1784035230093.png

Based on the API response, it appears that the group has only databricks-sql-access assigned directly.

However, in the Databricks workspace UI under:

Settings → Identity and Access → Groups → Group01

I see:

  • Workspace Access = Enabled (grayed out)
  • Databricks SQL Access = Enabled

Since Workspace Access is grayed out, it looks like it may be inherited. However, the SCIM API response shows "groups": [], which suggests the group is not a member of another parent group.

My questions are:

  1. Does the SCIM API return only directly assigned entitlements while the UI shows both direct and inherited entitlements?
  2. If Workspace Access is inherited, how can I determine the source of inheritance when the group's groups attribute is empty?
  3. What is considered the source of truth for entitlement automation—the SCIM API response or the workspace UI?

I'm trying to build automation to onboard groups to workspaces and manage entitlements through JSON-driven configuration, so I want to ensure I correctly understand the entitlement model before proceeding.

Thanks in advance for any guidance.

Labels:
0 Kudos

iyashk-DB
Databricks Employee
Databricks Employee

2 weeks ago

What you're seeing is expected, and it comes down to how "Workspace access" is granted right now versus how the other entitlements work.

Right now, every workspace principal automatically inherits the "Workspace access" entitlement through implicit membership in the account's built in users system group. That inheritance doesn't run through the custom group you're PATCHing via SCIM, so it never shows up in that group's SCIM entitlements array. But the UI still reflects it because it's checking the union of everything the user or SP has, direct or inherited, so it shows the toggle as enabled and greyed out. Greyed out just means "this is coming from a group, not assigned directly to this principal," and in this case that group is the implicit users membership, not the group you're managing.

databricks-sql-access behaves differently because it's something you're actually assigning explicitly on your custom group, so SCIM and the UI agree on it.

To answer your three questions directly:

  1. Yes, the SCIM API on a specific group resource only reflects entitlements explicitly set on that group. The UI shows direct + inherited for the principal as a whole, which is why they can disagree.
  2. There isn't a SCIM field that tells you "this came from group X." Under the current default behavior, Workspace access specifically comes from implicit users group membership, not from an inheritance chain you can query. So an empty groups array on your custom group doesn't mean nothing is granting it, it just means it's not this group.
  3. Neither is wrong, they're answering different questions. For entitlements you're explicitly managing (like SQL access on your group), SCIM is authoritative. For Workspace access specifically, under the current legacy model it's an automatic default, not something your group's SCIM state fully controls, so don't treat "empty groups array" as "no access."

If you need Workspace access to be a real, explicitly assignable entitlement that your automation can trust via SCIM instead of an implicit default, Databricks is rolling out exactly that change. Opt in starts June 15, 2026, it auto enables for workspaces that haven't opted in or out on July 27, 2026, and it's enforced for everyone on September 14, 2026. After that migration, Workspace access becomes something you assign per principal like any other entitlement, and the SCIM response should actually match what you set.

0 Kudos