Satisfies Expression Best Practices
Guidelines for getting reliable signal from Satisfies Expression checks while keeping the noise (and the maintenance) low.
Use a dedicated rule when one exists
amount > 0 is Positive. status IN (...) is Expected Values. a > b on two columns is Greater Than Field. A named rule states its intent, needs no SQL review, and produces a message that names the field. Keep this rule for the logic that genuinely has no other home.
Decide what empty values should do, and write it down
Rows where the expression returns nothing are reported. That is rarely what someone intends by accident. Add the IS NULL branch explicitly, in whichever direction you want, so the next reader can see the decision instead of inferring it.
Keep the expression short enough to read in the anomaly
The expression is quoted verbatim in the anomaly message. A three-line CASE is fine; a fifty-line one makes every alert unreadable. When the logic grows that large, move it into a Computed Field and check the result, or split it into several checks that each say one thing.
Write the description as the plain-language version of the expression
The expression says how; the description should say what and why. Whoever triages the anomaly reads the description first, and "tax must not exceed 10% of the line price" is worth far more than the SQL repeated in words.
Scope with the filter rather than inside the expression
CASE WHEN region = 'EU' THEN ... ELSE TRUE END and a filter of region = 'EU' express the same intent, but the filter runs first and evaluates fewer rows. It also keeps the expression about the rule rather than about which rows it applies to.
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
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.
-
How It Works
The complete reference: definition, field scope, what the expression must return, check variables, NULL handling, filter behavior, and coverage.
-
Anomaly Reporting
The anomaly messages the check produces, what the numbers mean, Source Records behavior, and Custom Anomaly Description.
-
Examples
Three production scenarios with sample data, anomaly messages, and the SQL equivalent of what the check evaluates.