Is Replica Of Best Practices
Deprecated: use Data Diff instead
The Is Replica Of rule is no longer maintained. Data Diff replaces it with the same row-by-row comparison plus change-type filtering. This page is kept as a reference for checks that already exist; new checks should use Data Diff.
Guidelines for getting reliable signal from Is Replica Of checks while keeping the noise (and the maintenance) low.
Migrate to Data Diff
This is the only best practice that matters for new work. Data Diff takes the same fields, the same Row Identifiers, the same Passthrough Fields, and the same Comparators, so recreating the check is mechanical. You gain change-type filtering and the maintained code path.
Keep Row Identifiers on the checks you still run
Without them an existing check can only tell you that the two sides differ, with no way to see which rows. Adding identifiers to a legacy check costs nothing and makes its anomalies actionable while you plan the migration.
Do not build new dependencies on this rule
Templates, automations, and runbooks that create Is Replica Of checks will keep working, but every new one is future migration work. Point them at Data Diff now.
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
-
How It Works
The complete reference: definition, field scope, Row Identifiers, Comparators, filter behavior, and why coverage does not apply.
-
Anomaly Reporting
What the Shape Anomaly reports and how the differing rows are presented.
-
Examples
A production scenario showing a replica that drifted from its source.
-
Permissions
The team permission each action needs: view, create, edit, archive, restore, and delete.