Matches Pattern Best Practices

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

Anchor by default, relax deliberately

Most patterns describe the entire value, so start with ^...$ and remove the anchors only when the field genuinely carries surrounding text. An unanchored pattern that passes almost everything is the most common way this check ends up providing false comfort.

Keep the expression readable and documented

A dense expression is hard to review and easy to break. Prefer the simplest form that captures the rule, and restate the intent in plain language in the check's description ("three uppercase letters, a dash, four digits"), so the next person can tell a bug from a deliberate constraint.

Prefer a dedicated rule when one exists

For a finite vocabulary use Expected Values; for lookups against another table use Exists In; for lengths use Max Length or Min Length. Those state the intent more clearly than an expression that encodes the same rule.

Pair with Not Null when the field is mandatory

NULL values pass. The rule asserts that present values have the right shape; it does not require the field to be populated. Add Not Null on the same field when presence is part of the rule.

Test the expression against real data before activating

Use Validate on the check form, and keep the check in Draft while you iterate. A pattern that is slightly too strict floods the anomaly queue on its first Active scan, which costs more trust than the defect it was meant to catch.

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 break the rule. 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 while a known set of legacy rows is being cleaned up.

Scope with a filter instead of loosening coverage

When the rule only applies to part of the table (one segment, one channel, 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.

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