Forum Discussion
Workaround Enabling Purview Data Quality & Profiling for Cross-Tenant Microsoft Fabric Assets
In my view, the root problem is that Purview cannot run Data Quality or Profiling on Fabric data held in another tenant; metadata scans may work, but the DQ engine requires the data to exist physically within the same tenant where Purview’s identity and RBAC operate.
From my experience, this creates a noticeable governance gap for multi-tenant setups, and it feels like the platform is not yet ready for true cross-tenant scenarios.
The workaround of exporting Fabric tables into an ADLS Gen2 account inside the Purview tenant does work reliably, enabling full profiling, rule execution and DQ scoring. This is effective because Purview can only process data it can access natively within its own tenant boundary.
The main drawbacks are that this produces a copy rather than a live view and requires scheduled refreshes, especially for large tables.
Overall, this staging approach is the only workable solution for now, though it feels like Microsoft needs to address cross-tenant DQ support sooner rather than later.
However, I might be wrong.
Pranav, the staging pattern introduces a second governed data asset. I would document the source snapshot, extraction time, transformations, destination tenant and region, accountable owner and permitted purpose before treating its quality score as evidence about the source. A successful scan validates the staged population under the rules executed there; changes or omissions during export can make that population differ from the live Fabric tables.
For this pattern, I would compare source and copy row counts, schema and selected control totals for the same snapshot, then record which checks cover the full population and which are sampled. Apply destination access and retention controls explicitly, and test what happens when source permission is revoked or a record must be removed from downstream copies. If refresh fails, keep the last result visibly dated and flag the dependent assessment as stale. Scheduling a daily export alone does not establish freshness.
This maps to the Data Fitness Decision and Data Disclosure Contract documented in my PALO Framework: https://paloframework.org/docs/palo-data-assurance-control-plane.html . The first binds purpose, source version, quality evidence and expiry; the second bounds fields, recipient, region and retention. These are governance design references, not a claim of a built-in PALO-Purview integration. They provide useful acceptance criteria for the staging workaround regardless of how native cross-tenant support evolves.