Skip to main content

The unified individual: how Data 360 resolves many profiles into one

What identity resolution produces: the unified individual. UnifiedIndividual__dlm vs the source ssot__Individual__dlm, the IndividualIdentityLink__dlm bridge that maps source to unified, why source-to-unified traversal always goes through that link and never a direct join, and why counting the wrong object silently breaks every metric downstream.

Reference·Last updated 2026-06-01·Drafted by Lira · Edited by German Medina

Identity resolution in Data 360 (formerly Data Cloud) has one job and one output: take the many source records that describe the same human and produce a single resolved profile — the unified individual. Everything else in this subcategory — match rules, reconciliation rules, the keys you resolve on — exists to make that one output correct. This page is the spine: what the unified individual is, how it relates to the source records it was built from, and the one traversal rule you cannot get wrong.

If you arrive from Marketing Cloud, the instinct is to picture a deduplicated table. It isn't one. The source records are not deleted, merged, or overwritten. They stay exactly as they landed, and identity resolution builds a new object alongside them that points back at all of them. Understanding that two-layer shape — source below, unified above, a bridge between — is the whole page.

Two objects, not one: source vs unified

There are two individual DMOs, and confusing them is the most expensive mistake in the subcategory.

  • ssot__Individual__dlm — the source individual. One row per individual per source. If the same person exists in your CRM, your e-commerce platform, and a newsletter list, that's three rows here. Standard DMOs carry the ssot__ namespace and the __dlm suffix; this is one of them.
  • UnifiedIndividual__dlm — the resolved individual. One row per real person, produced by identity resolution after it decided which source rows are the same human. It drops the ssot__ prefix on purpose — the name signals it is post-resolution, not source-aligned.

The source layer is what you ingested. The unified layer is what identity resolution concluded. They answer different questions — "how many records do we hold?" versus "how many people do we know?" — and they return different numbers by design.

The count relationship: unified is always ≤ source

Because matched source rows collapse into one unified individual, the arithmetic only ever runs one direction:

count of UnifiedIndividual__dlm ≤ count of ssot__Individual__dlm

They're equal only in the degenerate case where every source record is a distinct person and nothing matched. The moment any two records resolve to the same human, the unified count drops below the source count — and that gap is the deduplication identity resolution performed.

This is why counting the wrong object is not a rounding error. If your "active customers" metric counts source individuals, it silently double-counts anyone who exists in two systems. Switch it to unified individuals and the number drops — not because you lost customers, but because you stopped counting the same person twice. Metrics that mix the two objects across reports never reconcile, and the discrepancy looks like a data bug long before anyone suspects the grain (principle 4 — identity is a business decision, and the count is the first place that decision shows up).

The bridge: IndividualIdentityLink__dlm

The unified individual doesn't store which source rows it was built from. That mapping lives in a separate object: IndividualIdentityLink__dlm, the bridge identity resolution maintains. Each row in the link object ties one source individual to the one unified individual it resolved into.

That shape — many source rows, each linking up to one unified row — is what lets the unified count stay below the source count. It also means the relationship is modeled through the link, not stored as a foreign key on either side. There is no column on ssot__Individual__dlm that names its unified individual, and no column on UnifiedIndividual__dlm that lists its sources. The link object is the relationship.

The traversal pattern

To go from a source individual to its unified individual — or the reverse — you join through the link object in two hops. The exact field names follow your org's model; the shape is the constant:

-- Source individual -> its unified individual, traversed through the link.
-- Two hops, never a direct join. Alias and qualify every column.
-- link/source join-field names (e.g. SourceRecordId/UnifiedRecordId) follow your org's model
SELECT
  src.ssot__Id__c            AS source_individual_id,
  uni.ssot__Id__c            AS unified_individual_id
FROM ssot__Individual__dlm src
JOIN IndividualIdentityLink__dlm link
  ON link.SourceRecordId__c = src.ssot__Id__c
JOIN UnifiedIndividual__dlm uni
  ON uni.ssot__Id__c = link.UnifiedRecordId__c;

The same bridge runs the other direction. To see which source records collapsed into one unified individual — the query you reach for when a profile looks over-merged — start from the unified row and fan out through the link:

-- One unified individual -> all the source records that resolved into it.
-- More than a handful of distinct sources for one person is a smell worth checking.
SELECT
  uni.ssot__Id__c                       AS unified_individual_id,
  COUNT(DISTINCT link.SourceRecordId__c) AS source_record_count
FROM UnifiedIndividual__dlm uni
JOIN IndividualIdentityLink__dlm link
  ON link.UnifiedRecordId__c = uni.ssot__Id__c
GROUP BY uni.ssot__Id__c
ORDER BY source_record_count DESC;

Counting source rows per unified individual is also how you measure the deduplication: a unified individual with one linked source record was never matched to anything; one with five means identity resolution folded five source rows into a single person. (For the full clause behavior and the IS NOT DISTINCT FROM nullable-key join, see Data Cloud SQL.)

What the unified profile aggregates

Once source records resolve into one unified individual, the profile becomes the single place a downstream consumer reads the person from — but it doesn't physically copy every field. Two things happen:

  • Attributes are reconciled. When two source rows disagree — different last-modified emails, two postal addresses — reconciliation rules decide which value wins on the unified individual. That selection is its own surface; see reconciliation rules for how Most Recent, Source Priority, and the rest pick the winner.
  • Contact points attach to the unified individual. Email and phone live in their own DMOs — ssot__ContactPointEmail__dlm, ssot__ContactPointPhone__dlm — and once their owning source individuals resolve, those contact points belong to the unified individual. A person with three source records can carry every email address all three contributed, now reachable from one resolved profile. This is why a segment built on the unified individual can target a person across every channel any source knew about, instead of treating each source's copy as a separate audience member.

The unified individual is, in other words, the one coherent answer about a person assembled from fragments that arrived separately. That coherence is exactly what makes the model agent-ready (principle 10): if a human analyst can get a single, correct picture of a customer from the unified profile, so can an agent grounded on it. If identity is broken — the person fragmented across three unified rows, or two people merged into one — neither the analyst nor the agent can answer, and no amount of prompt engineering fixes a profile that resolved wrong underneath.

Related

  • Match rules — when Data 360 decides two source records are the same person
  • Reconciliation rules — once matched, which attribute value wins on the unified individual
  • Data Cloud SQL — the dialect you traverse the link object and count the unified profile with
  • Data 360 principles — why identity is a business decision (4) and agent-readiness is a property of the model (10)

Reference: