Data Quality Framework for Power BI Enterprise Analytics: Profiling, Validation, and Governance in 2026

<p>Every Power BI dashboard is only as trustworthy as the data behind it. When an executive questions a number on a report—and they will—the organization must be able to trace that number from the visual back through the semantic model, through the transformation layer, to the source system, and demonstrate that every step maintained data integrity. Organizations that cannot do this have a data quality problem disguised as a reporting problem. The dashboards look professional, the DAX is correct, but the underlying data contains duplicates, stale records, inconsistent formats, orphaned foreign keys, and undocumented business logic that nobody can explain.</p>

<p>A data quality framework for Power BI is not a tool purchase—it is an organizational discipline that spans people, processes, and technology. It defines how data is profiled, validated, monitored, remediated, and governed across the entire analytics lifecycle. Our <a href="/services/power-bi-consulting">Power BI consulting practice</a> has implemented data quality frameworks for Fortune 500 organizations where a single data error can trigger regulatory fines, clinical harm, or financial misstatement. This guide provides the enterprise-grade framework those implementations follow.</p>

<h2>Why Data Quality Fails in Power BI Environments</h2>

<p>Before building a framework, understand why data quality degrades in Power BI environments specifically:</p>

<ul> <li><strong>Self-service data preparation without guardrails</strong>: Business users connect Power BI Desktop directly to source systems and apply transformations in Power Query without validation rules. The same source data gets transformed differently by different analysts, producing conflicting metrics.</li> <li><strong>No single semantic layer</strong>: Without certified semantic models, each report author defines their own measures. "Revenue" means something different in the Sales report than in the Finance report because each uses different filters, date ranges, and calculation logic.</li> <li><strong>Source system quality inherited</strong>: Power BI inherits every quality issue from upstream systems—CRM records with missing emails, ERP entries with incorrect cost centers, HR data with stale department assignments. If you do not validate at ingestion, these errors propagate into every downstream report.</li> <li><strong>Refresh failures silently degrade freshness</strong>: A dataset refresh fails at 2 AM. The dashboard still loads the next morning with yesterday's data, but nobody notices because there is no freshness monitoring. Decisions are made on stale data.</li> <li><strong>No lineage visibility</strong>: When a data quality issue is discovered in a report, nobody can trace it upstream to identify which source, transformation, or model introduced the error.</li> </ul>

<p>A data quality framework addresses each of these failure modes systematically.</p>

<h2>The Six Dimensions of Data Quality</h2>

<p>Enterprise data quality is measured across six standard dimensions. Your framework must define metrics, thresholds, and monitoring for each:</p>

<h3>1. Completeness</h3> <p>Are all required fields populated? Measure the percentage of non-null values for critical columns. A customer record without an email address is incomplete. An invoice without a cost center is incomplete. Define completeness rules per entity: which columns are mandatory, which are conditionally required (e.g., shipping address required only for physical product orders), and what the acceptable null rate is for optional fields.</p>

<h3>2. Accuracy</h3> <p>Do the values reflect reality? Accuracy is the hardest dimension to measure because it requires a reference source. Validate email formats with regex patterns. Cross-reference postal codes against geographic databases. Compare financial totals against audited GL balances. For critical metrics, implement dual-source validation: calculate the same metric from two independent sources and alert on discrepancies exceeding a tolerance threshold.</p>

<h3>3. Consistency</h3> <p>Is the same data represented the same way across all systems and reports? "United States" vs. "US" vs. "USA" vs. "U.S.A." in a country field is an inconsistency that breaks grouping and filtering. Enforce reference data standards through lookup tables and reject or map non-conforming values during ingestion.</p>

<h3>4. Timeliness</h3> <p>Is the data current enough for the decisions it supports? Define freshness SLAs per dataset: financial data must be no more than 1 business day old, IoT sensor data must be no more than 15 minutes old, HR headcount must be refreshed weekly. Monitor refresh success/failure and data timestamps against these SLAs.</p>

<h3>5. Uniqueness</h3> <p>Are there duplicate records? Duplicate customer records inflate customer counts. Duplicate transaction records inflate revenue. Implement deduplication rules: define the natural key for each entity, detect duplicates during ingestion, and resolve them through merge rules (most recent wins, source system priority, or manual review).</p>

<h3>6. Validity</h3> <p>Do values conform to defined business rules? A discount percentage above 100% is invalid. A hire date in the future is invalid (in most contexts). An order quantity of -5 is invalid unless it represents a return. Define validation rules as machine-readable assertions that execute during data processing.</p>

<h2>Data Profiling: Understanding Your Data Before Governing It</h2>

<p>Data profiling is the foundation of any quality framework. Before you can define validation rules, you must understand the current state of your data—its distributions, patterns, anomalies, and relationships.</p>

<h3>Power Query Data Profiling</h3> <p>Power BI Desktop includes built-in profiling tools in the Power Query Editor (View &gt; Column Quality, Column Distribution, Column Profile). These tools show:</p> <ul> <li><strong>Column Quality</strong>: Percentage of valid, error, and empty values per column</li> <li><strong>Column Distribution</strong>: Count of distinct and unique values per column</li> <li><strong>Column Profile</strong>: Detailed statistics (min, max, average, standard deviation, null count, value distribution histogram) for a selected column</li> </ul>

<p><strong>Important limitation</strong>: By default, Power Query profiles only the first 1,000 rows. Click "Column profiling based on entire data set" in the status bar to profile all rows. This is critical—profiling a sample can miss quality issues in the tail of the data.</p>

<h3>Fabric Data Profiling with Notebooks</h3> <p>For enterprise-scale profiling, use Fabric Spark notebooks with libraries like ydata-profiling (formerly pandas-profiling) or great_expectations:</p>

<pre><code># Fabric Notebook - Data Profiling from ydata_profiling import ProfileReport import pandas as pd

df = spark.sql("SELECT * FROM lakehouse.bronze_customers").toPandas() profile = ProfileReport(df, title="Customer Data Profile", explorative=True) profile.to_file("Files/profiles/customer_profile.html") </code></pre>

<p>This generates a comprehensive HTML report covering distributions, correlations, missing values, duplicate detection, and data type inference. Run profiling on every new data source before building validation rules.</p>

<h3>Microsoft Purview Data Profiling</h3> <p>Microsoft Purview (formerly Azure Purview) provides automated data profiling at the catalog level. When you scan a data source, Purview generates column-level statistics including null percentage, distinct count, min/max values, and pattern detection. This profiling data feeds into the Purview Data Quality feature (preview in 2026) which supports rule-based quality scoring across registered assets.</p>

<h2>Validation Rules: Building the Quality Gate</h2>

<p>Validation rules are the enforcement layer of your data quality framework. They must be defined as code (not documentation), executed automatically, and produce measurable pass/fail results.</p>

<h3>Rule Categories</h3>

<p><strong>Schema Validation</strong></p> <ul> <li>Expected columns exist with correct data types</li> <li>No unexpected columns introduced (schema drift detection)</li> <li>Column order matches specification (important for positional file formats)</li> </ul>

<p><strong>Completeness Rules</strong></p> <ul> <li>Mandatory columns have zero nulls</li> <li>Conditional columns meet their conditional requirements</li> <li>Row counts fall within expected ranges (detect truncated loads)</li> </ul>

<p><strong>Format and Pattern Rules</strong></p> <ul> <li>Email addresses match RFC 5322 format</li> <li>Phone numbers match E.164 format</li> <li>Dates fall within valid ranges (not in the future for historical data)</li> <li>Currency values have expected precision (2 decimal places)</li> </ul>

<p><strong>Referential Integrity Rules</strong></p> <ul> <li>Foreign keys reference existing primary keys in parent tables</li> <li>Lookup values exist in reference tables (country codes, product categories)</li> <li>Cross-table row counts balance (order header count matches order detail distinct order count)</li> </ul>

