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.

[stbjelcevic]

Data profiling is a configuration you attach to a table. The output metric tables are Unity Catalog objects that you choose the schema for and can govern with UC privileges like any other table. The profile’s configuration and refresh history are workspace-scoped artifacts; you must use the same workspace where profiling was enabled to view refresh history and to trigger manual refreshes in the UI.

Treating the profile as workspace orchestration avoids introducing a new UC object type and keeps governance focused on the data artifacts (metric tables), which are the persistent record of quality and drift. It also leverages existing workspace ACLs for dashboards and UI assets rather than duplicating governance in UC for those UI objects.

If cross‑workspace editing is required, centralize profiling in one workspace (attached to the shared metastore) and expose the metric tables to other workspaces via UC grants. Others can query the metrics where they work, but administration happens in the “profiling workspace.”