Data Profile on a table is not securable object

[Charuvil]

Data Profile on a table is not a securable object in Unity Catalog or at Workspace level. This make the management of Data Profiles difficult for workspace admins.
Why isn’t “profile” a securable object in Databricks? It makes sense to require “Manage” permission on a table to create or access its “profile.” However, as the profile creator (Owner), I don’t want every user with “Manage” permission on the table to be able to access, refresh, or delete the profile. Also, profiles aren’t sharable across workspaces—for example, if I create a profile on a table in workspace A and share the table with workspace B, even I can’t edit or refresh the profile from workspace B. What is the reasoning behind this design? Profiles are tied to a workspace, while tables can be shared across workspaces.

[nayan_wylde]

• Profiles are metadata artifacts, not core data objects
  Unity Catalog’s securable objects (catalogs, schemas, tables, views, functions, etc.) are designed around data governance and lineage. Profiles are considered derived metadata for exploratory purposes rather than a governance-critical asset. So, they weren’t included in the securable hierarchy.

• Workspace-scoped feature
  Profiles are tied to the workspace because they rely on the compute and UI context of that workspace. This makes them non-portable across workspaces—even if the underlying table is shared—because the profile rendering and refresh logic depend on workspace-specific resources.

• Simplified permission model
  Databricks assumes that if you have Manage permission on a table, you can generate or delete its profile. This avoids introducing a new permission type and complexity in the ACL model. However, this does create the issue you mentioned: profile creators cannot restrict other managers from editing or deleting profiles.

Why can’t profiles be shared across workspaces?

• Profiles are not stored in Unity Catalog; they live in the workspace’s metadata store. When you share a table across workspaces, only the table object and its lineage are shared—not workspace-specific artifacts like profiles, dashboards, or queries.

[Raman_Unifeye]

well no concrete answer on why, perhaps Data Profile is treated as ephemeral, computed metadata or a snapshot of summary statistics (like min/max, distinct counts, etc.). It is created by a user's compute job within a specific workspace environment. It may not be considered a core, persistent data asset in the same vein as a table or view, which are the focus of UC's centralized governance.