topic Re: Newly added workspace users do not appear immediately in WorkspaceClient().users.list() or SCIM in Administration & Architecture

Newly added workspace users do not appear immediately in WorkspaceClient().users.list() or SCIM API

discuss_darende — Fri, 13 Mar 2026 15:22:55 GMT

Hello,

I’m trying to retrieve the list of users in a Databricks workspace.

I am currently using both the Databricks SDK and the SCIM API:

from databricks.sdk import WorkspaceClient w = WorkspaceClient() users = list(w.users.list())

and also:

import requests import pandas as pd workspace_url = "" token = "" headers = { "Authorization": f"Bearer {token}" } users = [] start_index = 1 count = 100 while True: resp = requests.get( f"{workspace_url}/api/2.0/preview/scim/v2/Users", headers=headers, params={"startIndex": start_index, "count": count} ) resp.raise_for_status() data = resp.json() users.extend(data.get("Resources", [])) if start_index + count > data.get("totalResults", 0): break start_index += count u = pd.DataFrame(users)["userName"].to_list()

What I’ve noticed is that after adding a user to the workspace, I can see that user in the Databricks UI, but the same user does not always appear immediately in either of the methods above.

I understand there may be some delay before the change is reflected, but the delay seems inconsistent. Some users appear relatively quickly, while others take much longer.

I could not find any documentation describing the expected synchronization or refresh delay for workspace user listing.

My questions are:

Is there an expected delay for newly added users to appear in WorkspaceClient().users.list() or in the SCIM /Users endpoint?
Is that delay documented anywhere?
Is there a more reliable or recommended way to retrieve an up-to-date workspace user list?

Any clarification would be appreciated.

Re: Newly added workspace users do not appear immediately in WorkspaceClient().users.list() or SCIM

pradeep_singh — Sat, 14 Mar 2026 05:36:39 GMT

There is no documented delay timing but there is documentation that gives a general idea about the over all delay . I think it could be from few mins to 20-40 mins . The changes are eventually consistent not immediately effective .

The references to delay .

https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/manage-groups#accountconsole-1

(There is a delay of a few minutes between updating a group and the group membership being fully propagated across all systems.)

https://learn.microsoft.com/en-us/azure/databricks/admin/users-groups/scim/aad#provisioning-tips

(The initial Microsoft Entra ID sync is triggered immediately after you enable provisioning. Subsequent syncs are triggered every 20-40 minutes, depending on the number of users and groups in the application.)

Re: Newly added workspace users do not appear immediately in WorkspaceClient().users.list() or SCIM

Ashwin_DSA — Sun, 15 Mar 2026 19:42:05 GMT

Hi @discuss_darende,

I agree with Pradeep here. In practice, there can be a delay before the identity and its memberships are fully visible everywhere, especially if you’re on Azure and using AIM or a SCIM connector from your IdP.

The delay isn’t documented as "SCIM list delay", but the underlying behaviour is documented in terms of identity and group sync.

The same article notes that enabling AIM can take 5-10 minutes to take effect. So, depending on how the user was added and when they authenticate, you may see a delay that appears inconsistent. Sometimes a user shows up in your list of calls almost immediately, sometimes only after the next identity/group refresh window. That’s identity propagation and caching timing, not a separate delay on the /Users endpoint. Those timings are what typically explain why a user appears in the UI first and only later in your SCIM/SDK listing.

Now, to your last question about a reliable or recommended way... I don't think there is anything else. You’re already using the recommended interfaces.

If you still see a user missing from /Users well beyond those windows (for example, > 30 - 40 minutes after:

they exist and are enabled in the IdP,
they’re assigned to the Databricks account/workspace, and
they’ve done at least one SSO login),

Then that’s a good point to open a support ticket with example user IDs and timestamps so Databricks can look at the specific tenant.

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.