Entity Resolution Best Practices

Guidelines for getting reliable signal from Entity Resolution checks while keeping the noise (and the cost) low.

Block on true boundaries, compare on everything else

A block field is a hard gate: records that disagree on it never become a candidate pair. That makes blocking the cheapest way to cut the search space, but it also makes it unforgiving. Block on values that genuinely cannot differ within one entity (a country code, a tenant), and leave everything that varies in the real world (names, addresses, phone formats) as comparison fields with a weight.

Do not block on a field where exceptions are possible

When a field usually matches but sometimes legitimately differs, blocking on it hides every one of those cases. Use an exact comparison helper with a high weight instead: the disagreement then lowers the composite score rather than eliminating the pair outright.

Tune the threshold from real clusters, not in the abstract

The composite match threshold defaults to 0.7, but the right value depends on how discriminating your fields are. Run the check, review the clusters it produced, then adjust. Two signals worth watching: clusters that merged records which are clearly different entities mean the threshold is too low; a run where more than 90% of records stay in single-record clusters (called out in the operation logs) usually means the threshold is too high or a fuzzy string comparison is missing.

Weight the fields that actually discriminate

A field that is nearly identical across the dataset adds cost without adding signal, and can drown out the field that really identifies the entity. Give the highest weights to the fields a human would use to decide "these are the same company", and keep low-signal fields at a small weight or out of the comparison entirely.

Normalize before you resolve

Comparison quality depends on the input. Lower-casing emails, stripping punctuation from phone numbers, and trimming whitespace upstream (or with a Computed Field) turns near-misses into clean matches and reduces the work the fuzzy comparisons have to do. A Satisfies Expression check can flag values that break the convention.

Watch for NULLs in block fields

A record with NULL in a block field cannot be paired with anything, so it silently drops out of resolution instead of being reported. Pair the check with Not Null on the block fields to make those omissions visible rather than invisible.

Scope the check when only part of the data needs resolving

The filter clause narrows the records that enter resolution. Entity Resolution also skips evaluation entirely when the target fields produce more than five million distinct combinations, which the operation logs report. Scoping to a segment, a region, or a time window keeps the check well inside that ceiling and makes each run cheaper.

Choose the right rule for the job

Use Entity Resolution when the same real-world entity appears under variations that no exact rule would catch.
Use Unique when a strict identifier must not repeat. The two complement each other: Unique guards the key, Entity Resolution guards the meaning.

Route the anomalies to the right people

A resolution failure is usually a data-entry or master-data problem, not a pipeline bug. Set an Anomaly Assignee from the team that owns the records, and record in the description which fields define the entity and why the distinction field must be consistent, so whoever reviews the clusters knows what "same entity" means for this dataset.