topic Hi @APJESK, To address your follow-up questions about the... in Administration & Architecture

Workspace Folder ACL design

APJESK — Sun, 25 Jan 2026 20:34:38 GMT

How should the Databricks workspace folder architecture be designed to support cross-team collaboration, access governance, and scalability in an enterprise platform? Please suggest below or share some ideas from your experience Thanks

Note: I'm new to Databricks I'm not aware about the Realtime scenario, so requesting your help how workspace folder ACL id designed and practiced at enterprise level.

Each team owns and manages its workspace objects within dedicated folders, while selectively sharing approved assets with other teams using folder-level access control to ensure governance and collaboration.

/Teams

/DataEngineers

/DataAnalysts

/DataScientists

/Admin

/Shared

/Repos

Re: Workspace Folder ACL design

Louis_Frolio — Mon, 26 Jan 2026 15:47:43 GMT

Hello @APJESK ,

Based on some digging and real-world patterns I’ve seen, here’s how I’d think about workspace folder ACL design in an enterprise Databricks environment.

Folder architecture: the big idea

Your proposed structure is a solid starting point. The core principle you’re leaning into is the right one: give teams clear ownership of their own spaces, and enable sharing intentionally through folder-level ACLs. That maps well to how Databricks permissions actually work at scale and aligns with enterprise best practices.

Recommended folder structure

A clean, opinionated structure like this tends to hold up well over time:

/Users

/[individual user workspaces]

/Teams

/DataEngineering

/DataScience

/Analytics

/MLOps

/Shared

/CommonLibraries

/UtilityNotebooks

/Templates

/Production

/Jobs

/Pipelines

/Models

/Repos

/[git-integrated folders]

/Sandbox

/Experimental

How to think about permissions by folder

Team folders (/Teams/*)

Each team should have CAN MANAGE on its own folder. That gives them full autonomy to create, modify, and delete notebooks and other objects without needing central intervention. By default, other teams should have no access, with selective CAN VIEW or CAN RUN granted only for assets that are explicitly meant to be shared.

Shared folders

Shared spaces should be mostly read-only. Grant CAN VIEW or CAN RUN broadly so teams can consume common utilities and templates, but reserve CAN EDIT for a small set of maintainers, usually a platform or enablement team. This prevents “shared folder entropy” over time.

Production folders

Lock these down tightly. Only automation identities (service principals) and a small number of designated owners should have CAN MANAGE. Everyone else should be limited to CAN VIEW or CAN RUN, depending on whether they need visibility into outputs or the ability to trigger workloads.

Repos folders

Repos are their own special case. Folder ACLs still apply, but Git gives you an additional layer of control. Teams should own their repo folders and manage collaboration through Git workflows and branch protections rather than loose workspace permissions.

Permission inheritance (this matters a lot)

Databricks folders use inheritance. Anything you put inside a folder automatically inherits that folder’s ACLs. This is a huge win operationally because it means you set permissions once at the folder level instead of micromanaging individual notebooks.

One nuance worth calling out: if someone has access to a single object inside a folder, they can see the parent folder name, but they won’t be able to browse or access sibling objects unless they’re explicitly granted access. This behavior is often misunderstood but works in your favor for selective sharing.

Enterprise best practices that actually stick

Use groups, not users

Always assign permissions to groups. Never individual users. Groups should mirror how your org actually works, for example:

data-engineers-team

data-scientists-team

analytics-viewers

production-job-runners

This makes onboarding, offboarding, and audits dramatically easier.

Adopt a three-environment model

When possible, separate Dev, Staging, and Prod into distinct workspaces. This reduces blast radius and creates clear promotion paths. Within each workspace, keep the folder structure consistent so teams don’t have to relearn where things live.

Establish a lightweight center of excellence

A small enablement or platform group goes a long way. They don’t need to gate everything, but they should own shared patterns, folder templates, and documented ACL conventions. Typically, they’re the stewards of /Shared and /Templates.

Give people a sandbox on purpose

Exploration is healthy, but it needs guardrails. Dedicated sandbox areas or even sandbox workspaces with tighter data access and cluster policies let people experiment without risking governed environments.

Permission levels refresher

Databricks gives you five levels at the folder layer:

NO PERMISSIONS: can’t see or access anything

CAN VIEW: browse and read, clone, export

CAN RUN: execute notebooks and files

CAN EDIT: create, modify, and delete

CAN MANAGE: full control, including permissions

Be especially careful with CAN MANAGE — that’s the sharpest knife.

Scaling without chaos

Resist the urge to create a new workspace for every use case. Most enterprises are healthiest with a modest number of workspaces per account, using folders to organize teams and projects inside them.

Automate where you can. Terraform for workspace setup and permissions, SCIM for group sync from your identity provider — these pay off quickly as you scale.

Also, remember the division of responsibility: workspace ACLs govern access to code and compute, while Unity Catalog governs access to data. You want both, not one pretending to do the other’s job.

Common pitfalls to avoid

Don’t hand out CAN MANAGE casually. Don’t stash production assets in default DBFS locations that bypass Unity Catalog. And don’t create a brand-new workspace for every project if a folder would do — that just creates operational overhead.

How I’d implement this in practice

Start simple. For smaller orgs, one workspace per environment with a well-designed folder hierarchy is usually enough. As requirements grow — compliance, data isolation, geography — add workspaces intentionally, not reactively.

Most importantly, document your folder structure and ACL patterns somewhere visible. Consistency and clarity matter more than cleverness here.

Cheers,

Louis

Re: Workspace Folder ACL design

APJESK — Mon, 26 Jan 2026 21:16:09 GMT

Thanks for the detailed information, Iwill review and get back to you if any question meanwhile can you please on this query

Databricks Workspace ACL Enforcement – How to Prevent Users from Creating Objects Outside Team Folder and Attaching to Shared Clusters?

Background

I am configuring workspace-level access control in Databricks to restrict Data Engineers (DE group) to operate only inside a dedicated team folder and to prevent unintended compute usage.

Here is the setup I implemented:

Configuration Details

Identity & Group Setup

Created a user and added the user to DE-grp
Assigned Workspace User role to DE-grp
Applied default workspace entitlements

Folder Permissions

Created a workspace folder:
/Team/DatabricksEngineering
Assigned CAN MANAGE permission to DE-grp
No permissions were granted to DE-grp on other workspace folders

Compute Permissions

Admin created shared clusters
Granted Attach To permission to DE-grp
DE-grp does NOT have permission to create clusters

Expected Behavior

I expected the following:

Users in DE-grp should only create and manage notebooks inside:
/Team/DatabricksEngineering
Users should NOT be able to:
- Create workspace objects outside this folder
- Attach notebooks to shared clusters unless explicitly allowed

Observed Behavior (Problem)

When logging in as a DE-grp user:

Workspace Object Scope Leak
- User can still create notebooks inside their personal Home folder:
  /Users/<username>
- Since the user owns their Home folder, they automatically get CAN MANAGE permission
- This bypasses folder-based governance
Compute Access Gap
- Even though the user cannot create clusters:
- They can still attach their notebooks which they created in Home folder to existing shared clusters and execute code

Hi @APJESK, To address your follow-up questions about the...

SteveOstrowski — Mon, 09 Mar 2026 01:05:24 GMT

Hi @APJESK,

To address your follow-up questions about the two behaviors you observed after implementing the folder ACL structure:

ISSUE 1: USERS CAN STILL CREATE NOTEBOOKS IN THEIR HOME FOLDER

This is by-design behavior. Every Databricks user automatically gets a personal home folder at /Users/<username> with CAN MANAGE permission. This permission is built into the platform and cannot be removed or restricted by workspace admins. There is no workspace setting, ACL configuration, or entitlement toggle that prevents a user from creating objects in their own home folder.

So even though you only granted DE-grp CAN MANAGE on /Team/DatabricksEngineering and nothing else, each user in that group still has full control over their personal /Users/<username> directory.

ISSUE 2: USERS CAN ATTACH HOME FOLDER NOTEBOOKS TO SHARED CLUSTERS

Compute permissions and workspace folder permissions are evaluated independently. The CAN ATTACH TO permission on a cluster grants the user the ability to attach any notebook they own or can run, regardless of where that notebook lives in the workspace folder hierarchy. Since users own their home folder notebooks (they have CAN MANAGE), they can attach and execute those notebooks on any cluster where they hold CAN ATTACH TO.

This is also expected behavior. There is no folder-aware restriction on compute attachment.

WHAT YOU CAN DO TO STRENGTHEN GOVERNANCE

While you cannot fully prevent home folder usage or add location-based compute restrictions through workspace ACLs alone, here are several complementary approaches:

1. Use Unity Catalog for data-level governance

 Workspace ACLs control access to code and compute, but Unity Catalog controls access to data. Even if a user creates a notebook in their home folder and attaches to a shared cluster, they can only query tables, schemas, and catalogs they have been explicitly granted access to. This is where the real governance boundary lives. Assign table-level and schema-level permissions via groups so that only DE-grp can access engineering data assets.

 Reference: https://docs.databricks.com/en/data-governance/unity-catalog/manage-privileges/index.html

2. Restrict cluster creation with entitlements

 Remove the "Allow unrestricted cluster creation" entitlement from the DE-grp group. This ensures they cannot spin up their own compute and must use admin-provisioned clusters. You already have this in place.

3. Use cluster policies to enforce guardrails

 Cluster policies let you define exactly what compute configurations are allowed. You can restrict instance types, auto-termination, Spark configs, and more. Assign specific policies to specific groups so that each team only sees and uses approved compute configurations.

 Reference: https://docs.databricks.com/en/compute/policy-definition.html

4. Limit CAN ATTACH TO permissions carefully

 Only grant CAN ATTACH TO on clusters to groups that genuinely need them. If DE-grp should only use one specific shared cluster, grant CAN ATTACH TO only on that cluster and ensure other shared clusters have no permissions granted to DE-grp. This limits the blast radius even if users create notebooks in their home folders.

5. Use audit logs to monitor home folder activity

 You can query system.access.audit to monitor what users are doing, including notebook creation events and cluster attachment. This provides visibility into whether users are circumventing the intended folder structure.

 Reference: https://docs.databricks.com/en/admin/system-tables/audit-logs.html

6. Consider separate workspaces for stronger isolation

 For stricter governance requirements, separate environments (dev, staging, prod) into distinct workspaces. Each workspace has its own set of folder ACLs, compute resources, and access controls. This gives you a harder boundary than folder-level ACLs within a single workspace.

SUMMARY

The home folder behavior and compute attachment behavior you observed are both by design. The workspace folder ACL model gives you governance over shared team folders, but every user retains CAN MANAGE on their personal directory. The recommended approach is to layer Unity Catalog data permissions on top of workspace ACLs so that even if a user runs code from their home folder on a shared cluster, they can only touch the data they are authorized to access.

Your proposed folder structure (/Teams, /Shared, /Repos, /Admin) is a solid foundation. The key is to pair it with Unity Catalog grants, restricted compute entitlements, cluster policies, and careful CAN ATTACH TO assignments.

* This reply used an agent system I built to research and draft this response based on the wide set of documentation I have available and previous memory. I personally review the draft for any obvious issues and for monitoring system reliability and update it when I detect any drift, but there is still a small chance that something is inaccurate, especially if you are experimenting with brand new features.

If this answer resolves your question, could you mark it as "Accept as Solution"? That helps other users quickly find the correct fix.