Databricks Apps is one of those platform features that looks deceptively simple: “deploy an app next to the data.” In practice, it changes how teams deliver internal tools (dashboards, forms, RAG UIs, lightweight workflows) because you can ship an application inside the Databricks security and governance boundary without standing up a separate web stack.

This post is my practical review: what Databricks Apps is, what it is not, how to configure access using SCIM-provisioned groups, and the best practices / anti-patterns I would use in a real rollout. One caveat: this is not tested in production. I provide this caution to those looking at this article as justification for a push to production.

What Databricks Apps is

At a high level, Databricks Apps lets you create, deploy, and share data/AI apps that run on Databricks-managed (serverless) infrastructure and integrate with Databricks services (SQL, model serving, Unity Catalog governance, secrets).

The key operational idea: an app is not “just code.” It’s code + a deployment + a permissions model:

• A Databricks app has workspace-level permissions (CAN USE and CAN MANAGE).
• Each app is assigned a dedicated Databricks service principal that is granted the permissions required to access app “resources” you configure (for example, a SQL warehouse).
• Users authenticate through your organization’s IdP (SSO). Databricks can forward user identity to the app runtime so governance can be enforced with the user’s identity, not just a shared service credential.

If you already live in Databricks, the big win is you can deliver “internal apps” without building:

• a separate Kubernetes cluster
• a separate IAM boundary
• a parallel secrets system
• a parallel audit surface

What Databricks Apps is NOT

Databricks Apps is not a generic replacement for “any web app anywhere.” The important “isn’ts”:

1) It’s not public hosting

You cannot make Databricks Apps public. Anonymous access and bypassing SSO are not supported.

If your use case needs “anyone on the internet can see this,” Databricks Apps is the wrong tool.

2) It’s not “permissions = data access”

App permissions control who can access/manage the app. They do not automatically grant access to the underlying data.

You still need Unity Catalog and workspace permissions to be correct.

3) It’s not a great fit for heavyweight, high-throughput backend services

If you need:

• very high request rates
• strict low-latency SLAs
• custom networking / ingress patterns
• complex multi-service architectures

…you’ll likely be happier with a dedicated application platform. Databricks Apps shines when the app is a thin layer over Databricks-native services.

Permissions vs authorization (the distinction that matters)

Databricks documentation draws a useful line:

• Permissions: who can CAN USE or CAN MANAGE the app.
• Authorization: what the app (and its users) can access.

Authorization has two parts:

• User authorization: the app can act as the signed-in user (so UC policies apply by user).
• App authorization: the app service principal can be granted only what the app needs (least privilege), independent of the user.

This is where Databricks Apps can be “good governance by default” if you design it intentionally.

Configuring SCIM access for Databricks Apps (a sane rollout)

If you want app access to be predictable and auditable, do not hand-manage users. Use SCIM-provisioned groups and assign permissions to groups.

Step 1: Use account-level SCIM provisioning

Databricks recommends account-level SCIM provisioning (not legacy workspace-level SCIM). The typical flow:

• In the Databricks account console: Security → User provisioning → enable provisioning, copy:
  • the SCIM URL
  • the SCIM token
• Configure your IdP’s SCIM connector (Okta / Entra ID / OneLogin) to sync users and groups.

Important behavior to understand: attributes provisioned by your IdP can override admin changes made directly in Databricks on the next sync. If you want entitlements to “stick,” manage them at the source of truth (IdP/group policy), not by clicking around in the workspace.

Step 2: Create SCIM groups that map to app personas

I like 3 standard groups per app:

• app-<name>-users (default CAN USE)
• app-<name>-admins (small set of CAN MANAGE)
• app-<name>-service (optional, only if you need a separate service principal story)

Keep membership assignment in your IdP so “join/leave company” flows deprovision cleanly.

Step 3: Ensure workspace entitlements match your access model

Even if a user can authenticate, they still need the right workspace entitlements depending on how you’re exposing the app (and your workspace auth policies).

Also: if your environment uses PrivateLink (or other restricted network patterns), read the fine print; Databricks notes that certain authentication policies can block users who try to connect via the public endpoint.

Step 4: Assign app permissions to groups (not individuals)

In the Databricks Apps UI:

• Add your SCIM group(s) to the app Permissions tab
• Grant:
  • CAN USE to the users group
  • CAN MANAGE to the admins group

If you want org-wide internal discoverability, Databricks Apps supports an organization permission mode (“Anyone in my organization can use”). Use this carefully, especially in larger orgs, because it is easy to accidentally create “shadow IT dashboards” with unclear ownership.

Step 5: Review the app service principal permissions

Each app gets its own service principal. Treat it like production:

• Give it access only to the resources the app truly needs (SQL warehouse, model serving endpoint, UC objects).
• Avoid building apps that “create new infrastructure” at runtime; apps are designed to be portable and least-privilege.

Best practices (the stuff that prevents pain later)

1) Prefer “thin apps” over “mini platforms”

Databricks Apps is strongest when it’s a UI and lightweight orchestration layer over:

• Databricks SQL
• Jobs
• Model Serving
• Unity Catalog governed tables/volumes

If you find yourself rebuilding a full backend, step back.

2) Use groups for permissions, not people

• CAN MANAGE should be rare.
• Don’t assign app permissions to individual users unless it’s a one-off emergency.
• Make app ownership visible (group owners + tags + a clear “contact” in the app UI).

3) Separate dev/test/prod apps and workspaces

Treat apps like code:

• dev workspace = fastest iteration
• prod workspace = locked down permissions, change control

4) Don’t hardcode compute resources

Databricks explicitly recommends keeping apps portable by configuring dependent resources (like a SQL warehouse) in the Apps UI rather than hardcoding IDs in code. This makes promotion across environments much less painful.

5) Secrets: always use Databricks secrets, never env files in git

If the app needs tokens, API keys, or credentials:

• store them in Databricks secrets
• reference them at runtime
• never bake them into the repo

6) Audit like you mean it

Databricks provides app-related audit events through system tables (app logins, permission changes, recent actions). If your org cares about governance (it should), build a small monitoring query and alert on:

• permission changes (CAN MANAGE grants)
• org-wide access toggles
• unusual login spikes

When Databricks Apps is a bad use case

Here are the cases where I’d strongly consider a different platform:

• Public-facing apps (anonymous or consumer access on the open internet)
• Hard real-time / low-latency APIs with strict SLOs
• High-volume interactive traffic where you need fine-grained autoscaling controls and deep observability of the web tier
• Complex multi-tenant SaaS products that need custom domains, edge routing, WAF rules, complex auth patterns, and multiple backend services
• Apps that need deep OS/network control (custom ingress, unusual binaries, privileged networking, etc.)

In those scenarios, a conventional app platform (Kubernetes, ECS, serverless functions + API gateway, etc.) is usually the right tool.

Final thought

Databricks Apps is a strong choice for “internal data apps” because it keeps the experience close to the data and close to governance. The biggest mistake is treating it like a generic hosting platform. Treat it like a governed delivery mechanism for thin apps, wire access through SCIM groups, keep permissions tight, and you’ll get the “boring outcome” you are looking for.

In my next post, I will discuss DataBricks Apps configurations, and what to do if your app is not responding or performing the way it should.

Thank you for reading.

Cheers!
Jason