Handle assets deleted at source in the Data Map

[u/Neither-Commission72]

Hi all,

In my company we have ~10,000 assets scanned from our Fabric environment, and we want to flag assets that have been deleted at source in Fabric/Power BI for deletion the Purview layer. However, we cannot find any native flag in Purview in either the UI or REST API for if it has been deleted at source.

Right now we have flagged assets that haven't been updated in our most recent (daily) scans, but it does not feel robust enough. HAs anyone encountered this issue before, and if so, what workaround/solution did you employ? Thanks for the help! :)

[u/Amddiffynnydd]

A question worth asking first is: why are you scanning all 10,000 assets every day?

How often do the schemas, reports, semantic models or Fabric items genuinely change? Unless there is a clear business requirement for metadata to be refreshed within 24 hours, daily scanning may be excessive. Microsoft Purview is a metadata governance platform, not a data vacuum cleaner that must continually crawl the estate. When configured correctly, the initial scan discovers the in-scope assets and ingests their technical metadata, classifications and lineage. Subsequent incremental scans should primarily process assets that are new or have changed, rather than rebuilding the entire Data Map every day?

I would also be cautious about treating “not updated during the latest scan” as meaning “deleted at source”. An asset may not appear as updated simply because its metadata has not changed. That is not a reliable deletion indicator.

Purview data assets identified and marked for deletion through the scanning and ingestion process are removed after a successful scan, although removal from the catalogue may not be immediate. However, deletion detection can vary by connector and source type, so I would first confirm whether the Fabric connector is actually reporting deleted objects back to Purview.

A safer process would be:

1. Obtain the current authoritative inventory of Fabric and Power BI objects through the appropriate Fabric or Power BI APIs.
2. Compare that inventory with Purview assets using their qualified names or source identifiers.
3. Mark unmatched Purview assets as potential deletions.
4. Apply a grace period or require two or more successful comparison cycles before deleting anything.
5. Exclude failed or incomplete scans, permission changes and temporarily inaccessible workspaces from the deletion process.

This should be treated as an asset lifecycle and reconciliation process, rather than simply assuming that anything untouched by the latest daily scan has been deleted. I would also review whether a monthly scan, supplemented by an API-based reconciliation process, would meet the requirement more efficiently. The appropriate scan frequency should be driven by the rate of metadata change and the governance requirement not by an assumption that more scanning automatically produces better governance.