The Compute tab disappears without telling you why
You log into a Databricks workspace. The left sidebar shows Workspace, Repos, maybe SQL — but no Compute. No error banner. No permission-denied toast. The tab is simply absent, as if the feature does not exist in your deployment.
This is a recurring question on Databricks community forums, and the confusion is understandable. The platform does not distinguish between "you lack permission to see this" and "this feature is not enabled." Both states produce the same result: a missing sidebar entry.
The cause is nearly always one of three workspace entitlements, configured at the admin level and inherited through group membership. Databricks uses entitlements — properties assigned to users, service principals, or groups — to gate access to entire feature surfaces. Unlike object-level ACLs that return a 403 when you try to access something, entitlements remove the UI element entirely.
This design means a user who loses access to the Compute tab has no diagnostic signal to work with. They cannot determine whether the tab was removed intentionally, whether their group membership changed, or whether a workspace admin revoked an entitlement from the users group during a policy change. They just see a shorter sidebar.
The three entitlements that matter are workspace-access, allow-cluster-create, and the presence of at least one cluster policy. Each controls a different layer of compute visibility, and misconfiguring any one of them produces the same symptom.
workspace-access gates the entire sidebar, not just Compute
The workspace-access entitlement is the broadest gate. Without it, a user cannot access notebooks, jobs, models, pipelines, or the Compute tab. It controls access to what Databricks calls the "Data Science & Engineering" persona — essentially everything outside of Databricks SQL and the consumer dashboard experience.
By default, every workspace user inherits workspace-access through the built-in users group. All workspace users and service principals are automatically added to this group. The problem arises when a workspace admin modifies the users group entitlements, often while trying to implement a consumer-access model.
Databricks offers a feature called "Change default workspace access to Consumer access" that strips workspace-access and databricks-sql-access from the users group and reassigns them to a cloned group. The intent is to give new users a read-only consumer experience by default. But if existing users are not added to the cloned group, they lose their workspace-access entitlement and the Compute tab vanishes.
You can check this with the SCIM API:
``bash
curl --netrc -X GET \
https://``
The response should include an object with "value": "workspace-access". If it is missing, the user cannot see the Data Science & Engineering workspace at all. The fix is to either add the user to a group that carries the workspace-access entitlement, or assign it directly through Settings > Identity and access > Users > [user] > Entitlements.
This is also relevant for SCIM-provisioned users synced from Microsoft Entra ID. If automatic identity management is enabled, users appear in the account console but with an "Inactive: No usage" status until they are explicitly assigned to a workspace with entitlements.
allow-cluster-create controls the Create button, not the tab itself
A user with workspace-access can see the Compute tab. But seeing it and being able to create clusters are different permissions. The allow-cluster-create entitlement — labeled "Allow unrestricted cluster creation" in the admin UI — determines whether the user can provision compute resources without restrictions.
Workspace admins receive this entitlement by default, and it cannot be removed from admin accounts. Non-admin users do not receive it unless explicitly assigned. This is a deliberate security boundary: unrestricted cluster creation means a user can spin up any cluster configuration, including expensive GPU instances or clusters with permissive network access.
Without allow-cluster-create, the Compute tab still appears, but the user can only create clusters through assigned cluster policies. If no policies are assigned, the user sees the Compute page with no Create button or a grayed-out interface. This is the specific scenario that trips up many teams: the tab is visible, but it looks broken.
The API name for this entitlement is allow-cluster-create. You can assign it via SCIM:
``json
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [
{
"op": "add",
"path": "entitlements",
"value": [
{
"value": "allow-cluster-create"
}
]
}
]
}
``
Most production workspaces should not grant unrestricted cluster creation broadly. The better approach is to keep this entitlement restricted to admins and use cluster policies to give users controlled access to specific compute configurations. But if you use policies, you must actually assign them — which brings us to the third failure mode.
Cluster policies are the missing middle layer
Cluster policies sit between "no compute access" and "unrestricted compute access." They define a set of rules that constrain the configuration options available when creating a cluster. A user without allow-cluster-create but with an assigned cluster policy can create clusters within those constraints.
Databricks provides a built-in Personal Compute policy that allows single-machine compute resources. By default, all users have access to this policy. But workspace admins can revoke it, and custom policies require explicit assignment.
The failure pattern works like this: an admin removes allow-cluster-create from a user group to enforce cost controls, intending users to rely on cluster policies instead. But they forget to assign any policies to the group. The user opens the Compute tab and sees existing clusters they have permission to use, but has no way to create new ones. In some UI states, this manifests as the Create Compute button being entirely absent.
To check which policies a user can access, use the Cluster Policies API:
``bash
curl --netrc -X GET \
https://``
This returns policies visible to the calling user. An empty list confirms the user has no policies assigned and no unrestricted creation entitlement.
The fix is to create a cluster policy that matches your cost and security requirements, then assign it to the appropriate group. A minimal policy that allows only single-node clusters with a specific instance type gives users the ability to run notebooks without risking runaway costs. The key point is that removing allow-cluster-create without assigning a policy creates a dead zone where users can see compute but not create it.
SCIM sync and Entra ID can silently revoke entitlements
For organizations using Microsoft Entra ID (formerly Azure AD) with SCIM provisioning, entitlement changes can happen without any workspace admin taking direct action. SCIM sync is designed to be the source of truth for identity and group membership. If a user's group membership changes in Entra ID, the next SCIM sync propagates that change to Databricks.
Consider this sequence: a user belongs to a "Data Engineers" group in Entra ID that maps to a Databricks group with workspace-access and allow-cluster-create entitlements. An identity admin removes the user from "Data Engineers" in Entra ID for organizational reasons — maybe they moved teams, maybe it was a cleanup. The next SCIM sync removes them from the corresponding Databricks group. Their entitlements, inherited from that group, disappear. The Compute tab vanishes.
The user opens a ticket saying the platform is broken. The workspace admin checks the user's direct entitlements and sees nothing wrong — because the entitlements were inherited, not direct. The admin would need to check group membership to find the gap, and by then the SCIM sync has already removed the association.
Databricks also introduced automatic identity management for accounts created after August 2025, which uses Entra ID as the source of record without requiring a manual SCIM connector. Changes to users or group memberships in Entra ID are respected automatically. This is more convenient but also means entitlement changes propagate faster and with less visibility.
The diagnostic approach is to query the user's full group membership and trace which groups carry which entitlements. The SCIM Users API returns a groups array for each user, and the Groups API returns entitlements for each group. Cross-referencing these two responses reveals whether the user lost access through a group change rather than a direct entitlement revocation.
MetricSign monitors Databricks job outcomes and surfaces failures with root cause context, including jobs that fail because the owning service principal's entitlements were revoked during a SCIM sync — a failure mode where the job error message says "permission denied" but the actual cause is an identity change three layers removed from the workspace.
A diagnostic sequence that saves you the support ticket
When a user reports a missing Compute tab or an inability to create clusters, work through this sequence before escalating.
First, confirm the user has workspace-access. Navigate to Settings > Identity and access > Users, select the user, and check the Entitlements tab. If workspace-access is not toggled on and not inherited from a group, that is your answer. The entire Data Science & Engineering sidebar is hidden.
Second, if the Compute tab is visible but creation is disabled, check allow-cluster-create. This entitlement is labeled "Allow unrestricted cluster creation" in the UI. If it is not assigned, the user depends entirely on cluster policies.
Third, verify cluster policy assignment. If the user has neither allow-cluster-create nor any assigned cluster policies, they are in the dead zone. Assign at least the Personal Compute policy, or create a custom policy that matches your governance requirements.
Fourth, check group membership for SCIM-managed users. Entitlements inherited from groups do not show as directly assigned. The toggle appears selected but grayed out in the UI when inherited. If the toggle is off and not grayed out, the entitlement was never assigned through any path.
Fifth, for service principals running scheduled jobs, the same entitlement rules apply. A service principal without workspace-access cannot execute jobs that reference workspace objects. This produces cryptic job failures that look like permissions errors on specific objects when the real problem is a missing top-level entitlement.
The Stack Overflow 2024 developer survey shows Databricks SQL at 1.9% adoption among professional developers — a small but growing user base where workspace administration knowledge is still accumulating. These entitlement interactions are not edge cases; they are the standard configuration model. Understanding them prevents the 2 AM call where a production job fails because someone cleaned up an Entra ID group.