<p><strong>Business Logic Rules</strong></p> <ul> <li>Revenue = Quantity x Unit Price (within rounding tolerance)</li> <li>End Date &gt;= Start Date</li> <li>Discount Percentage between 0 and 100</li> <li>Employee termination date is null for active employees</li> </ul>

<h3>Implementing Validation in Power BI Dataflows</h3> <p>In Power BI Dataflows (or Dataflows Gen2 in Fabric), implement validation as Power Query steps that flag non-conforming rows:</p>

<pre><code>// Power Query M - Validation Column = Table.AddColumn(Source, "DQ_EmailValid", each if Text.Contains([Email], "@") and Text.Contains([Email], ".") then "Pass" else "Fail", type text) </code></pre>

<p>Add a validation summary table that counts pass/fail per rule per refresh. Visualize this in a <a href="/blog/power-bi-monitoring-alerting-admin-best-practices-2026">monitoring dashboard</a> to track quality trends over time.</p>

<h3>Implementing Validation in Fabric Notebooks (Great Expectations)</h3> <p>For enterprise-scale validation, use the Great Expectations framework in Fabric notebooks:</p>

<pre><code># Great Expectations in Fabric Notebook import great_expectations as gx

context = gx.get_context() datasource = context.sources.add_spark("lakehouse_source") asset = datasource.add_dataframe_asset("customers")

# Define expectations expectation_suite = context.add_expectation_suite("customer_quality") expectation_suite.add_expectation( gx.expectations.ExpectColumnValuesToNotBeNull(column="customer_id")) expectation_suite.add_expectation( gx.expectations.ExpectColumnValuesToMatchRegex( column="email", regex=r"^[a-zA-Z0-9_.+-]+@[a-zA-Z0-9-]+.[a-zA-Z0-9-.]+$")) expectation_suite.add_expectation( gx.expectations.ExpectColumnValuesToBeBetween( column="credit_limit", min_value=0, max_value=1000000))

# Run validation results = context.run_checkpoint(checkpoint_name="customer_check") </code></pre>

<p>Great Expectations produces structured validation results that can be stored in a Lakehouse table and visualized in Power BI for continuous quality monitoring.</p>

<h2>Data Lineage Tracking: From Source to Dashboard</h2>

<p>Lineage is the ability to trace data from its origin through every transformation to its final presentation in a Power BI report. Without lineage, data quality issues cannot be diagnosed, root causes cannot be identified, and impact assessments cannot be performed.</p>

<h3>Power BI Native Lineage</h3> <p>Power BI provides workspace-level lineage views showing the relationships between data sources, Dataflows, semantic models, reports, and dashboards within a workspace. This native lineage is valuable but limited—it does not extend upstream beyond the Power BI boundary to show source system transformations.</p>

<h3>Microsoft Purview Lineage</h3> <p>Microsoft Purview extends lineage end-to-end by scanning and connecting data assets across the entire analytics stack:</p> <ul> <li><strong>Source systems</strong>: SQL Server, Azure SQL, Synapse, Databricks, SAP, Salesforce—Purview catalogs columns and tables</li> <li><strong>Data movement</strong>: Azure Data Factory, Fabric Pipelines—Purview captures copy and transformation lineage</li> <li><strong>Processing</strong>: Spark notebooks, SQL stored procedures—Purview captures column-level lineage for supported connectors</li> <li><strong>Semantic layer</strong>: Power BI semantic models—Purview shows which source columns feed which measures and calculated columns</li> <li><strong>Consumption</strong>: Power BI reports and dashboards—Purview connects visuals to the semantic model elements they display</li> </ul>

<p>With Purview, when a data quality issue is found in a Power BI visual, you can trace back through the semantic model, through the Dataflow or pipeline, through the transformation logic, to the exact source table and column where the issue originated. This is indispensable for regulated industries where auditors require this traceability. See our <a href="/blog/power-bi-data-governance-framework-enterprise-2026">data governance framework</a> for Purview integration implementation.</p>

<h3>Lineage for Impact Analysis</h3> <p>Lineage works in both directions. Forward lineage (impact analysis) answers: "If I change this source column, which reports are affected?" This is critical before modifying source systems, ETL logic, or semantic models. Purview and Power BI's impact analysis feature (available in the Power BI service for semantic models) provide this capability. Always run impact analysis before modifying any shared data asset.</p>

