A silent button is worse than an error message
You open Databricks, click Create, and nothing happens. No error toast. No red banner. No entry in the event log. The button might be greyed out, or it might appear fully clickable but swallow your click without feedback. This is one of the most common complaints on the Databricks Community forums, and it frustrates experienced engineers precisely because Databricks usually does surface errors clearly — PERMISSION_DENIED, INVALID_STATE, RESOURCE_LIMIT_EXCEEDED all arrive with codes you can search. A dead button gives you nothing to search.
The root cause is almost never a browser bug, though that's where most people start troubleshooting. The real problem is that Databricks evaluates multiple authorization layers before rendering interactive UI elements, and when any layer returns a deny, the frontend disables the control without telling you which layer blocked it. This behavior is by design — the UI hides actions you can't perform — but it backfires when you believe you should be able to perform them.
The 'Create' action spans several resource types: notebooks, clusters, jobs, SQL warehouses, Delta Live Tables pipelines, and workspace folders. Each has its own permission model. A user who can create notebooks might not be able to create clusters, and the single 'Create' dropdown in the workspace UI gates multiple resource types behind a single control. When the most privileged creation action (usually cluster creation) is denied, the entire button can become unresponsive depending on your workspace version and UI state.
Five authorization layers that gate the Create action
Databricks stacks five distinct authorization checks that can each independently block resource creation. Understanding the hierarchy saves hours of trial and error.
Layer 1: Workspace access entitlement. Before any resource-level permission matters, the user or group must have the workspace-access entitlement enabled. Without it, the Databricks API returns PERMISSION_DENIED: The user does not have access to Databricks Workspace on every call. This entitlement is managed in the account console under User Management, not in the workspace itself. It's frequently missed when users are added to groups that have folder-level permissions but lack the workspace entitlement.
Layer 2: Unrestricted cluster creation. The allow-cluster-create entitlement lets a user create clusters without needing a cluster policy. If this entitlement is absent and no cluster policy grants creation rights, the compute creation path is blocked entirely. Check this in Admin Settings → User entitlements.
Layer 3: Cluster policy assignment. Even without unrestricted creation, a user can create clusters if they have CAN_USE permission on at least one cluster policy. If your admin defined policies but didn't assign them to your group, the policy dropdown won't appear and the creation form won't render. Verify with databricks cluster-policies list via the CLI.
Layer 4: Account subscription state. On Azure Databricks, a lapsed or unlinked subscription silently disables workspace actions. The account console at accounts.azuredatabricks.net shows subscription status. Free Edition users hit this wall when their trial compute quota is exhausted — the UI doesn't explain that serverless compute is all that's available on the free tier.
Layer 5: Unity Catalog metastore admin role. For actions that touch governed resources (creating catalogs, schemas, external locations), the CREATE CATALOG or CREATE SCHEMA privilege must be granted explicitly. The metastore admin role inherits these, but workspace admins do not automatically become metastore admins.
The diagnostic sequence that resolves 90% of cases
Run these checks in order. Stop at the first failure — that's your root cause.
First, verify the workspace entitlement. In the account console, navigate to Users, select the affected user, and confirm Workspace access is toggled on. Alternatively, use the SCIM API: GET /api/2.0/preview/scim/v2/Users/{id} and look for urn:ietf:params:scim:schemas:extension:workspace:2.0:User with the workspace-access entitlement present.
Second, check compute entitlements. Run databricks current-user me via the Databricks CLI. The response includes an entitlements array. Look for allow-cluster-create or allow-instance-pool-create. If neither is present, you need a cluster policy.
Third, list accessible cluster policies. Run databricks cluster-policies list --output json. If the result is an empty array, you have no policies assigned. Ask your admin to grant CAN_USE on an appropriate policy, or request the allow-cluster-create entitlement.
Fourth, test the API directly. Bypass the UI entirely: databricks clusters create --json '{"cluster_name": "test", "spark_version": "14.3.x-scala2.12", "num_workers": 0, "node_type_id": "Standard_DS3_v2"}'. The API error message is far more specific than the silent UI. A 403 with PERMISSION_DENIED confirms an authorization gap. A 400 with INVALID_PARAMETER_VALUE means you have permission but the configuration is wrong.
Fifth, clear browser state as a last resort. Hard refresh with Ctrl+Shift+R, clear cookies for .azuredatabricks.net or .cloud.databricks.com, and try an incognito window. The Databricks frontend caches entitlement state aggressively, and a stale session token can present a UI that doesn't reflect recent permission changes. This actually resolves the issue more often than you'd expect — particularly after an admin has just updated your entitlements.
Free Edition and Community Edition hit different walls
If you're on Databricks Free Edition (launched mid-2025, replacing the older Community Edition), the 'Create' button behavior has its own quirks. Free Edition restricts you to serverless SQL compute. You cannot create all-purpose clusters or job clusters. The Create menu still shows these options in some UI versions, but selecting them leads to a form that won't submit.
Community Edition, which Databricks is actively deprecating, had a single shared cluster per user. If that cluster was already terminated and the backend couldn't provision a replacement (common during high-demand periods), the Create button would appear functional but the cluster creation would fail silently on the backend. The only way to see the failure was to check the Events tab on the Compute page.
For production workloads, neither edition is appropriate. But many engineers start learning on Free Edition, build notebooks, and then hit the create wall when they try to attach compute. The migration path is to upgrade to a paid workspace, which requires linking a cloud provider account (AWS, Azure, or GCP) with valid billing. After the upgrade, existing notebooks carry over but cluster configurations do not — you'll need to create new compute resources under the paid workspace's policies.
The Stack Overflow 2024 Developer Survey shows Databricks SQL at 1.9% adoption among all respondents. That number understates the platform's presence in enterprise data teams, where Databricks is often the primary compute layer. But it does explain why community troubleshooting resources are thinner than for PostgreSQL or MySQL — fewer people publicly posting means fewer solved threads to find when your button breaks at 2 AM before a Monday morning stakeholder review.
When a broken button cascades into broken pipelines
A non-functional Create button seems like a minor UI annoyance until you consider what it blocks. You can't create a new job cluster configuration to replace one that's failing. You can't spin up an interactive cluster to debug a production notebook. You can't create a new SQL warehouse when the existing one hits a PERMISSION_DENIED error during auto-scaling.
The worst scenario is when the permission change that broke the button also broke scheduled jobs. Databricks jobs run as the job owner's identity. If an admin revokes allow-cluster-create from a service principal that owns production jobs, those jobs will fail on their next trigger with PERMISSION_DENIED: You are not authorized to create clusters. The UI button was your canary — by the time you noticed it, the nightly ETL may have already failed.
This is exactly the kind of failure that needs detection outside the Databricks workspace itself. MetricSign monitors Databricks job runs and surfaces PERMISSION_DENIED failures with the specific permission that was denied, the identity that was affected, and when the permission change occurred. Instead of discovering the problem when a stakeholder reports stale dashboards, you get an alert within minutes of the first job failure — with enough root cause context to know whether to fix a cluster policy, restore an entitlement, or escalate to the account admin.
For Terraform-managed workspaces, add a CI check that validates entitlements after every terraform apply. The databricks_entitlements resource in the Databricks Terraform provider makes this declarative, but drift detection requires running terraform plan regularly — or having an external system that watches for the downstream effect of permission changes on actual job execution.