DATIMORE · WEB-053 · SYNTHETIC EXAMPLE
One customer history the team can follow
Inspect the starting records, a confirmed match and a rejected match. The example keeps the reason for every choice alongside the retained history.
All data is invented. Names, IDs, email addresses, notes, roles and times are synthetic. This static example is not a client result, working customer management system or tested platform recovery procedure. It changes no real records. Times show sequence, not speed.
1. Starting records, kept unchanged
All four records are from one fictional customer management system. Customer numbers are checked against its separate account register; a record ID identifies a row, not necessarily a unique customer. “Missing” is not a matching value.
On a narrow screen, scroll each table sideways. Keyboard users can focus the table area and use arrow keys.
| Record ID | Customer name | Checked customer number | Linked history | |
|---|---|---|---|---|
| R-01 | Sample North Trading | C-041 | orders@north.example | O-101; N-101 |
| R-02 | Sample North | C-041 | sales@north.example | O-102; N-102 |
| R-03 | Sample South | Missing | buying@shared.example | O-103 |
| R-04 | Sample South Services | Missing | buying@shared.example | O-104 |
| Reference | Source record | Original detail |
|---|---|---|
| O-101 | R-01 | 10 September: order for 3 boxes. |
| N-101 | R-01 | 11 September: customer asked for a delivery update. |
| O-102 | R-02 | 25 September: order for 2 boxes. |
| N-102 | R-02 | 26 September: customer confirmed receipt. |
| O-103 | R-03 | 27 September: order for 4 boxes. |
| O-104 | R-04 | 28 September: order for 1 box. |
2. Rules for this demonstration
- Exact match: if both records have the same customer number, they may belong to one customer. First check the number in the same account register. The account owner still confirms identity before this example permits a merge. Here C-041 belongs to one customer.
- Possible match: similar names or a shared email lead to human review, not a merge. Missing customer numbers cannot match each other. Conflicting numbers also require review.
- Keep chosen details: use the name from the checked account register and the email confirmed by the account owner. Keep the original names, email addresses and record numbers in the unchanged original copy. Do not choose a detail merely because it was entered last.
- Keep orders and notes with the right customer: record where to find each old record's details after merging. Link each order and note once to the resulting customer record, keeping its original record number and content. Before accepting a real merge, check that the orders and notes belong to the right customer and that the right colleagues can reach them.
These are chosen rules for four invented records, not measured matching accuracy. Real rules need testing on representative data, including similar customers who must stay separate.
3. Human decisions and merge/history log
Illustrative sequence on 2 October 2026, Coordinated Universal Time. “Reviewer A” and “Account owner B” are fictional people whose decisions represent human review.
- 09:00 · Reviewer A · Review openedR-01/R-02 flagged by the exact-number rule. R-03/R-04 flagged by similar names and shared email; held unchanged.
- 09:10 · Account owner B · First pair confirmedChecked account file AF-041: both records refer to customer C-041. Confirmed name “Sample North Trading” and current email sales@north.example. These checks are invented evidence inside this example.
- 09:15 · Reviewer A · Merge accepted in the exampleCreated example record OUT-01; old IDs R-01 and R-02 now lead to it. Retained both orders and notes below. Old names and emails remain in the original copy. The new record number is chosen for this example; real systems handle record numbers differently.
- 09:20 · Reviewer A · Second pair rejectedSeparate account files AF-S1 and AF-S2 establish different customers sharing a purchasing mailbox. Keep R-03 and R-04 separate. If that evidence were unavailable, the pair would stay on hold.
| Record after review | Old IDs lead here | Retained details | History stays linked |
|---|---|---|---|
| OUT-01 | R-01, R-02 | Sample North Trading; C-041; sales@north.example | O-101, N-101 from R-01; O-102, N-102 from R-02. |
| R-03 | R-03 | Unchanged: Sample South; number missing; shared email. | O-103 from R-03 only. |
| R-04 | R-04 | Unchanged: Sample South Services; number missing; shared email. | O-104 from R-04 only. |
Result check: 4 input records become 3 working records. All 4 order references and 2 notes remain, each linked once to the correct customer and still traceable to its original record. Order quantities remain 3, 2, 4 and 1 boxes. This checks the example, not a company's performance.
4. Verify recovery before using real records
The original copy and decision log explain what changed; they do not prove that a system can reverse it. Test your system's recovery procedure on an approved test copy. Check how it restores orders and notes to their customers, who can access them and how it handles changes made after a merge. If the required history cannot be preserved or the recovery limit is unacceptable, leave the proposed merge on hold.
HubSpot says records cannot be unmerged. Creating another record does not by itself restore earlier orders, notes, access rights or automatic actions connected to the customer. This example makes no recovery promise; its steps have not been tested in HubSpot or Dynamics.
Background: Microsoft Customer Insights matching and merge preferences. Sources checked 2 October 2026. Merge rules differ between systems. These references explain product rules; they do not prove that this example has been implemented in a real system.