Survivorship rules: picking the winner when two master records disagree

You are merging two records for the same customer. Same VAT number, same registered name, but seven fields disagree: two billing addresses, different payment terms, different industry codes, different contact emails, different phone numbers, and one record says "active" while the other says "closed". You have decided to consolidate them. Which values survive?

This is the question survivorship rules exist to answer. It is also the part of master data management most projects underestimate, right up until the week they have to merge real data and nothing is simple.

What survivorship actually means

Survivorship is the logic that picks a winning value for every field when two or more records get consolidated into one. It differs from matching. Matching decides whether two records refer to the same entity. Survivorship runs after that decision, and it runs field by field.

That means one rule per attribute. Customer name survives from the ERP. Billing address survives from the CRM. Phone number survives from whichever record was updated most recently. Industry code survives from the legal registry integration. Every attribute needs a rule, or a human decides every time.

Rules sound simple on a whiteboard. They fight back in production.

The four strategies you will actually use

Vendor documentation makes survivorship sound like a research problem. In the field it reduces to four patterns that get mixed together in different ways.

Most organizations ship a hybrid. Source priority is the default, completeness fills in when a priority-one source has a null, and recency breaks ties between two priority-one sources. Trust scores sit on a slide deck until a specific domain demands them.

Where survivorship projects go wrong

The technical failure is predictable. You write rules assuming your data is cleaner than it is. Then every edge case survives into the golden record: a source that stopped syncing six months ago, a field that got renamed without the rule being updated, a record with three nulls and two garbage strings that beats a clean record because it was touched more recently.

The organizational failure is worse. Nobody writes down why the rules exist. Two years later the legal registry starts returning "Ltd" instead of "Limited", and the survivorship engine dutifully overwrites thousands of clean records. Nobody remembers that "legal name wins from the registry" was only supposed to apply when the registry value matched a whitelist of legal suffixes.

The third failure is scope. Teams try to cover every entity and every field in a single rule set. Six months in, the spreadsheet has 400 rows, nobody understands the interactions, and stewards start overriding the engine manually — the exact thing the engine was bought to prevent.

When you actually need a survivorship engine

If you run a bank with 40 million customer records spread across five acquired systems and the regulator wants a single view of each customer by year-end, you need real survivorship tooling. Weighted trust, attribute-level lineage, confidence routing, the whole kit. That is the workload these products were built for and they do it well.

If you run a manufacturer with 20,000 suppliers, mostly in one ERP and partly in a purchasing tool, you do not. You need something simpler, and you need a human in the loop.

The industry likes to sell the first scenario's solution to everyone. That is how mid-market companies end up paying six figures a year for a match-merge engine their stewards bypass every week because the rules are wrong for two out of every five records.

A practical approach that survives contact with real data

The approach that works for most organizations has four parts.

Pick a single authoritative source per entity. Customer master lives in the CRM. Supplier master lives in the ERP. Cost centers live in the finance system. Decide once, write it down, and stop arguing. Half of every survivorship debate I have watched turned out to be a disagreement about authority that nobody had ever resolved.

Treat everything else as input, not authority. Other systems feed data into the master. The master decides what to keep. Inbound fields get validated, then either accepted or flagged for a steward. They do not overwrite master values silently.

Resolve conflicts at entry, not in a batch job. When a new record arrives from a non-authoritative source and matches an existing master record, do not auto-merge. Route the proposed change to a data steward. Five minutes of human review beats a six-month survivorship configuration project, and it catches the subtleties a rules engine never will.

Log every steward override. When a human picks a value that was not the default, capture why. That log is the training data for whatever rules you eventually automate. If you see the same override three hundred times, you have a rule. Until then, you have a case.

None of this is glamorous. It also does not require a match-merge engine, a trust model, or a consulting engagement. It requires one decision per entity and a governance practice that actually runs.

How Primentra approaches it

Primentra does not ship a match-merge engine with configurable survivorship scoring. That is deliberate.

What it gives you is the substrate that makes a simple survivorship approach work. Required unique keys that block duplicates before they enter the system. Approval workflows that route proposed merges to a data steward. And a full audit trail that records every field-level change with the reason the steward gave.

When a record needs to be merged, the steward sees both sources side by side, picks the winning value per field, and approves. The log captures which values were picked and why. No black box, no calibration drift, no engine overwriting clean records the morning someone changed a source system.

That pattern covers most mid-market MDM work. It scales to the complexity most organizations actually have, and it fails visibly rather than silently. If your real problem is ten million records across five source systems with no shared key, you need a different tool, and you probably know it already. If your real problem is one ERP, one CRM, and the occasional acquisition spreadsheet, a human-in-the-loop merge flow will outperform any rules engine you can afford to configure.

Frequently asked questions