Survivorship is the set of rules you configure to decide, field by field, which value wins when two or more records are merged into a single golden record.
Survivorship only runs on records that have already been identified as duplicates. Duplicate detection itself is configured on the separate Match Rules page — this page covers only what happens after a match is found.
Overview
When records from different sources describe the same real-world entity — say, a customer whose phone number or address was captured slightly differently in two systems — merging them into one golden record raises an obvious question: whose value do you keep? One source's data might be more trustworthy than another's; a timestamp field might need whichever value is most recent; a numeric field might need the highest or lowest of the conflicting values. Survivorship is where you answer that question for every field on the entity, once, so it doesn't have to be resolved by hand each time a merge happens.
You configure survivorship per entity, and it applies automatically whenever your match rules merge records. Set one strategy for the whole entity, then override it for individual fields that need different treatment.
Where to find it: Ontology › your model › Entities › the entity › Survivorship.
Survivorship Strategies
Each strategy tells the system how to pick a winning value when the same field has conflicting values across the records being merged.
| Strategy | What it does |
| Source System | Prioritizes values based on which connection they came from. You drag your connected sources into a priority order, and the value from the highest-ranked source that has data for that field wins. You can also exclude specific connections from consideration entirely. |
| Recency | Keeps the most recently updated value among the duplicates, regardless of which source it came from. |
| Minimum Value | Keeps the lowest value among the duplicates. Useful for fields like a starting price or an earliest date. |
| Maximum Value | Keeps the highest value among the duplicates. Useful for fields like a lifetime spend total or a most-recent activity count. |
Setting a Default vs. Custom Strategy
Every entity has a Default Survivorship Strategy — the strategy applied to every field unless you say otherwise. Pick one of the four strategies above as the default when you're configuring the entity.
If a particular field needs different logic than the rest of the entity, turn on Use Custom Strategy for that field and choose a different strategy just for it. For example, you might default the whole entity to Recency, but set the email field to Source System because you trust one connection's email data over others.
Custom field-level strategies support two additional controls:
Apply Filter — restrict which of the duplicate records are even considered when picking a value for this field, using conditions on the record's own data.
Add Fallback Strategy — choose a second strategy to use when the primary one can't determine a winner, such as when a Source System strategy hits a tie because none of the matching duplicates came from a ranked source.
For Source System specifically, you set the priority order by dragging connections into the order you want them evaluated, top to bottom, and can remove a connection from the list to exclude it from ever contributing a value for that field.
Notes
Survivorship only applies to fields on records a match rule has actually merged — see the Match Rules page for how merges happen.
Using Source System without a priority order, or without any duplicate coming from a ranked source, gives unpredictable results unless you've also set a fallback strategy.
An Apply Filter that excludes every duplicate leaves the field with no value to choose — pair filters with a fallback strategy.
Excluding a connection only affects the field whose strategy you excluded it on, not other fields on the same entity.
Changing a strategy affects future merges only — it does not retroactively re-resolve fields on records already merged.