How Any Not Null Checks Work

This page covers everything the Any Not Null check does, in detail: how it decides which rows are violations, how NULLs affect the evaluation, filter behavior, coverage, the resulting anomaly, and how the rule relates to other completeness rule types.

If you only need a quick reference, the Introduction page covers the formal definition, field scope, and general/anomaly properties. This page is the detailed reference.

Evaluation Flow

Every Any Not Null check follows the same four-step evaluation flow:

Apply the filter clause. If the check has a filter set, only rows matching the filter expression continue to the next step. Rows outside the filter are ignored and cannot contribute to the violation count.
Read the selected fields. The platform reads every field listed under fields for the current row, without any type conversion.
Test at least one non-NULL. The row passes if at least one of the selected fields carries a non-NULL value. It fails only when every selected field is NULL.
Apply coverage. At 100% coverage, any failing row causes the check to fail. Below 100% coverage, the check fails only when the passing fraction drops below the threshold (see Coverage and Tolerance).

The evaluation is symmetric across the selected fields: their order does not matter. Empty strings, zeros, and false are treated as values, so they satisfy the check. Only SQL NULL counts as missing.

NULL Handling

Any Not Null is a completeness rule, so NULL is the value it looks for. Row-level behavior:

All selected fields NULL → the row fails.
At least one selected field non-NULL → the row passes, even when the other selected fields are NULL.

Because a NULL in some fields (but not all) does not fail the row, Any Not Null is a weaker constraint than a per-field Not Null on every field. Use Any Not Null when the row is considered complete as long as at least one alternative is present.

Fields are inspected as-is; there is no transformation or comparison against sentinel values. If your source data uses a placeholder such as "" or "N/A" to mean "missing", either normalize it upstream with a Computed Field or add a companion rule that treats those placeholders as violations.

The Filter Clause

The filter clause is a SQL WHERE expression applied before the evaluation. Filtered-out rows are ignored entirely (they cannot trigger a violation and are not counted in the totals).

Common uses:

Restricting the check to a subset of the dataset (tenant_id = 42, status = 'active').
Excluding known-incomplete legacy rows that are tracked by a separate clean-up task.
Scoping the check to a partition (event_date >= '2025-12-01').

When a filter is set, both the Record Anomaly and the Shape Anomaly messages end with [filter: <expression>] so the evaluated scope is visible in the alert.

Coverage and Tolerance

Coverage is a fractional value between 0 and 1 that defines the minimum fraction of evaluated rows that must pass:

1.0 (100%, default): every row in the filtered set must pass. Any failing row causes the check to fail. This is the strictest setting.
< 1.0: the check tolerates a fraction of rows failing. The check fails only when the fraction of passing rows drops below the threshold.

Lower coverage values are useful when a small, known fraction of rows is expected to fail (for example, during a slow backfill). Use coverage carefully: a 0.5% tolerance can mask a real regression that happens to fall just under the threshold.

The Resulting Anomalies

At 100% coverage, Any Not Null reports violating rows as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset. The two templates are:

Record Anomaly

None of the fields '<field_list>' have a value assigned

Shape Anomaly

For the fields '<field_list>', X.XXX% of N records (K) have no value set for any field

When a filter is set, both Record and Shape Anomaly messages end with [filter: <expression>].

Scan settings can group a large number of Record Anomalies into one rolled-up Shape Anomaly. This behavior applies across rule types and is documented under Maximum Record Anomalies per Check.

What the Numbers Mean

<field_list>: the comma-separated list of selected fields.
X.XXX%: the fraction of filtered rows that fail the check.
N: the total number of rows the check evaluated (after the filter, if any).
K: the number of rows that fail the check.

Source Records Behavior

Every selected field that is NULL on a violating row is highlighted with an orange outline and an orange-tinted background in the Source Records view, mirroring the platform's standard violation rendering. Fields not part of the check render normally.

Custom Anomaly Description

Any Not Null supports Custom Anomaly Description because it emits Record Anomalies. When anomaly_message_field (or the Custom Anomaly Description toggle in the UI) points at another column on the same row, the Record Anomaly message becomes the value of that column. When the referenced column is null, missing, or empty, the standard template is used instead.

Because the option only applies to Record Anomalies, it does not affect Shape Anomalies, which always use the fixed template.

Relationship with Other Rule Types

Any Not Null belongs to the completeness family. Use it together with the rules below when a single constraint is not enough.

Rule Type	Why pair it with Any Not Null
Not Null	Not Null enforces that every selected field is populated. Any Not Null enforces that at least one is populated. Use Not Null when every field is required; use Any Not Null when the row only needs one of several alternatives.
Field Count	Field Count asserts that the dataset has exactly the expected number of columns. Pair the two to cover both layers: Field Count guards the shape of the table, Any Not Null guards that each row carries data in at least one of the alternative columns.
Expected Values	Expected Values validates that the values fall within an allowed set. Any Not Null does not inspect values; combine the two when at least one field must be present AND the values it holds must come from a known list.
Matches Pattern	Matches Pattern validates the format of a value when present. Pair with Any Not Null to require that at least one contact field is populated AND that populated values match the expected format.

Introduction: formal definition, field scope, and general/anomaly properties.
Examples: three production scenarios with sample data and resulting anomalies.
API: payload shape and field notes for creating an Any Not Null check programmatically.
FAQ: short answers to the most frequent questions.