# Duplicate people and firms A person or firm recorded twice splits their history in two: a message can go to them twice, or go out from the record that lacks their do-not-contact mark, and a deal or an introduction ends up on the record nobody reads. This guide says when to look for duplicates, what proves two records are the same, and how to merge them or fix a record that is only badly entered. ## When to look - After importing a file, a list or a batch of research, for the records just added. - Before a message to a group, for the members of its list. - When a search, a new address or a profile link turns up a record close to one you are working with. Do not sweep the whole address book unless the user asks. When they do, page through all of it and say how far you got. ## Finding candidates `find_duplicates` without `about` inspects a page of contacts and lists up to five candidates for each. Follow `next_offset` while `has_more` is true, even past a page with no candidates; `scanned_count` is how many contacts were inspected. A scan lists each pair once, under the contact that comes first. With `about`, it lists every candidate for one contact. Use `kind` to check firms as well as people. It compares names, and a similar name only suggests a match. It finds a name written in another order ("Borchers, John" and "John Borchers") or with a credential after it, but it misses a nickname ("Mike" and "Michael") and a name spelled quite differently. Search for the address, the domain or the profile link with `search_crm` as well, and read both records with `get_profile` before deciding anything. Each pair carries `first_facts` and `second_facts` to compare at a glance: a person's current firms, email addresses and live deals, a firm's domain, email addresses and live deals. It also lists a record that carries the same picture as the contact, whatever the names, with the reason `same picture`. Two records rarely share one image: either they are one person or firm recorded twice, or one of them has the wrong picture, which is how a run of invented headshots looks (in one workspace on 2026-09-29, 40 people in 18 clusters shared one image each). Read both records and check the picture's source page before deciding which it is. ## What proves two records are the same The same: - the same email address, or the same LinkedIn or other personal profile link (Ray refuses a second record with an address another record already has, so this shows up as a refusal when saving); - the same full name at the same firm, with nothing on either record that contradicts it; - for firms, the same domain or the same official website. Not enough on its own: - the same or a similar name ("Jennifer Lee" at GSV and "Jennifer Li" at a16z are two people); - the same picture (it also means one record has the wrong picture; the source page decides); - the same firm (firms have several partners); - the same city or the same interests; - for firms, similar names with different domains ("Peak Ventures" and "First Peak Ventures", "SK Capital Partners" and "LGT Capital Partners"). When the evidence is not enough, ask the user, showing what each record holds: the firm, the address, the deals and the last event. Never merge on a guess. ## Merging `merge_contacts` takes effect at once: it does not follow the capture rules and does not wait in Captures to Review, and it needs an owner. So merge only when the user asked you to clean up duplicates and the evidence above establishes the match, or when the user confirms the pair. Otherwise list the pairs and ask. 1. Read both records with `get_profile`. 2. Call `merge_contacts` with the duplicate as `source` and the record to keep as `target`. Keep the record with more history (deals, events, introductions) unless the user says otherwise. This first call is a preview and changes nothing. 3. Read the conflicts in the preview. `prefer` chooses whose values survive where the two disagree; ask the user when it matters. A do-not-contact mark on either record survives the merge. 4. Commit with `preview` false and the preview's `expected_token`. If the records changed since the preview, it is refused: preview again. 5. Read the surviving record back. The duplicate becomes an archived alias, and its refcode resolves to the survivor. The preview and the merge both say what the kept record holds (current firms, email addresses, live deals); check that against what you expected before telling the user it is done. Two firms that each have a deal in the same round block the merge. Merge them only if the user chooses to keep the duplicate's deal as archived history (`archive_source_deals`). ## A record that is badly entered, not duplicated - A name written "Last, First", or with a degree or credential after it: save it the way people say it, with `save_contact` and the record's refcode. - A firm whose domain or website belongs to someone else (another firm, or a profile site such as Crunchbase or LinkedIn): set the domain with `save_contact`, remove the wrong link with `remove_profile_item` when the user asks for the fix, and add the firm's own site with `enrich_profile`, citing the page that shows it. - A person attached to the wrong firm: tell the user what you found and ask before changing it. If they never worked there, remove the job with `save_contact` and `remove: true` on that affiliation; if they did and have moved on, end it with `ended_on`. When the user gives only a month ("left last month"), use that month's last day and tell them the day is assumed; leaving the job open shows them at both firms. Add the right firm as another affiliation, with a start date only if the user or a source gave one. - An email address or phone number on the wrong record, which also stops it being saved on the right one: remove it with `remove_profile_item` (platform `email` or `phone`) when the user asks for the fix, then save it on its owner. ## Report Say how many records you inspected, which pairs you merged and on what evidence, which you left as different people or firms and why, and which questions are open.