Required Values Best Practices

Guidelines for getting reliable signal from Required Values checks while keeping the noise (and the maintenance) low.

List the values the business depends on, not every value you have seen

The list is a contract: each entry is something a downstream report, join, or dashboard assumes exists. Adding values that merely happen to be present turns the check into a snapshot of today's data and makes it fire the first time a legitimately rare category takes a day off.

Copy the values from the data rather than retyping them

On a text field the comparison is literal, so casing and stray spaces matter. Taking the entries straight from the column avoids the most common cause of a false anomaly on this rule. On a numeric field the notation is irrelevant: the two sides are compared as numbers, so 1, 1.0 and 1.00 are the same value.

Pair it with Expected Values to close both directions

Required Values proves nothing went missing; Expected Values proves nothing unexpected arrived. Together they pin a categorical column to a known set. Alone, either leaves half the door open.

Scope the filter deliberately

A filter makes the requirement stricter: every value must appear inside the filtered rows. Scoping to a recent window is a good way to catch a category that quietly stopped arriving, and a good way to create noise if the categories are seasonal.

Keep it off high-cardinality columns

The rule examines up to 10,000 distinct values. On identifiers or free text it is both slow and unreliable. For those, a referential rule such as Exists In answers the question properly.

Scope with a filter, not with coverage

When the rule only applies to part of the table (one segment, one channel, one period), express that with a filter clause. Coverage is inert here: the rule asks whether each value is present at all, so there is no per-row pass rate for the slider to relax, and the check reports a Shape Anomaly at any coverage setting.

Put the scope in the description

The anomaly message names the field and the values that never appeared, and nothing else: the filter expression is not part of it. Whoever triages the anomaly sees no sign that the evaluation was narrowed, so state the scope in the check description.

Route the anomalies to the right people

A failure usually points at the system that produced the value, not at the warehouse. Set an Anomaly Assignee from the team that owns that producer, and tag the check so related checks are easy to find.

See Also