A dashboard can be mathematically correct and still be operationally wrong. A customer table may contain a million historical records, yet only active customers are eligible for a renewal campaign. An orders table may include cancelled and test orders, yet only fulfilled orders should contribute to recognized sales. If a data-quality check measures every row indiscriminately, its result can hide a critical defect or raise alarms about records that no longer matter.
The better question is not simply, “Is this table clean?” It is, “Is the population behind this business decision sufficiently reliable?” Snowflake’s data metric functions (DMFs) provide reusable quality measurements. Filtered associations let teams apply those measurements to specific row populations, while expectations turn measurements into explicit pass-or-fail controls. The technology matters, but the larger design decision is defining exactly which rows a KPI is supposed to represent.
What changed in Snowflake, and why it matters
Snowflake’s September 5–9, 2026 server release 10.32 added the ability to modify or clear a FILTER on an existing DMF association without dropping and recreating the association. The release notes identify the feature under data governance updates, with the announcement added September 8 and final notes published September 9. This is an operational improvement to an existing filtering capability, not the introduction of all DMFs or all row filtering.
A DMF is a function that evaluates a data-quality property, such as a null count. An association attaches that function to a table or view and, optionally, a filter and an expectation. Snowflake’s guide to filtered data-quality checks explains that the filter is stored with the association and applied whenever the metric runs. Data Quality Monitoring requires Snowflake Enterprise Edition. Check edition, privileges and feature availability before planning a rollout.
For leaders, the practical benefit is control over scope. The same underlying table can support historical reporting, customer operations and financial reporting, while each use case requires a different definition of valid data. A quality check should reflect the contract of the consuming process, not an arbitrary whole-table average.
Start with the KPI population, not the SQL
Before configuring a metric, write a one-sentence business rule: “The weekly renewal-eligible customer count includes active, non-test accounts with a valid customer identifier and a renewal date in the next 30 days.” That sentence defines both a denominator and a quality obligation. Without it, engineers can build a technically valid rule that checks the wrong records.
For every important KPI, record the owner, grain, eligible population, excluded records, freshness window, critical fields, acceptable error threshold and response owner. Grain means the unit counted: an order, order line, customer, account or invoice. A duplicate order line and a duplicate order are not the same defect. Similarly, a missing email address is critical for a campaign audience but may be irrelevant to a warehouse inventory valuation.
Three populations that often deserve separate controls
Active customers: Check customer IDs, required contact details and lifecycle status only where the business still has an active relationship. Maintain a separate rule for historical records if retention or audit requirements demand it.
Open orders: Check delivery address, order ID, payment or credit status and promised ship date for orders that are genuinely open. Closed, returned and test orders may need different checks.
Financial transactions: Check posted transactions in the reporting period for completeness, currency and reference integrity. Draft or reversed transactions should not silently contaminate the denominator.
These are examples, not universal definitions. Finance, sales and operations must approve the filters because changes to status codes, cutoff dates or cancellation logic can change what a “good” result means.
How filtered data metric functions work
Snowflake supports attaching a row predicate through FILTER when adding a DMF association to a table or view. A system DMF such as SNOWFLAKE.CORE.NULL_COUNT can then measure only rows matching the predicate. A corresponding expectation can require the result to equal zero, or another business-approved threshold. The example below is illustrative SQL; adapt object names, privileges and schedules to your environment.
ALTER TABLE analytics.customer_data
ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT
ON (email)
FILTER (status = ‘ACTIVE’)
ADD EXPECTATION active_email_present (VALUE = 0);
This checks missing email values among rows with status ACTIVE, not every customer ever stored. The expectation expresses a zero-null policy for that population. A more realistic policy might tolerate a small number of exceptions or use a rate-based custom DMF, depending on the business. Do not use a zero-tolerance threshold merely because it looks stringent.
To change the population on an existing association, the September 2026 enhancement permits a MODIFY operation:
ALTER TABLE analytics.customer_data
MODIFY DATA METRIC FUNCTION SNOWFLAKE.CORE.NULL_COUNT
ON (email)
FILTER (status = ‘ACTIVE’ AND is_test_account = FALSE);
To remove the row restriction and evaluate all rows, use FILTER () in a MODIFY statement. Snowflake does not permit combining FILTER with SUSPEND, RESUME, EXPECTATION or SET in the same MODIFY operation. Treat filter changes as versioned changes to a business control, not casual SQL edits.
There is also a structural constraint: only one association is allowed for a particular DMF, table and column combination. You cannot create several otherwise identical associations distinguished only by different filters. If two populations need independent measurements, design distinct compatible associations or appropriate views, and verify the resulting maintenance and cost implications.
A practical control framework: six questions every rule should answer
1. What decision fails if the data is wrong?
A quality rule earns its place by protecting a business action. Missing active-customer emails may affect campaign delivery; missing order IDs may prevent fulfillment; invalid ledger references may undermine reconciliation. Write the consequence in business language. This helps prioritize alerts when many checks fail simultaneously.
2. Which exact rows are in scope?
Specify status codes, dates, regions, source systems and exclusions. Prefer stable, governed fields. If the predicate uses a rolling date window, clarify whether the window is based on the business date, ingestion date or evaluation time. Time zones and late-arriving updates can otherwise create apparent quality swings that are only timing effects.
3. What does success mean?
A raw null count is not always enough. For high-volume populations, calculate both defect count and defect rate where appropriate: defect rate = invalid eligible records / eligible records. Set a threshold from business impact and historical behavior, not a generic industry benchmark. For some controls, any defect is unacceptable; for others, a temporary low percentage may be manageable.
4. Who owns the rule and the exception?
Assign a business owner for meaning and a technical owner for implementation. The business owner approves the eligible population and severity; the technical owner manages the DMF, permissions, scheduling, results and remediation evidence. An alert with no named owner is not a control.
5. When should the check run?
A five-minute check may be sensible for operational order feeds but unnecessary for a monthly financial snapshot. Snowflake uses the DATA_METRIC_SCHEDULE parameter on the table or view, and associated DMFs follow that object’s schedule. The default schedule is hourly. Align frequency with source refreshes, decision deadlines and the time needed to act.
6. What happens when it fails?
Define an escalation path and recovery test before go-live. A failed rule might pause a downstream export, flag a dashboard as provisional, create an exception ticket or trigger manual review. Not every failure should stop the pipeline. Decide based on severity, reversibility and the risk of using incomplete data.
Do not confuse a filtered check with a trustworthy KPI
Filtered checks improve relevance, but they do not automatically establish correctness. A predicate can be wrong, a status field can arrive late, and a metric can pass on an unexpectedly small or empty population. For example, if an upstream integration accidentally changes every ACTIVE status to ARCHIVED, the active-customer null count could return zero while the active-customer population collapses. That is a false sense of safety.
Pair critical filtered checks with independent controls: eligible-row count, trend or range checks, upstream-to-downstream reconciliation, freshness, and where appropriate a distinct-count or uniqueness measure. Compare against a separate source of truth when possible. A rule that says “no missing emails among active customers” should not be interpreted as “the active-customer audience is complete.”
A useful control sheet has columns for KPI, eligible-population definition, numerator, denominator, threshold, last measurement time, observed value, owner, severity and remediation status. This is the bridge between technical monitoring and executive reporting. For organizations building governed metrics and reporting pipelines, Actiknow’s business intelligence consulting and implementation services cover data integration, modeling and reporting, which are relevant to this broader control design.
Filtered checks versus grouped checks: choose the right shape
Use FILTER when a question is about one defined subset, such as active accounts. Use WITHIN GROUP when the same metric should be evaluated separately for categories such as region or product line. These are different mechanisms, and Snowflake does not allow FILTER and WITHIN GROUP on the same DMF association. If you need both perspectives, design separate associations or curated views and document the trade-offs.
A grouped check can reveal that one region is failing while the global average looks acceptable. A filtered check can remove irrelevant historical records from the analysis. Neither replaces the need to monitor the size and composition of the population. Keep cardinality in mind: grouped DMFs have limits and operational behavior that must be reviewed before using high-cardinality keys.
Operational design: from metric output to action
Capture measurement time, not just the last scheduled run
Snowflake exposes DMF results through its data-quality monitoring views, table functions and a dedicated event table. The DATA_QUALITY_MONITORING_RESULTS view is a convenient starting point for operational reporting. Snowflake recommends using measurement_time when evaluating results because it represents when the measurement actually occurred, which can differ from the scheduled time.
Make the filter auditable
Snowflake exposes an association’s stored predicate through the PROPERTIES field, including properties:filter, in DATA_METRIC_FUNCTION_REFERENCES. Include the current predicate, owner and change ticket in your operational inventory. A dashboard showing a passing metric without revealing which rows were evaluated is incomplete evidence.
Route exceptions to the right team
Design a simple status model: passed, failed, stale, not evaluated and under investigation. Distinguish a failed business expectation from a DMF that did not run. If the eligible population is zero, classify that separately where the KPI expects nonzero activity. Show the affected population and downstream reports so the owner can judge the impact.
Monitor compute and alert noise
Scheduled DMFs use Snowflake serverless compute, so monitoring frequency and the number and complexity of associations affect cost. Review DATA_QUALITY_MONITORING_USAGE_HISTORY and establish a baseline before expanding checks. A filter can narrow a logical population, but it should not be assumed to deliver a specific percentage cost saving. Test actual usage. Track alerts per week, repeat failures and median time to resolution; high alert volume with little action is a governance problem.
The operational dashboard should connect technical quality measures to business outcomes: which KPIs are affected, whether the last trusted refresh is still valid, and what the business can safely do next. Actiknow’s business intelligence dashboard services describe KPI-focused dashboards, integrations and reporting workflows; a quality-control view can be designed as part of that reporting experience rather than a separate engineering-only console.
Illustrative example: protecting a weekly renewal KPI
Consider a hypothetical subscription business reporting renewal-eligible accounts every Monday. The definition includes ACTIVE accounts with a renewal date in the next 30 days, excluding test accounts. The source CRM feeds a warehouse customer table, and a dashboard calculates the eligible count. This example is a design exercise, not an Actiknow client case study.
The team defines four checks. First, the eligible population must not unexpectedly fall to zero. Second, customer_id must be present and unique within the relevant grain. Third, renewal_date must be populated for eligible records. Fourth, the latest CRM-to-warehouse load must be within the agreed freshness window. The team also reconciles source and warehouse eligible counts using the same business cutoff.
Suppose the null count passes but the eligible population falls by 35% in one day. The right response is not to announce a 35% business decline. The owner investigates status mappings, late-arriving records, date logic and source extracts, then either validates the change or marks the dashboard provisional. A green null check is only one piece of evidence.
A control record might read: KPI = renewal-eligible accounts; population = ACTIVE, non-test, renewal within 30 days; threshold = no missing renewal dates; cadence = after daily CRM ingestion; owner = revenue operations; escalation = data engineering plus revenue operations; downstream action = withhold campaign export until critical failures are resolved. This level of specificity makes the rule operational.
A 30-day rollout plan for a business-critical dataset
Week 1: Define the decision contract
Select one high-impact KPI and map its sources, grain, status logic, filters, refresh frequency and consumers. Obtain sign-off on the population definition and acceptable failure thresholds. Document edge cases such as cancelled orders, reopened accounts, backdated adjustments and delayed events.
Week 2: Build and test the controls
Configure a small set of DMFs and expectations in a nonproduction environment. Test normal records, deliberate nulls, zero eligible rows, late arrivals and status-code changes. Confirm that the filter is attached to the intended table or view and that the result matches an independently calculated query.
Week 3: Operationalize visibility
Expose results, measurement times, predicates and owners in a simple monitoring view. Define alert severity, acknowledgments, escalation and a documented rollback path for filter changes. Measure baseline serverless usage and verify the required permissions.
Week 4: Prove the response process
Run a controlled failure exercise. Introduce a test defect, confirm that the check evaluates the intended population, verify that the responsible team receives the issue, and confirm that downstream consumers understand whether the KPI remains usable. Review false positives and refine the threshold only with business-owner approval.
Exit criteria should be concrete: every rule has an approved population and owner; critical checks are reproducible with independent SQL; empty-population behavior is defined; results and timestamps are visible; alert delivery is tested; and the team can demonstrate a complete failure-to-resolution workflow.
Common implementation mistakes
- Checking every row by default. Historical and inactive records may dominate the result while the current business process is broken. Start with the consuming KPI’s population.
- Treating a passing null count as completeness. A zero result may hide a missing or empty eligible population. Add count and reconciliation controls.
- Changing filters without governance. A predicate change alters the meaning of historical comparisons. Record the effective date, owner, rationale and validation.
- Using status labels without source semantics. ACTIVE in a CRM may not mean eligible for billing or marketing. Resolve semantic differences with the business owner.
- Scheduling checks more often than the data changes. Extra evaluations can add cost and noise without improving decisions. Match cadence to source behavior and actionability.
- Building alerts that nobody can resolve. Pair each control with an owner, severity and documented first response. The purpose is remediation, not merely a red badge.
FAQs
1. What is a Snowflake data metric function?
A DMF measures a property of data in a table or view, such as null counts or another quality condition. It can be run directly or associated with an object for scheduled evaluation.
2. What does FILTER do in a DMF association?
It restricts the rows evaluated by the metric to those matching a SQL predicate, such as status = ‘ACTIVE’. The DMF definition remains unchanged.
3. What specifically changed in Snowflake 10.32?
The September 2026 release enabled modifying or clearing an existing association’s FILTER without dropping and recreating the association. This made scoped quality rules easier to maintain.
4. Can I monitor active customers and inactive customers with the same DMF and column?
Not as two otherwise identical associations on the same table and column combination that differ only by filter. Snowflake limits each DMF/table/column combination to one association. Consider separately designed views or distinct compatible checks.
5. Can I combine FILTER with WITHIN GROUP?
No. Snowflake does not support both on one association. Use separate designs for scoped and per-group checks.
6. Can a filtered DMF replace data reconciliation?
No. It measures a quality property within a population. It does not automatically prove that all expected source records arrived or that financial totals match.
7. How should we set pass/fail thresholds?
Start with the business consequence, the denominator, baseline variation and the ability to remediate. Some fields require zero defects; other checks are better expressed as rates or tolerances.
8. How do we see the filter that was configured?
Inspect DATA_METRIC_FUNCTION_REFERENCES and its PROPERTIES field, including properties:filter, subject to the relevant privileges.
9. How frequently should checks run?
Use the decision deadline and data-refresh cadence. Snowflake’s object-level DATA_METRIC_SCHEDULE governs associated checks, with hourly as the default. Monitor the actual measurement time.
10. Do filtered data-quality checks cost money?
Scheduled DMF evaluations consume serverless compute. Estimate and monitor actual usage, and avoid assuming that narrower predicates automatically produce predictable savings.
The executive takeaway
A data-quality program should not be judged by how many rules it runs. It should be judged by whether the right people can trust the right numbers at the moment a decision is made. Start with the KPI population, make the filter visible, pair the measurement with a meaningful expectation, and connect every failure to a named response. That is how data quality becomes a business control rather than a background engineering task.
Discuss a KPI-focused data-quality approach
If your organization is consolidating data sources or building executive reporting, Actiknow can help assess the KPI definitions, integrations, data models and dashboards that need reliable quality controls. Explore our business intelligence services or contact the Actiknow team to discuss a focused assessment of one critical reporting workflow.
Technical references
Snowflake’s September 2026 release notes document the change to existing FILTER associations. The official guide to applying data-quality checks to a subset of rows covers SQL syntax and limitations. The Snowflake guide to viewing data metric function results describes the monitoring views and measurement timestamps. Confirm syntax and permissions against your account’s current documentation before deployment.