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