Entity Resolution Recipe Examples
Real scenarios showing the recipe taking a table from suspected duplicates to a golden set. Pick a tab to see how the fields, the threshold, and the remediation choices differ with the data.
Merging customer records with name variations
Context. A sales operations team keeps a customers table in a Snowflake datastore that has been profiled and has an enrichment destination linked. Over the years, the same companies were entered several times with different spellings ("Acme Corp", "ACME Corporation", "Acme Corp Ltda") and slightly different emails. Each entry has its own customer_id, so a plain uniqueness check finds nothing wrong. They open Recipes, choose Entity Resolution, and select the table.
What happens. AgentQ suggests customer_id as the distinction field, since it is complete and fully unique. On Compare Fields, it suggests company_name as a fuzzy string with the highest weight, billing_email as a fuzzy string with a lower weight, and country as an exact comparison helper, with a threshold of 0.75. The team applies the suggestion, leaves Blocking Fields empty, and validates. The dry run on a sample reports a few dozen entities among the duplicates and the assessment Configuration looks good. The full scan groups several hundred records into entities; on Remediate they accept the AI picks for most entities and hand-pick the record with the most recent activity where the model preferred an older one. They write both outputs and finish with a golden set and an _inverse output of the discarded duplicates.
Why it works. Fuzzy matching on the name absorbs spelling variation, and the email adds independent evidence so that two unrelated companies with similar names do not merge. Country as an exact compare field lowers the score for similar-looking companies in different countries without ruling them out, which is the right treatment for a field that is usually, but not always, consistent. Keeping the check active means the next scan raises an anomaly for any new duplicates, which Remediate in Recipe hands straight back to this step.
Cleaning a supplier list with inconsistent formatting
Context. A procurement team consolidated supplier records from three regional systems into one suppliers table. Phone numbers arrive with and without country codes, addresses use different abbreviations, and tax IDs are reliable within a country but were issued by different authorities. Duplicates across regions are rare and always mean a data entry error, while duplicates within a region are the real problem.
What happens. They pick supplier_id as the distinction field and, in the optional Blocking Fields view, select country: records from different countries are never compared, which also keeps the scan fast. On Compare Fields they add legal_name as fuzzy with Pair substrings on, so "Müller GmbH" and "Müller" pair, tax_id as an exact comparison with a high weight, and phone as fuzzy with a small weight. They start at the default threshold and validate. The dry run assessment reads Consider adjusting the match threshold with a suggested 0.80, because suppliers sharing only a phone number were matching. They Apply the suggestion, validate again, and the sample now groups only records that also agree on the name or the tax ID. After the full scan they keep one record per entity, preferring the one with the tax ID filled in, and write the golden set.
Why it works. The blocking field encodes a rule the team is certain about, so it belongs in Blocking Fields rather than Compare Fields: it removes cross-country pairs before scoring and shrinks the number of comparisons. Substring pairing handles short-form names without loosening the whole match. Validating twice on the sample cost seconds and caught a threshold that would have over-merged the full table.
Keeping several golden records in one catalog entity
Context. A retailer's products table lists items by sku, but the same physical product was often re-created when suppliers changed, with a new SKU, a slightly different title, and a price that drifted by a few percent. Some near-identical titles are legitimately different products (a 500 g and a 1 kg pack), and those must not be merged.
What happens. The team selects sku as the distinction field and configures title as a fuzzy string, brand as an exact comparison, and unit_price as a Relative numeric comparison with a 5% tolerance. They set the threshold to 0.85, Strict matching, because a false merge is worse for them than a missed one. The scan groups the re-created products correctly, but a handful of entities also contain the different pack sizes. On Remediate, for those entities they tick more than one record in the Keep as golden column: the preferred record for each duplicated product, and the record of the genuinely different pack. Every ticked record is retained in the golden set; only the unticked duplicates go to the excluded table.
Why it works. The relative price tolerance turns a drifting number into useful evidence instead of noise. A strict threshold keeps merges conservative, and remediation is where the human judgment lives: the recipe requires at least one record per entity but lets you keep as many as the entity really contains, so a cluster the check drew too wide is fixed by selection rather than by loosening or tightening the whole configuration.
Rerunning the recipe after each monthly load
Context. The customer master from the first scenario receives a fresh load from the CRM every month, and new duplicates arrive with it. The team does not want to rebuild the configuration each time.
What happens. The Entity Resolution check the recipe created is still Active on the table. After the load, a team member opens the check on the datastore page and clicks Scan in Recipe. The recipe opens directly at the Scan step with the check's configuration loaded; they click Scan, review the results, pick golden records for the new duplicates, and materialize. When the monthly scan runs from a schedule instead, the anomaly it raises carries Remediate in Recipe, which opens the Remediate step with that anomaly's duplicates already loaded.
Why it works. The recipe is a guided flow around an ordinary check, not a separate object, so the check keeps working between runs like any other check. The entry points let the team skip straight to the phase that needs a human, and each run replaces the golden set output for that source table, so the enrichment destination always holds the latest resolution.
See Also
-
Best Practices
Guidelines for preparing the asset, choosing fields, tuning the threshold, and remediating.
-
Permissions
The roles and team permissions behind each step of the recipe.
-
How It Works
The phases, the two prerequisites, what the run reads and writes, and AgentQ's role.
-
Build and Validate
Select Asset, Distinction Field, Compare Fields, Match Threshold, Review, and Validate, step by step.
-
Scan and Remediate
The full scan, choosing golden records, writing the golden set, and the completion summary.
-
Entry Points and Resuming
Open in Recipe, Scan in Recipe, Remediate in Recipe, and how progress is kept between visits.