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.