Any Not Null Best Practices

Guidelines for getting reliable signal from Any Not Null checks while keeping the noise (and the maintenance) low.

Group only fields that are genuinely interchangeable

The rule passes as soon as one selected field carries a value, so every field you add makes the check easier to satisfy. Group fields that are real alternatives for the same need (three ways to contact a customer, three ways to identify an applicant). Adding an unrelated column that is almost always populated silently defeats the check: the row passes on that column no matter how empty the fields you actually care about are.

Use Not Null when every field is required

Any Not Null asserts "at least one of these". When each field must be populated on its own, use Not Null on each field instead. Both rules can coexist: Not Null on the fields that are always mandatory, Any Not Null on the optional group where one of several will do.

Remember that empty strings are values

The check tests for NULL, not for emptiness. A row where email holds '' passes, because the field is not NULL. When blank strings are a real possibility in your source, normalize them upstream (or with a Computed Field) so the absence of data is represented consistently as NULL.

Pair with a format rule when the value must also be usable

Any Not Null guarantees presence, never correctness. A row where the only populated contact field holds n/a passes. Pair the check with Matches Pattern or Expected Values on the same fields so the value that satisfies the group is also well formed.

Keep coverage at 100% unless a known backlog exists

At 100% coverage every failing row is reported as a Record Anomaly, which tells you exactly which rows have nothing in the group. Below 100% the check reports a single Shape Anomaly only when the failing fraction crosses the tolerance, and no per-row detail is produced. Lower coverage only when a known fraction of legacy rows is expected to be empty, and revisit the setting once the backfill clears.

Scope with a filter instead of loosening coverage

When only part of the table is subject to the rule (only resident applicants, only active customers, only today's partition), express that with a filter clause rather than by lowering coverage. The filter removes the out-of-scope rows from evaluation entirely and keeps the check strict on the rows that matter; the filter expression is echoed in every anomaly message, so the evaluated scope stays visible.

Choose the right rule for the job

Use Any Not Null when a row needs at least one of several alternative fields.
Use Not Null when each field is individually mandatory.
Use Field Count to guard the shape of the table itself (the columns exist), which is a different failure from a row having no data in them.

Route the anomalies to the right people

Completeness gaps usually trace back to a collection form or an ingestion mapping. Set an Anomaly Assignee from the team that owns that source, and tag the check (completeness, contact-data) so related checks are easy to find. Record in the description which fields count as acceptable alternatives, so a future reader knows whether adding one more is legitimate.