Forum Discussion
Workaround Enabling Purview Data Quality & Profiling for Cross-Tenant Microsoft Fabric Assets
The Challenge: Cross-Tenant Data Quality Blockers Like many of you, I have been managing a complex architecture where Microsoft Purview sits in Tenant A and Microsoft Fabric resides in Tenant B.
While we can achieve basic metadata scanning (with some configuration), I hit a hard wall when trying to enable Data Quality (DQ) scanning. Purview's native Data Quality scan for Fabric currently faces limitations in cross-tenant scenarios, preventing us from running Profiling or applying DQ Rules directly on the remote Delta tables.
The Experiment: "Governance Staging" Architecture rather than waiting for a native API fix, I conducted an experiment to bridge this gap using a "Data Staging" approach. The goal was to bring the data's "physicality" into the same tenant as Purview to unlock the full DQ engine.
The Solution Steps:
Data Movement (Tenant B to Tenant A): Inside the Fabric Workspace (Tenant B), I created a Fabric Data Pipeline. I used this to export the critical Delta Tables as Parquet files to an ADLS Gen2 account located in Tenant A (the same tenant as Purview).
Note: You can schedule this to run daily to keep the "Governance Copy" fresh.
Native Scanning (Tenant A): I registered this ADLS Gen2 account as a source in Purview. Because both Purview and the ADLS account are in the same tenant, the scan was seamless, instantaneous, and required no complex authentication hurdles.
Activating Data Quality: Once the Parquet files were scanned, I attached these assets to a Data Product in the Purview Data Governance portal.
The Results: The results were immediate and successful. Because the data now resides on a fully supported, same-tenant ADLS Gen2 surface:
✅ Data Profiling: I could instantly see column statistics, null distributions, and value patterns.
✅ DQ Rules: I was able to apply custom logic and business rules to the data.
✅ Scans: The DQ scan ran successfully, generating a Data Quality Score for our Fabric data.
Conclusion: While we await native cross-tenant "Live View" support for DQ in Fabric, this workaround works today. It allows you to leverage the full power of Microsoft Purview's Data Quality engine immediately. If you are blocked by tenant boundaries, I highly recommend setting up a lightweight "Governance Staging" container in your primary tenant.
Has anyone else experimented with similar staging patterns for Governance? Let's discuss below.
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.
4 Replies
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.The problem is not just with cross-tenant, but also cross region - Purview is not available in all Microsoft regions and DQ engine requires the data to exist physically in the same region as well even with a single tenant.
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.
If you found this helpful, consider giving some Likes. If I answered your question or solved your problem, mark this post as the solution.
