Cookbook
Merge the duplicates, and refuse the one that looks identical
The interesting part of this job is not the merging. It is the pair your agent will propose that you must not accept, and the fact that it cannot accept it for you.
The situation
Your workspace has been running for a while, or you have just imported from two places, and the same organisation is in there twice. Its deals are split across both copies, so no number you ask for is right.
What must be true when you are done
- One record per organisation, with the other one's history attached rather than lost.
- The deals, contacts and interactions from both are on the survivor.
- Records that merely look alike are still two records, because looking alike is not the same as being the same.
- Any merge you regret can be undone.
Ask for the survey
You
Survey this workspace for duplicates, companies and people. Show me each pair with how similar they are and why they were proposed. Do not merge anything yet.
What comes back is a list of proposals, not a plan:
| Type | Pair | Similarity | Why |
|---|---|---|---|
| Companies | Northwind Trading / Northwind Trading Ltd | 0.82 | similar name |
| People | Ada Whitfield / Ada Whitfield | 1.00 | identical name |
The one you must not accept
Read the second row again. Two people called Ada Whitfield, scored 1.00, identical name. It is the strongest match on the page and merging it would be wrong: one is the managing director at Northwind Trading and the other runs operations at a company with a similar name. They are two people who share a name, which is a thing that happens constantly and which no similarity score can see.
This is why Indraft proposes and never decides. There is no accept button on a proposal and nothing your agent can hand back to a merge: a candidate is two identifiers and the reasons they look alike, and a merge requires you to name both records yourself. The unsafe version of this operation is not something the product can express.
The score is a prompt to look, not a verdict. A 1.00 on a common name means less than a 0.82 on an unusual one, and you are the only one in this loop who knows which is which.
Merge the one that is real
You
Merge Northwind Trading Ltd into Northwind Trading. Leave the two Adas alone, they are different people. Then show me what moved.
Agent
The renewal was on the record that no longer exists and is now on the one that does. That is the point of merging rather than deleting: the deal, the contacts, the interactions and the history all move, and the survivor is the whole picture rather than half of it.
Undo one you regret
A merge is not covered by the ordinary undo, because it is not a field that changed. It has its own reversal, and your agent has the identifier it needs from the merge itself.
You
Actually those were two different companies. Put them back.
Agent
Both records are back, with what belonged to each. Unmerge works once per merge, so if you are unsure it is cheaper to leave a pair alone and look again next month than to merge and reverse repeatedly.
Verify the workspace
- Ask for the survey again. The pairs you merged are gone from it. The pairs you deliberately left are still there, which is correct: you decided they were not duplicates, and the product does not record that decision as a fact about the records.
- Check the survivor's history. Every change from both records is on it, with who made each one, so nothing was lost in the merge.
Run it again
Monthly is enough for most teams, and after any import. A survey examines a bounded number of records per call and pages through the rest, so a large workspace is a walk rather than one enormous question, and you can stop partway without leaving anything half done.