Between Best Practices

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

Set inclusivity deliberately on each side

The two Inclusive toggles are independent, and the difference matters exactly at the boundary, where real data tends to cluster. A discount of exactly 0, a score of exactly 100, an amount of exactly the approved ceiling: decide for each of those whether it is valid before saving the check, rather than discovering it from the first anomaly.

Prefer half-open ranges when several checks partition a scale

When you split a continuous scale into bands (0-10, 10-20, 20-30), make the lower bound inclusive and the upper bound exclusive. Closed ranges on both sides make the edge value belong to two bands at once, which produces contradictory results depending on which check you read.

Use Between for a band, single-sided rules for a floor or a ceiling

Between always evaluates both sides. When only one side is a real rule, Min Value or Max Value states the intent more clearly than a Between with an artificial second boundary. Positive and Not Negative cover the two most common floors without any configuration at all.

Pair with Not Null when the value is mandatory

NULL values pass. Between asserts that present values are inside the range; it does not require the field to be populated. When the field must also have a value, add a Not Null check on the same field.

Keep the boundaries a business rule, not a snapshot of the data

A range derived from today's minimum and maximum will start failing the moment the business legitimately grows. Anchor the boundaries to something that has meaning outside the data (a contractual limit, a physical limit, a percentage that cannot exceed 100), and record that reasoning in the description so a future reader knows whether an anomaly means bad data or an outdated rule.

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 values fall outside the range. 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 values is expected, and revisit the setting once the cleanup lands.

Scope with a filter instead of loosening coverage

When a range only applies to part of the table (one product line, one contract tier, one period), express that with a filter clause rather than by lowering coverage. The filter removes the out-of-scope rows from evaluation entirely, and the expression is echoed in every anomaly message so the evaluated scope stays visible.

Route the anomalies to the right people

An out-of-range value usually comes from an application that failed to validate its input, or from a unit mismatch upstream. Set an Anomaly Assignee from the team that owns that producer, and tag the check (range, plausibility) so related checks are easy to find.