# Granting to Groups for Databricks Unity Catalog

Databricks is pushing toward group-based grants as the scalable way to manage Unity Catalog access. To align with this direction and avoid running into Databricks privilege limits as environments grow, Immuta is changing how we instrument grants behind the scenes by transitioning from direct user grants to group grants for group-based access paths.

This is a back-end update that does not have any consumer-facing impact. However, there is one significant administrative change, which is that granting to groups requires Immuta to have workspace admin privileges.

<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th></tr></thead><tbody><tr><td><strong>Current model: direct user grants</strong></td><td><p>Databricks access control is based on principals (users, service principals, and groups) rather than database roles. In our current Databricks integration, Immuta effectively manages access at the user level.</p><ul><li>Users may already have Unity Catalog privileges granted outside of Immuta.</li><li>Immuta does not have a reliable way to distinguish which specific Databricks privileges on Immuta-managed data were created by Immuta versus granted out of band.</li><li>When Immuta needs to grant access via an Immuta group, individual Databricks grants are generated for every Databricks user in that group.</li></ul></td></tr><tr><td><strong>New model: group grants</strong></td><td><p>Under the new model, Immuta will treat group-based access as group-based privileges in Databricks.</p><ul><li>For manual group grants and automatic subscription policies, Immuta will generate one Databricks grant per group (instead of one per user).</li><li>Immuta will also manage the group’s membership so the right users inherit access via the group.</li><li>Immuta requires the ability to create and manage Databricks groups and memberships, which requires workspace admin privileges.</li><li>Immuta-managed groups are created at the account level and not assigned to any particular workspace.</li></ul><p>What behavior stays the same:</p><ul><li>Manual subscriptions to individual users will continue to result in direct user grants.</li><li>No UI changes, no workflow changes, no concept changes. This is purely a back-end shift in how Immuta issues Databricks grants.</li></ul></td></tr></tbody></table>

Moving to group grants dramatically reduces the number of privilege entries per securable object. Databricks limits still apply, but the group grants model makes it easier to stay within these limits.

* **Direct group memberships**: A principal can be a member of up to 1,500 groups
* **Unity Catalog privileges per object**: 4,000 privileges for parent objects and 1,000 privileges for non-parent objects
* **Groups per account**: Limit of 250,000 groups for Databricks customers using Account SCIM 2.1. All other Databricks environments are subject to a 5,000 group limit

## Group naming convention

When Immuta creates Databricks Unity Catalog groups to enforce access controls, the group naming convention differs slightly based on whether access was granted by an automatic subscription policy or the [group was manually subscribed](#user-content-fn-1)[^1] to the data source.

* **Automatic subscription of a user or Immuta group**: The group name comprises the Immuta external ID, the `connectionKey`, and the policy hash.
  * Naming convention: `IMMUTA_<Immuta external ID>_<connectionKey>_<policy hash>`
  * Example: `IMMUTA_123456789_UnityCatalogConnection_ce86d2f5f86471f66fcd08741d0eb0f4447a6e73a005094c9da07753a8d630f7`
* **Manual subscription of an Immuta group**: The group name comprises the Immuta external ID, the `connectionkey`, and the Immuta group name.
  * Naming convention: `IMMUTA_<Immuta external ID>_<connectionKey>_MANUAL_<group name>`
  * Example: `IMMUTA_123456789_UnityCatalogConnection_MANUAL_Research`&#x20;

## Grant the Immuta service principal workspace admin permissions

To create and manage groups, this new model requires the Immuta service principal to be a Unity Catalog workspace admin on the workspace you've configured as the host for the integration.

To grant the Immuta service principal workspace admin permissions on that workspace,

1. In your Databricks workspace, navigate to **Permissions**.
2. Click **Edit** on your service principal.
3. In the **Role** dropdown that appears, select **Admin**.

If your service principal is a Databricks regular user and *not* an actual service principal in Databricks,

1. In your Databricks workspace, navigate to **Settings**.
2. Under **Identity and access**, click **Users** and find the Immuta service principal you created.
3. Under that user’s **Entitlements**, switch the **Admin access** toggle to **On**.

[^1]: If a user is manually subscribed to a data source instead of a group, Immuta grants Databricks privileges on the data object directly to that user instead of creating a group.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://documentation.immuta.com/saas/configuration/integrations/databricks/databricks-unity-catalog/how-to-guides/granting-to-groups-for-databricks-unity-catalog.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