<h2>Data Stewardship: Human Accountability in the Quality Chain</h2>

<p>Tools and automation cannot replace human accountability. Every data domain needs a designated steward who is responsible for the quality of data within that domain.</p>

<h3>Steward Responsibilities</h3> <ul> <li><strong>Define quality rules</strong>: Stewards specify which validation rules apply to their domain's data. They define acceptable thresholds (e.g., "email completeness must be above 95% for the customer table").</li> <li><strong>Monitor quality dashboards</strong>: Stewards review the DQ monitoring dashboard weekly and investigate any metric that falls below threshold.</li> <li><strong>Remediate issues</strong>: When quality issues are detected, stewards coordinate remediation—working with source system owners to fix upstream problems or with the data engineering team to adjust transformation logic.</li> <li><strong>Certify semantic models</strong>: Only a steward can approve a semantic model for certification, confirming that the data meets quality standards for executive and regulatory use. See our <a href="/blog/power-bi-center-of-excellence-coe-playbook-2026">COE playbook</a> for certification workflow details.</li> <li><strong>Maintain documentation</strong>: Stewards maintain data dictionaries, business glossary entries, and metric definitions in Purview or the organization's knowledge base.</li> </ul>

<h3>Stewardship Operating Model</h3> <p>Assign stewards at the data domain level (Finance, HR, Sales, Operations, Clinical) rather than at the table level. Each steward owns a portfolio of 10-30 core entities within their domain. Stewards meet monthly as a council to address cross-domain quality issues (e.g., customer data used by both Sales and Finance). The council reports to the <a href="/blog/power-bi-center-of-excellence-coe-playbook-2026">COE governance committee</a>.</p>

<h2>Data Quality Metrics and KPIs</h2>

<p>What gets measured gets managed. Define a standard set of DQ metrics that are tracked continuously and reported to stakeholders:</p>

<h3>Core DQ Metrics</h3> <ul> <li><strong>DQ Score (per entity)</strong>: Composite score (0-100) calculated as the weighted average of pass rates across all validation rules for an entity. Weights reflect business criticality (e.g., financial accuracy rules weighted higher than format rules).</li> <li><strong>DQ Score (per domain)</strong>: Average of entity-level scores within a business domain. Reported to domain stewards.</li> <li><strong>DQ Score (enterprise)</strong>: Weighted average across all domains. Reported to the governance committee and executive sponsor.</li> <li><strong>Rule Pass Rate</strong>: Percentage of rows passing each individual validation rule. Trending downward triggers investigation.</li> <li><strong>Freshness SLA Compliance</strong>: Percentage of datasets refreshed within their defined SLA window.</li> <li><strong>Issue Resolution Time</strong>: Average time from DQ issue detection to remediation. Target: under 48 hours for critical issues, under 5 business days for standard issues.</li> <li><strong>Orphan Rate</strong>: Percentage of foreign key values that do not match a parent record. Indicates referential integrity degradation.</li> </ul>

<h3>DQ Trend Analysis</h3> <p>Track all metrics over time. A quality score that is stable at 92% is healthy. A score that dropped from 98% to 92% in the last month requires investigation even though 92% looks acceptable in isolation. Trend analysis reveals degradation before it hits critical thresholds.</p>

<h2>Data Quality Monitoring Dashboard</h2>

<p>Build a dedicated Power BI dashboard that serves as the central monitoring hub for data quality. This dashboard should be the stewards' primary operational tool and the governance committee's quarterly review artifact.</p>

<h3>Dashboard Pages</h3>

<p><strong>Page 1: Enterprise DQ Scorecard</strong></p> <ul> <li>Overall enterprise DQ score (gauge visual)</li> <li>DQ score by domain (bar chart, sorted worst to best)</li> <li>DQ trend over time (line chart, 12-month rolling)</li> <li>Top 10 failing rules (table with rule name, entity, pass rate, trend)</li> <li>Freshness SLA compliance (matrix of datasets vs. SLA status)</li> </ul>

