One person, five identifiers: reconciling learner identity across systems

How duplicates are born

Systems assign their own identifiers. Migrations re-create accounts. People change names, move departments, become employees after being contractors, or return after leaving. Each event is an opportunity for a person to become two records. Multiply by the number of systems and a mid-sized organization can easily have a fifth of its learners represented more than once.

Deterministic rules first

Start with matches that cannot reasonably be wrong: a shared verified email, an HR employee ID present in both systems, a student number carried through. These merges can be automated with confidence and form the backbone of the identity map.

Probabilistic matching second

What remains needs scoring. Name similarity, date of birth, org unit, manager, timing of activity. Each signal contributes to a confidence score. Set two thresholds: above the upper one, merge automatically; below the lower one, reject; in between, route to a human.

Review is not optional

A wrong merge attaches one person's completions to another. That is worse than a duplicate. The review queue should show the evidence for each candidate match and record who decided what. LearningUnify keeps this log as part of the record's lineage.

Preserve the map

Every original identifier stays linked to the reconciled identity. Migration validation depends on it, auditors ask for it, and it lets you split a merge later if new evidence appears.

Privacy considerations

Matching attributes are personal data. Run reconciliation inside the governed layer under the permission model, log access to matching attributes, and apply retention to them like any other record.