Any Not Null Check FAQ

Answers to common questions about how the Any Not Null check evaluates a group of fields, how it handles NULLs and filters, and how anomalies are reported, grouped by topic.

Behavior

When does a row pass and when does it fail?

A row passes as soon as at least one of the selected fields carries a non-NULL value. It fails only when every selected field is NULL on that row.

Do empty strings, zero, and false count as values?

Yes. Any Not Null is a NULL-only check. Any non-NULL value satisfies the rule, including empty strings (""), 0, and false. If your data uses placeholders such as "" or "N/A" to mean "missing", either normalize them upstream with a Computed Field or pair the rule with a companion check that treats those placeholders as violations.

How is Any Not Null different from Not Null?

Not Null asserts that every selected field is populated on every row. Any Not Null asserts that at least one of the selected fields is populated. When one non-NULL field is enough, use Any Not Null; when every field is required, use Not Null.

Does the order of fields in the check matter?

No. The evaluation checks all selected fields against NULL at once, and their order does not affect the result.

Does the filter run before or after the check?

Before. The platform applies the filter first and then evaluates only the rows that pass the filter. Filtered-out rows cannot trigger an anomaly and are not counted in the totals.

Anomaly Reporting

What do the anomaly messages look like?

Record Anomaly: None of <field_a>, <field_b> and <field_c> holds a value

Shape Anomaly: None of <field_a>, <field_b> and <field_c> holds a value in N of M asserted records

When a filter is set, the message names it at the end of its first sentence, as (applied to records where <expression>). Record and Shape Anomaly messages both carry it.

Does Any Not Null produce Record Anomalies, Shape Anomalies, or both?

At 100% coverage (the default), violating rows are reported as Record Anomalies. Below 100% coverage, a failed coverage assertion produces one Shape Anomaly for the dataset.

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

Does Custom Anomaly Description work for Any Not Null?

Yes, for Record Anomalies. The anomaly_message_field payload field (and the Custom Anomaly Description toggle in the UI) applies.

When the option points at another column on the same row, the Record Anomaly message becomes that column's value for the violating row, shown as written. When the column is null, missing, or empty, the message falls back to the rule's standard wording, and when the column is masked the message reads <masked>. Shape Anomaly messages are unaffected.

How are the selected fields highlighted in Source Records?

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. Fields outside the check render normally.

Configuration

Does Any Not Null have rule-specific properties?

No. The check has no additional properties. In the API, send "properties": {} or omit the key.

Can I use Any Not Null on a single field?

Yes, the platform accepts a single field, but the rule is designed for two or more. With one field the semantics are identical to Not Null (the row fails when that field is NULL), so use Not Null instead: the anomaly messages are clearer.

Can I lower the coverage on an Any Not Null check?

Yes. Coverage at 1.0 (100%) means every row must pass. Lowering coverage to 0.995 allows up to 0.5% of rows to fail without raising an anomaly; once the failing fraction goes past that, the check reports a Shape Anomaly. Use lower coverage with care: a real regression that happens to fall just under the threshold will not raise an alert at all.

Can I add or remove fields on an existing check?

Yes. In the UI, open the check, change the Fields selection, and click Update; see Edit a Check for the full steps. Through the API, a PUT to /api/quality-checks/{id} updates fields along with most other fields. The rule type, the target container, and the associated Check Template stay immutable; see the API page for the editable/immutable matrix.

What permission do I need to create or edit an Any Not Null check?

The Drafter team permission on the datastore covers Draft work (creating a check as Draft or editing it while it stays Draft). Anything that puts the check into evaluation, such as creating or editing an Active check, archiving, or deleting, requires the Author team permission (or above). Viewing only requires Reporter. See Permissions for the full matrix.