Reconciliation rules: which value wins in the unified profile | Cleon

A ruleset in Data 360 (formerly Data Cloud) identity resolution has two halves. Match rules decide which source records are the same person and group them; reconciliation rules decide, for that group, which value of each attribute survives into UnifiedIndividual__dlm. This page is the second half. Match rules build the cluster; reconciliation rules pick the winner inside it, one attribute at a time.

The distinction is easy to skip and expensive to skip. A source individual carries a first name, an email, a phone, an address from each system it came from. When three source records collapse into one unified individual, that profile cannot hold three first names — it presents one. Reconciliation is the rule that says which one. And that single chosen value is what every downstream consumer reads: the email a segment filters on, the phone activation sends to, the address a journey personalizes with.

What reconciliation runs over

Reconciliation never runs on its own. It runs over what match rules already grouped — and only over that. The set of source records feeding a single UnifiedIndividual__dlm is fixed by matching before reconciliation looks at a single attribute. Get the matching wrong and reconciliation is moot: if two different people were merged, reconciliation is now choosing the "winning" email between two customers, and whichever wins, the profile is wrong about someone. If one person was split across three unified individuals, reconciliation runs three times in isolation and none of the three profiles is complete.

So read this page as the second move, never the first. The traversal from a source record to the unified individual it landed in always goes through IndividualIdentityLink__dlm — that link is what tells you which source values were even candidates for a given unified attribute. Source and unified are never a direct join; the link object is the only honest map of the cluster reconciliation operated on.

The four reconciliation options

For each attribute, you choose how the winner is selected from the candidate source values in the cluster:

Most Recent — the value from the source record with the latest last-modified timestamp wins. The instinct "the newest data is the truest data" — right for a contact detail a person actively updates, wrong when "most recently touched" is a batch job, not the customer.
Most Frequent — the value that appears across the most source records wins. Useful when many systems agree and one is an outlier — five sources say Maria, one says Mara, frequency picks Maria. It is a vote, so it inherits the biases of which systems you ingest: three feeds derived from one bad import outvote two correct ones.
Source Priority / Sequence — you hand reconciliation a ranked list of data sources, and the value from the highest-ranked source that has a value wins. This is the deterministic option: the system of record for email is the CRM, full stop, and recency never overrides it. Predictable and auditable in a way the other three are not.
Last Updated — the value from the most recently updated source record. In practice this overlaps heavily with Most Recent; the line that matters is whether your timestamp reflects a human update or a pipeline one. If a nightly sync stamps every row as "updated" at 2am, both recency options are measuring the sync, not the customer.

Per-attribute selection vs the ruleset default

Reconciliation is set per attribute, not once for the whole profile. A ruleset carries a default policy, and you override it attribute by attribute where the default is wrong. That granularity is the point: the right rule for email is rarely the right rule for birthdate or for a loyalty tier.

A profile usually wants a mix. Email and phone — details a person actively maintains — often suit Most Recent, if your timestamps reflect real edits. Birthdate, which should never change, suits Source Priority pointed at the most trustworthy source, so a typo in a low-quality feed can't overwrite a verified value just by being newer. A status that a billing system owns suits Source Priority with billing ranked first. Set the default to your safest general policy, then override the attributes where "safest" and "correct" diverge.

The failure to watch: accepting the ruleset default on every attribute because configuring each one is tedious. That is how a profile ends up with a correct email and a birthdate that flips every time a marketing list re-imports — nobody chose that, the default did.

When to prefer a source-priority list over recency

Recency answers "what's newest." Source priority answers "who do we trust." They diverge precisely when newest and most-trustworthy are not the same record — which is most of the time at scale.

Prefer a ranked source list when:

One system is the genuine system of record for the attribute — CRM owns the verified email, the billing platform owns the account status — and you want that authority to hold regardless of which feed happened to write last.
A low-quality or high-volume source would otherwise win on recency alone. A nightly enrichment feed that touches every row is "most recent" every night; priority lets a quieter, cleaner source outrank it.
The result has to be auditable. "The CRM value won because the CRM is ranked first" is an answer you can defend to a business owner. "The value from whichever pipeline ran last won" is not.

Prefer recency when the attribute is something the customer changes and the change should propagate fast — a freshly updated mobile number, a new mailing address from a move — and you trust the timestamp to mean a real update. Most contact-point attributes sit on this line, which is exactly why the timestamp-hygiene question decides it.

Why this is principle 4, not configuration

Reconciliation is the half of identity resolution that quietly assigns the customer their "true" email, name, and address — and like match rules, its failures are silent. No error fires when the wrong value wins. The profile simply presents a stale email, and the first you hear of it is a bounce report or a customer who stopped getting messages they expect.

That makes reconciliation a business decision, not a checkbox — principle 4. Which source is authoritative for email, whether birthdate should ever change, what "most recent" actually measures in your pipelines: these are answerable only with someone who owns the data. And like every rule in the ruleset, changing reconciliation triggers reprocessing across the org — the unified values shift for every affected individual, so it is budgeted and validated, not toggled.

Match rules — the first half: how source records get grouped into one person before reconciliation picks a winner inside the group
The unified individual — what reconciliation writes into: UnifiedIndividual__dlm and the IndividualIdentityLink__dlm bridge
Identity resolution gotchas — the production version, including the "wrong value won" surprise and reconciliation under reprocessing

Reference: