Candidate Merge

Pick the record carrying the most hiring activity, not the newest one. A profile holding live applications, interview feedback and email history is expensive to rebuild, whereas a thin record created last week by an import usually holds nothing but contact details. Where both carry activity, most teams keep the one linked to the open requisition so that nothing in flight breaks. Contact details are the exception to the general rule: the freshest email and phone number should win even when the older profile survives, because reachability is the point. Write the choice down as a policy rather than leaving it to whoever happens to be looking. Without one, two recruiters resolve identical situations differently, and six months later nobody can explain why one profile has a full history and its twin has none.

The intent is that everything attached to the retired record moves to the survivor, but behavior differs by system and deserves testing before you trust it. Applications normally transfer, which can leave one person holding two applications to the same job and needing manual tidying. Notes and scorecards usually carry across with their original authors and timestamps intact, and that provenance matters, since feedback loses meaning if it is silently reattributed. Attachments such as resumes and portfolios generally survive, sometimes as duplicate copies. Email threads are the least predictable part: some systems relink the whole conversation, others leave it tied to the original address where it becomes hard to find. Run a test merge on two throwaway records in your own applicant tracking system and inspect each of these before letting the wider team loose on real profiles.

Often not, or not cleanly. Once fields have been overwritten and child objects re-pointed, reversing the operation means reconstructing which value came from which record, and many products simply do not retain that. Some offer an unmerge that restores the shell of the retired record without reliably returning every note and application to it. Assume irreversibility unless a vendor demonstrates otherwise on live data. Two habits reduce the damage. Confirm the match before merging rather than after, using an identifier the two records share instead of a name that merely looks similar. Make sure every merge writes an entry to the system log recording who ran it, when, and which records were involved, so a mistake can be investigated even if it cannot be rolled back. Log coverage varies, so check it when comparing ATS features.

Restrict it. Merging is destructive in a way that most recruiting actions are not, and the people most likely to encounter duplicates are not always the people best placed to judge whether two records describe the same person. A workable split gives everyday users the ability to flag a suspected duplicate, and gives a smaller group, typically recruiting operations or a system administrator, permission to execute the merge. That group also owns the policy on which fields win and works the queue on a schedule instead of merging ad hoc. Where agencies or external partners have access, they should never hold merge rights over internal records. Permission design here is worth more than any amount of training, because the mistake is silent and the person who makes it usually has no idea anything went wrong.