"Nobody designs a multi-platform reporting ecosystem on purpose. It emerges — one data source at a time, one team at a time, one workaround at a time. The challenge is not preventing it. The challenge is governing it before it governs you."
The Reality — What Enterprise Reporting Environments Actually Look Like
TYPICAL ENTERPRISE REPORTING REALITY (not the architecture diagram on slide 3)
SOURCES PROCESSING REPORTING
────────── ────────── ─────────
On-prem SQL Server 2016 ──→ Power BI Import ──────→ 150 old .pbix reports
(no one knows who owns them)
Azure SQL Database ────────→ Power BI Direct ──────→ Finance dashboard
Query (owned by Finance, updated weekly)
Fabric Lakehouse ──────────→ Power BI Direct ──────→ New operational reports
Lake (owned by Data team, correct)
SharePoint Excel ──────────→ Power BI Import ──────→ Marketing reports
(manual refresh) (updated when someone remembers)
Salesforce CRM ────────────→ Power BI Import ──────→ Sales team dashboard
(via connector) (nobody certified this)
SAP on-prem ───────────────→ Third-party ETL ──────→ Supply chain reports
→ Azure SQL (different team, no lineage)
Each arrow = a potential data quality, security, or compliance risk.
Each report = a question "is this number right, and who is responsible?"
Enterprise Scenario — National Bank with Mixed Platform Reality
A national bank has 200 Power BI reports spread across four teams:
- Retail Banking team: 80 reports from on-premises SQL Server, Import mode, no RLS
- Risk team: 45 reports from Azure SQL Database, Direct Query, certified by Risk Analytics team
- Operations team: 50 reports from new Fabric Lakehouse, Direct Lake, still in pilot
- Finance team: 25 reports from a mix of SAP extracts and Excel uploads
A regulator asks: "Show us exactly where the customer credit score figure comes from in your Q3 risk report." The bank must trace the data from the report number back through every transformation to the original source system — within 48 hours.
Without lineage tracking, answering this takes days of manual investigation across four teams. With Purview, it is a 10-minute query.
Microsoft Purview — The Governance Control Plane
Microsoft Purview is the governance layer that spans all data assets — on-premises, Azure, Fabric, and even other clouds. It has three core capabilities relevant to multi-platform reporting:
MICROSOFT PURVIEW — THREE GOVERNANCE CAPABILITIES
1. DATA CATALOGUE
─────────────────────────────────────────────────────────────────
What it does: Registers all data assets (tables, files, reports,
semantic models) with metadata — owner, description,
sensitivity, classification.
In practice: Search "customer_id" → see every table, report, and
pipeline that uses it across all platforms.
No more "where does this column come from?" investigations.
2. DATA LINEAGE
─────────────────────────────────────────────────────────────────
What it does: Tracks the journey of data from source to report —
automatically, for Fabric and Azure services.
In practice: Power BI report → Semantic model → Delta table →
Spark notebook → Bronze table → Data Pipeline →
On-premises SQL Server → original transaction record.
Visual lineage graph, one click.
3. SENSITIVITY LABELS AND CLASSIFICATION
─────────────────────────────────────────────────────────────────
What it does: Classifies data assets (Confidential, PII, Public)
and applies Microsoft Information Protection labels.
Labels propagate from dataset to report to export.
In practice: A dataset marked "Confidential — Financial" prevents
export to unprotected Excel. The label follows the data.
Certified Datasets — The Trust Layer in Power BI
In a multi-platform environment, one of the most practical governance tools is dataset endorsement in Power BI and Fabric. It answers the question: "Which data source should I trust?"
In the bank scenario: the Risk Analytics team's Azure SQL-backed semantic model is Certified. The Finance team's Excel-backed reports are Promoted. The Retail team's unclaimed old reports have no endorsement. When a new analyst joins, they know immediately which datasets are authoritative.
Data Lineage in Practice — The Regulator Scenario
Back to the bank's 48-hour regulator request. With Purview lineage enabled across Fabric and Azure services, here is what answering looks like:
LINEAGE TRACE — "Where does the Q3 credit score figure come from?"
Step 1: Open Microsoft Purview → search "Q3 Risk Report"
Step 2: Click the Power BI report → view lineage graph
Lineage graph shows automatically:
Q3 Risk Report (Power BI)
↑ reads from
Risk_Semantic_Model (Certified dataset)
↑ built from
risk_gold.credit_scores (Delta table, Fabric Lakehouse)
↑ transformed by
credit_score_calc.ipynb (Spark notebook, runs nightly)
↑ reads from
risk_silver.customer_records (Delta table)
↑ ingested from
Azure SQL Database: CustomerRisk (Data Pipeline, hourly)
↑ source system
On-premises Credit Scoring System (SQL Server 2019)
Total trace time: 10 minutes.
Without Purview: 2-3 days of cross-team investigation.
Governing the Multi-Platform Reality — Practical Steps
Common Misconceptions
- "Governance means locking everything down so analysts cannot work freely" — Governance means knowing what you have, who owns it, and what the data means. Certified datasets do not prevent analysts from building their own reports — they give analysts a trusted starting point. Self-service and governance coexist.
- "Purview is only needed for compliance-regulated industries" — Purview is useful for any organisation where people ask "where does this number come from?" or "who owns this dataset?" That is every organisation with more than 10 Power BI reports.
- "Lineage only works for Fabric and Azure services" — Purview can scan on-premises SQL Server (via Integration Runtime), third-party databases, and even SAP. Lineage for on-premises sources requires additional configuration but is achievable.
- "We can add governance after the platform is built" — Governance retrofitted after data is in the platform is 3-5x more expensive than governance designed in from the start. Every report built without an owner becomes a future investigation. Every dataset without a sensitivity label is a potential compliance gap.
🎯 Quick Check
Q1: A new data analyst joins the bank and needs to find a trustworthy dataset for customer credit scores to build a new compliance report. What should they look for in the Power BI data hub?
Show Answer
They should look for a dataset with the Certified endorsement badge. Certified datasets have been reviewed by designated certifiers, meet data quality standards, have a named owner, and are officially approved for enterprise use. Promoted datasets are self-certified by the creator — useful but not officially reviewed. Datasets with no endorsement may be personal workspace items or ungoverned reports that should not be used as the basis for compliance work.
Q2: A sensitivity label of "Confidential — Customer PII" is applied to a Fabric Lakehouse Delta table containing customer records. A Power BI report is built from a semantic model that reads this table. What happens to the sensitivity label when an analyst exports the report to Excel?
Show Answer
The sensitivity label propagates to the Excel export. Microsoft Information Protection labels follow the data through the Power BI pipeline — from the Delta table to the semantic model to the report to any export. The exported Excel file will also carry the "Confidential — Customer PII" label, which can restrict opening on unmanaged devices and trigger DLP policies if the file is emailed externally. Labels protect data at rest and in transit.
Q3: What is the difference between a data catalogue and data lineage, and why does an enterprise need both?
Show Answer
Data catalogue answers "what data do we have and what does it mean?" — it is an inventory of assets with metadata (owner, description, classification). Data lineage answers "where did this data come from and where does it go?" — it is the journey map from source to report. An enterprise needs both: the catalogue tells you the credit score column exists and who owns it; the lineage tells you it was calculated by a Spark notebook from raw bureau data ingested last night. Catalogue without lineage = inventory without provenance. Lineage without catalogue = journey map without asset descriptions. Together they enable full accountability.
Key Takeaways — Part 8
- Multi-platform reporting environments are the enterprise norm, not the exception — governance must work across all platforms simultaneously
- Microsoft Purview provides three governance capabilities: data catalogue (what you have), data lineage (where it came from), and sensitivity classification (how sensitive it is)
- Certified datasets in Power BI and Fabric are the trust signal for analysts — designated certifiers review and approve authoritative datasets
- Data lineage enables compliance investigation in minutes instead of days — regulators increasingly require this capability
- Governance must be designed in from the start — retrofitting it after data is in the platform is significantly more expensive and creates compliance gaps