Data Governance with Purview + Power Platform

Most data governance programmes in mid-market industrials produce one thing reliably: a policy document that sits in SharePoint and goes stale within six months. The data remains ungoverned. The policy remains unread.

The reason they stall is not a lack of ambition. It is the wrong starting point.

Governance frameworks are necessary. But a framework without an enforced data product is theoretical. The question is not "what is our governance policy?" — it is "which data domain is causing the most pain right now, and can we make one clean, owned, maintained version of it?"

For most mid-market industrials, that domain is one of three: customer master, product master, or supplier master. These are the records that every other system depends on. When they are wrong — duplicate supplier codes in SAP S/4HANA, inconsistent product descriptions between the ERP and the WMS, customer records without a primary contact — the downstream effects are everywhere. Wrong OTIF calculations. Mis-routed purchase orders. Failed EDI transactions. Incorrect regulatory declarations.

Pick one domain. Make it right. Then expand.

This is not a theoretical architecture. It is the pattern that works in practice for mid-market industrials already running SAP S/4HANA or SAP ByDesign as their ERP golden source.

**Microsoft Purview** handles lineage and classification. It connects to the SAP source — via the SAP connector or via the ADF-landed copy in OneLake — and classifies what it finds. Sensitive fields are tagged. Lineage is traced from SAP through any transformation layer to the downstream consuming system. When a data steward asks "where did this supplier address come from and when was it last changed?" — Purview answers that without a manual audit trail exercise.

**Dataverse** holds the governed master. Not a replica of the SAP table — a curated, validated, steward-approved version that SAP writes to and reads from via a defined integration. Dataverse is the single source of truth for that domain. Everything else subscribes.

**Power Apps** is the steward interface. A named data steward — not "the IT team," a named person in the business — logs into a canvas app. They see the records flagged for review, the quality exceptions, the pending change requests. They approve or reject. They add context. The app is built for the steward's job, not for a developer's convenience.

**Power Automate** runs the approval cycle. A supplier record change request arrives in SAP ByD. The flow triggers a review notification to the steward. The steward acts in Power Apps. The approved change writes back to SAP ByD and updates Dataverse. The full cycle is auditable — timestamp, actor, decision, reason.

**Power BI** exposes the quality scorecard. Fill rate by field, duplicate count, approval cycle time, exception volume by category. The steward's manager sees the trend. The IT Head sees the improvement month-on-month. The CIO can show the board that governance is a living programme, not a filed document.

Most mid-market industrials treat SAP as the golden source — and it should remain so for transactional data. The governance layer does not replace SAP. It wraps it. Master data changes are validated before they enter SAP, not corrected after. Lineage traces back to SAP as the originating system.

The integration pattern depends on what you are running. SAP S/4HANA with an API layer gives you cleaner bidirectional sync. SAP ByDesign typically uses file-based or OData integration, which is manageable but requires a well-designed ADF pipeline to keep latency acceptable. Azure Data Factory handles both patterns. The pipeline lands a copy in OneLake; Purview scans OneLake; Dataverse holds the curated master. The SAP system remains authoritative for transactions. The governed master remains authoritative for reference data.

This is where governance programmes fail most often. They assign ownership to a team — "the master data team" — rather than a person. Teams do not own data. People do. And when the person who actually knows the difference between a valid supplier record and a duplicate is not in the loop, the exceptions pile up unresolved.

A working governance model has a named steward per domain. That steward has a defined remit — they own the quality of that domain's records, they have the authority to approve or reject changes, and they are accountable for the scorecard. Power Apps makes their job manageable. Power Automate keeps the workflow moving. Power BI shows whether it is working.

The platform makes stewardship possible. The steward makes governance real.

A manufacturing business running SAP S/4HANA across two plants had a supplier master with 23% duplicate records and no formal change approval process. Procurement were creating new supplier codes rather than reusing existing ones because finding the right record took too long. The downstream effect was fragmented spend reporting and mis-consolidated accounts payable.

The practitioner approach: Purview scanned the SAP supplier master and classified duplicates. Dataverse held the de-duplicated, curated master. Power Apps gave the procurement data steward a daily exception queue. Power Automate enforced a two-step approval before any new supplier code could be created. Power BI tracked the quality score weekly.

After the initial deployment, duplicate rate fell from 23% to under 4% within the first quarter. Approval cycle time for new supplier onboarding came down from 8–12 days to 3–5 days. Spend consolidation accuracy improved materially across the reporting period.

If the data quality problem is primarily a process problem — people creating records incorrectly — governance tooling alone will not fix it. You need process redesign alongside the platform.

If the SAP instance is heavily customised and the integration layer is fragile, stabilise the integration first. Introducing a governance layer on top of an unreliable feed creates a governed version of bad data — which is arguably worse than ungoverned bad data, because it appears trustworthy.

A Discover → Prototype engagement maps one data domain — supplier master or product master — through Purview, into Dataverse, and out to a Power BI quality scorecard. In six weeks, you have a live scorecard showing the quality state of that domain and an exception queue that a steward can actually work. That is the proof of concept that justifies the broader programme.