<p><strong>Page 2: Domain Detail (parameterized by domain filter)</strong></p> <ul> <li>Entity-level DQ scores within the selected domain</li> <li>Rule-level pass rates for each entity</li> <li>Row-level failure examples (sample of failing rows for investigation)</li> <li>Issue log (open DQ issues, severity, assigned owner, age)</li> </ul>

<p><strong>Page 3: Freshness and Refresh Monitoring</strong></p> <ul> <li>Refresh success/failure history per dataset</li> <li>Data timestamp vs. current time (visual indicator of staleness)</li> <li>Refresh duration trends (increasing duration may indicate performance degradation)</li> <li>Failed refresh details with error messages for rapid diagnosis</li> </ul>

<p><strong>Page 4: Lineage and Impact</strong></p> <ul> <li>Source-to-dashboard lineage visualization for critical metrics</li> <li>Impact analysis: count of downstream reports affected per source table</li> <li>Change log: recent schema changes or transformation modifications detected</li> </ul>

<p>Build this dashboard on a certified semantic model that ingests validation results from your DQ rule execution engine (Dataflow validation columns, Great Expectations results, Purview quality scores). Refresh the dashboard at least daily. Set up <a href="/blog/power-bi-monitoring-alerting-admin-best-practices-2026">data-driven alerts</a> to notify stewards when any DQ score drops below its threshold.</p>

<h2>Microsoft Purview Integration: Catalog, Classify, and Govern</h2>

<p>Microsoft Purview is the enterprise governance platform that ties data quality into the broader governance fabric. For Power BI environments, Purview provides three critical capabilities:</p>

<h3>Data Catalog</h3> <p>Purview automatically discovers and catalogs data assets across Azure, on-premises, and multi-cloud sources. For Power BI specifically, Purview scans tenant metadata to catalog workspaces, semantic models, reports, Dataflows, and their relationships. Business users can search the Purview catalog to find certified, quality-validated data assets rather than building their own models from scratch. This directly reduces data duplication and inconsistency.</p>

<h3>Data Classification</h3> <p>Purview classifies data using built-in and custom classifiers to identify sensitive data types: Social Security numbers, credit card numbers, medical record numbers, email addresses, and more. Classifications feed into Microsoft Information Protection sensitivity labels that are enforced in Power BI. A dataset containing PHI (Protected Health Information) is automatically labeled as "Highly Confidential" and subject to DLP policies that prevent external sharing. This is essential for HIPAA, GDPR, and SOC 2 compliance. See our <a href="/blog/power-bi-security-best-practices-enterprise-2026">security best practices</a> for classification policy implementation.</p>

<h3>Data Quality (Preview)</h3> <p>Purview Data Quality (in preview as of 2026) allows you to define quality rules directly in the Purview governance portal, execute them against registered data assets, and view quality scores alongside catalog metadata. This means that when a business user browses the catalog for a dataset, they see not only its description and lineage but also its current quality score—enabling informed decisions about data fitness for use.</p>

<h3>Integration Architecture</h3> <p>The recommended architecture connects Purview to your Power BI quality framework as follows:</p> <ol> <li><strong>Purview scans</strong> Power BI tenant metadata (workspaces, models, reports) and source systems (SQL, ADLS, Fabric Lakehouse)</li> <li><strong>Purview classifies</strong> sensitive columns and applies sensitivity labels</li> <li><strong>Validation rules execute</strong> in Dataflows or Fabric notebooks, producing quality scores stored in Lakehouse tables</li> <li><strong>Purview ingests quality scores</strong> from Lakehouse tables and attaches them to cataloged assets</li> <li><strong>Power BI DQ dashboard</strong> reads from the same Lakehouse tables for operational monitoring</li> <li><strong>Stewards use Purview</strong> for catalog browsing, lineage exploration, and quality review; they use the Power BI dashboard for operational DQ management</li> </ol>

<h2>Governance Alignment: DQ as Part of the Broader Framework</h2>

<p>Data quality does not exist in isolation—it is one pillar of a comprehensive data governance framework. Ensure your DQ framework aligns with:</p>

<h3>Workspace Governance</h3> <p>Only semantic models that pass DQ validation should be eligible for certification. Integrate DQ scores into the <a href="/blog/power-bi-workspace-governance-tenant-settings-guide-2026">workspace governance</a> certification workflow: a model with a DQ score below 90% cannot be promoted to a certified workspace.</p>

<h3>Access Governance</h3> <p>DQ monitoring data itself must be governed. Stewards see detail for their domain. The governance committee sees enterprise-level aggregates. Individual row-level failure data may contain sensitive values and must be protected accordingly.</p>

<h3>Change Management</h3> <p>When DQ rules change (thresholds adjusted, new rules added, rules retired), document the change, communicate to affected stewards, and track the impact on DQ scores. A score improvement from a relaxed threshold is not the same as a genuine quality improvement. See our <a href="/blog/power-bi-adoption-change-management-enterprise-guide-2026">change management guide</a> for governance change protocols.</p>

<h3>Regulatory Compliance</h3> <p>For regulated industries, the DQ framework must produce audit artifacts:</p> <ul> <li><strong>HIPAA</strong>: Demonstrate that PHI is identified (classification), protected (sensitivity labels), and accurate (validation rules on patient data)</li> <li><strong>SOC 2</strong>: Demonstrate processing integrity controls—validation rules, monitoring, remediation procedures, and evidence of consistent execution</li> <li><strong>GDPR</strong>: Demonstrate data accuracy (Article 5(1)(d))—the right to rectification requires that you can identify and correct inaccurate personal data</li> <li><strong>Financial reporting (SOX)</strong>: Demonstrate that financial data in Power BI reconciles to audited source systems with documented validation controls</li> </ul>

<p>For organizations in these regulated sectors, see our industry-specific guides: <a href="/blog/power-bi-healthcare-hipaa-compliant-analytics-2026">healthcare HIPAA analytics</a>, <a href="/blog/power-bi-financial-services-regulatory-reporting-2026">financial services regulatory reporting</a>, and <a href="/blog/power-bi-government-fedramp-analytics-2026">government FedRAMP analytics</a>.</p>

<h2>Implementation Roadmap: 90-Day Data Quality Framework</h2>

<p><strong>Phase 1: Assess and Profile (Weeks 1-3)</strong></p> <ul> <li>Inventory all Power BI semantic models, Dataflows, and source connections</li> <li>Run data profiling on the top 10 most-consumed datasets</li> <li>Identify critical entities and columns based on business impact</li> <li>Document current DQ issues and estimate their business cost</li> <li>Assign stewards for top 5 data domains</li> </ul>

<p><strong>Phase 2: Define and Build (Weeks 4-8)</strong></p> <ul> <li>Define validation rules for top 10 datasets (start with completeness and referential integrity)</li> <li>Implement rules in Dataflows or Fabric notebooks</li> <li>Build the DQ monitoring dashboard (start with Pages 1 and 2)</li> <li>Configure Purview scanning for Power BI tenant and primary source systems</li> <li>Establish DQ thresholds and freshness SLAs for each dataset</li> </ul>

<p><strong>Phase 3: Operationalize (Weeks 9-12)</strong></p> <ul> <li>Launch steward council with monthly meeting cadence</li> <li>Integrate DQ scores into semantic model certification workflow</li> <li>Set up automated alerts for DQ threshold breaches</li> <li>Remediate top 5 DQ issues discovered during profiling</li> <li>Report Phase 1 metrics to governance committee</li> <li>Expand rule coverage to next 10 datasets</li> </ul>

<p>Data quality is not a project with an end date—it is an ongoing discipline. The framework you build in 90 days provides the foundation; continuous monitoring, steward accountability, and iterative rule expansion sustain quality over time. <a href="/contact">Contact EPC Group</a> for a data quality assessment, framework design, and implementation support from consultants who have built enterprise DQ programs for the most demanding regulatory environments.</p>