COMPOSITE PATTERN

Identity Resolution

Connect different identifiers that represent the same business entity across systems and over time.

Separate stable business identity from changing source identifiers so historical joins, merges and migrations remain explainable.

Problem

The same real-world entity can have different IDs across systems.

A customer may have one identifier in CRM, another in billing and a different identifier in a policy or contract system.

Historical reporting becomes unreliable when those identifiers change, merge, split or become visible at different times.

Without a historized identity layer, one business entity can be counted several times or several real entities can be collapsed into one.

Duplicate entitiesBroken joinsIncorrect attributionLate identity correctionsUnsafe merges

Interactive example

CRM and ERP use different identifiers for the same customer.

Compare a stable identity mapping with a false split and an unsafe merge.

Source identifiers

CRM

Customer IDC1001

ERP

Customer IDK9981

Resolution result

Two source IDs resolve to one business identity

Business identityB-42

CRM customer C1001 and ERP customer K9981 are historized as identifiers of the same business entity.

Key idea

Preserve every source identifier and its temporal mapping. The canonical business identity should unify history without erasing lineage.

Core concepts

Business identity should remain stable even when source identifiers change.

Identity Resolution creates a stable business identity and maps source-specific identifiers to it through historized relationships.

Preserve source identifiers

Keep the original system and source key as immutable lineage.

Assign a business identity

Resolve identifiers to one stable canonical business ID.

Historize mappings

Track when each identifier-to-business mapping is valid and visible.

Model merge and split history

Preserve predecessor and successor relationships instead of rewriting identity.

The business ID is the durable analytical identity. Source IDs remain evidence and lineage, not replacements for the business entity.

Why it happens

Identity mappings are historical facts themselves.

Cross-system identifiers are not always stable. They can be created late, corrected later, merged into canonical identities or split into multiple entities.

In historical models, identity is therefore not only a matching problem. It is also a time-dependent relationship problem.

CRM + billing integrationMaster data managementSystem migrationsMerge historySplit historyConformed dimensions

Common modeling approaches

Model identity mappings as historized relationships.

Stable business ID

Create one canonical identifier that does not change when source systems or source keys change.

Source identifier bridge

Store source_system, source_id and business_id together with temporal validity.

Merge lineage

Preserve predecessor identities and the effective date of a merge.

Split lineage

Preserve the original identity and map successor identities explicitly.

Identifier bridge

business_id | source_system | source_id
B-42        | CRM           | C1001
B-42        | ERP           | K9981

Validation checks

Historical identity should remain stable and explainable.

✓ Stable business identity✓ Historized identifier mappings✓ No accidental entity splits✓ No unintended entity merges✓ Cross-system lineage preserved✓ Merge and split dates are explicit✓ Regression-tested joins

Why it matters

Identity Resolution creates one coherent history across systems.

Without identity resolution, the same customer or product can appear as multiple disconnected histories.

With a stable business identity, source-system changes do not break longitudinal reporting or historical attribution.

Preserved lineage also makes merges, splits and corrections auditable instead of silently rewriting the entity graph.

RELATED TEMPORAL MODELS

How Identity Resolution connects to other historical patterns

Identity resolution provides the stable entity foundation required by cross-system conformance, relationship history and deterministic historical matching.

Relationship History

Models changing relationships between identities and other business entities.

Historical Conformance

Uses resolved identities to compare source histories for the same entity.

Historical Winner Selection

Applies deterministic precedence when multiple identity candidates remain.

Rectangle Decomposition

Aligns independently historized identity and attribute relationships into stable temporal regions.

Related Patterns

Relationship History Historical Conformance State Modeling Historical Winner Selection Rectangle Decomposition

Try it

Review a historical identity resolution strategy.

Use the Historical Data Assistant to reason about source identifiers, canonical business keys, merge lineage and split history.

Open Historical Data Assistant →