Blocking in Record Matching

Blocking selects candidate pairs through shared features, narrowing comparisons without deciding identity. A postcode rule is one possible example.

Suppose a fictional hall roster compares names only within the same postcode. “North Hall” and “N Hall” enter the queue when both have that postcode. If one record lacks it, the pair may never be compared. That omission means the rule did not retrieve the pair, not that the halls are different.

Dedupe describes shared-feature comparison in its blocking explanation. For your workflow, record the actual rules and their versions. Test them against owner-confirmed matching pairs, including cases with missing or changed fields. Consider an alternative block when a useful field is absent, then inspect the additional candidates rather than accepting them automatically.

The duplicate-record review workflow preserves why each pair entered the review queue. That evidence helps distinguish candidate-coverage problems from mistaken match decisions.

For cross-source linkage, also keep each source’s namespace and grain. Shared attributes may be common across several locations or accounts. Passing a blocking rule earns a comparison, not an identity decision or permission to join the records.

Report missed known pairs separately from disputed identity decisions. The first suggests a retrieval rule needs review; the second needs source evidence and a named owner to resolve the relationship.