A possible duplicate is a question, not a merge instruction
Two contacts may share an email address and still be different people. Start with a reviewed pair and let a person decide whether to keep them separate. Do not run a merge because a similarity score passed a threshold.
Our fictional pair is C101 and C202. The reviewer chooses C101 as the survivor. Notes N01 and N02 already belong to C101; N03 belongs to C202. C303 and note N04 are unrelated controls that must remain untouched.
Define the dependency boundary
On a small screen, scroll the table sideways to see every column.
| Table | Fields used | Purpose |
|---|---|---|
| Contacts | ContactID, Name, Email, Archived, MergedIntoID | People and retained source identity |
| Notes | NoteID, ContactID, Body | Related notes |
| MergeDecisions | DecisionID, SourceID, SurvivorID, choices, outcome | Reviewed decision and result |
The teaching file has only these dependencies. A real contact may also own invoices, tasks, external mappings, portal relationships, attachments and audit records. Inventory every dependency before offering a merge in that file. If the dependency inventory is incomplete, stop and keep the contacts separate.
Do not enable cascading deletion to make a merge convenient. This design retains the source contact as archived with MergedIntoID pointing to the survivor. It requires ordinary screens and future write paths to handle that archived identity deliberately.
Resolve field conflicts before applying
Show both names and addresses side by side. Have the reviewer choose the value to retain for each conflicting field. An empty source value must not silently erase a useful survivor value. Save the reviewed choices with the decision ID.
JSON · fictional reviewed decision
{
"decisionID": "MERGE-001",
"sourceID": "C202",
"survivorID": "C101",
"keepNameFrom": "C101",
"keepEmailFrom": "C202",
"expectedNoteIDs": ["N03"]
}These are example IDs, not a production uniqueness scheme. Require distinct source and survivor IDs, access to both records, and no existing merge chain or cycle. If the records changed after review, ask for a new decision instead of applying stale choices.
Move the notes and record the decision together
Pseudocode · reviewed merge transaction
Validate the reviewed decision and reject a replay already completed.
Open one transaction in the worker window.
Lock both contacts in a stable ID order; re-read their state.
Verify the reviewed field values and the complete dependency set.
For each source note, lock and recheck its ContactID.
Change only that note's ContactID to the survivor.
Apply the chosen survivor field values.
Archive the source and set its MergedIntoID.
Save the completed decision with before/after counts.
Commit; capture the error immediately.
On any failure, revert the whole decision and inspect the result.Prevent new related records from being added to the source during the merge. A shared write protocol or maintenance window is required for this teaching design; merely finding the current notes does not freeze the relationship. Every relevant writer must honor the protocol.
Use a unique decision ID and transactionally saved result so a repeated Apply cannot move notes twice. Keep the original source ID and the reviewed field choices available for later investigation. An audit record is not an automatic undo feature.
Verify identities, not just the new count
After a successful fixture merge, C101 owns N01, N02 and N03. C202 remains archived and points to C101. C303 still owns N04. There are still four notes and three contact records; only two contacts are active. No note body or note ID changes.
Repeat Apply and expect no additional changes. Repeat from a fresh fixture with a locked note and with a forced validation failure: the entire merge must remain unapplied. Try Keep separate and confirm no business fields change.
This is an editorial walkthrough with a reproducible fixture, not a completed customer case study. A separate native laboratory has passed reviewed field choices, Keep separate, stale-decision protection, survivor navigation, replay and coordinated-note-writer checks, alongside locked-note and schema-validation rollback. Its dependency inventory covers only Contacts and Notes. Intended permissions, independent hosted clients and additional related tables still need separate integration checks. No working-file download is offered here.
Try the small review fixture
The fictional data and review notes below accompany this article. They are not a FileMaker application, and they do not establish native test results.
References
Documentation checked on 21 October 2026. This review does not establish native execution or hosted compatibility.