Does this Unity Catalog → Purview guidance make sense?

I’ve been working through how Azure Databricks Unity Catalog metadata surfaces in Microsoft Purview after a scan, and I’ve created the attached visual to make the relationship easier to understand.

The principle I’m trying to communicate is simple:

Maintain Databricks-native technical metadata in Unity Catalog → scan supported metadata into Microsoft Purview → use Purview for the wider enterprise governance, discovery and business context.

The short guidance accompanying the visual would be:

In Azure Databricks:

Navigate to Catalog Explorer → Catalogue → Schema → Table/View. From here, maintain metadata such as table comments, column comments and Unity Catalog tags. Some comments can also be AI-generated as a starting point and reviewed before saving.

After the Microsoft Purview scan:

Find the corresponding Data Asset in Purview and review the surfaced metadata:

Table Comment → Data Asset → Description

Column Comment → Data Asset → Schema → Column Description

Table Tag → Data Asset → Properties → Tags

Column Tag → Data Asset → Schema → Tags

Column Name / Data Type → Data Asset → Schema

Table/View and Column Lineage → Data Asset → Lineage, subject to the relevant prerequisites.

The distinction I’m trying to reinforce is that this is not Purview vs Unity Catalog, and it is not about manually duplicating technical metadata.

Unity Catalog remains the Databricks-native governance and technical metadata layer, while Purview can consume supported metadata through scanning and place it into the wider enterprise governance context.

I’d be interested in feedback from people implementing Purview + Azure Databricks Unity Catalog:

Does the visual and navigation guidance make the relationship clear?

In particular, are the field mappings and terminology intuitive enough for Data Engineers, Data Stewards and Data Owners, or is there anything you would simplify, rename or clarify?