How Required Values Checks Work

Definition

Asserts that all of the defined values must be present at least once within a field.

Overview

The Required Values rule takes a list of values and confirms that each of them appears somewhere in the column. One occurrence is enough: the rule counts presence, not frequency.

It is the mirror of Expected Values, and the two answer opposite questions. Expected Values asks "is every value in the column on my list?" and reports the strays. Required Values asks "is every value on my list in the column?" and reports what is missing. Neither implies the other, which is why they are often used together.

Typical use cases:

Confirm every category of a reference dimension survived a load.
Verify that all expected enumeration values are represented.
Check that every product type, region, or status the business depends on is present.

Field Scope

Single: The rule evaluates one field per check and looks at the set of values that field holds.

Accepted Types

Type	Supported
`Date`
`Timestamp`
`Integral`
`Fractional`
`String`
`Boolean`

The rule declares no field-type filter, so a complex field (Array, Struct, Map) is not blocked either. It has no element-wise mode: Array Element Context is rejected for this rule, so the list is matched against the field itself rather than against the elements inside it.

Anomaly Types

Type	Supported
Record Flag inconsistencies at the row level
Shape Flag inconsistencies in the overall patterns and distributions of a field

Evaluation Flow

Every Required Values check follows the same three-step evaluation flow:

Apply the filter clause. If the check has a filter set, only rows matching the filter expression are considered. A required value that appears solely in filtered-out rows counts as missing.
Collect the values the column holds. The platform gathers the distinct values present in the filtered rows.
Confirm every value on the list is among them. The check passes when each configured value appears at least once. Any value on the list that is absent produces a Shape Anomaly.

Presence, Not Frequency

One occurrence satisfies the rule. A category that appears in a single row passes exactly like one that appears in a million. The rule cannot express "at least 100 orders per region": that is a volume question, not a completeness one.

It also says nothing about values the column holds that are not on your list. Those are what Expected Values is for.

How Values Are Compared

On a non-numeric field the comparison is literal. "1-URGENT" and "1-urgent" are two different values, and a trailing space makes "HIGH " distinct from "HIGH". A required value that appears in the data with different casing or padding is reported as missing.

On a numeric field both sides are read as numbers before they are compared, so 1, 1.0 and 1.00 are the same required value and the notation you type is irrelevant.

When entering the list on a text field, take the values from the data itself rather than retyping them, and be careful not to leave stray spaces around an entry.

The Filter Narrows Where the Values May Appear

Filtering makes the rule stricter, not looser: a required value must appear within the filtered rows. Scoping a check to the current month means every value on the list has to show up this month, which is often exactly the point, and occasionally a surprise.

Very High-Cardinality Columns Are Not a Good Fit

The rule examines up to 10,000 distinct values of the column, keeping the most frequently occurring ones. On a column with more distinct values than that, a rare required value can fall outside what the rule examines and be reported as missing even though a row holds it.

Use Required Values on categorical columns (statuses, regions, product types), not on identifiers or free text.

Coverage Does Not Change the Outcome

The form shows a Coverage slider because it is part of the shared check form, but Required Values evaluates the column as a set. There is no per-row pass rate for a threshold to relax, so the setting does not affect whether the check passes.

The Filter Clause

The filter clause is a SQL WHERE expression applied before the evaluation. Filtered-out rows are ignored entirely.

The anomaly message names the field and the missing values only: the filter expression is not repeated in it. When a filter scopes the check, say so in the check description, otherwise the alert gives no hint that the evaluation was narrowed.