Recruit CRM Duplicate Candidates: When to Merge and When to Review

A duplicate candidate is not a cleanup task until you know what the two records represent. Two profiles may belong to one person. They may also hold different consent, job history, client feedback, or source context that a recruiter still needs to inspect before an apparently tidy database change turns into a lost operating record.

Recruit CRM has more than one duplicate path. A detected match during candidate entry can lead to a field-by-field update review. A manual merge combines records and permanently deletes the secondary record. A bulk import can match on one chosen identifier and can be configured to override existing data. Those are different decisions with different evidence requirements.

This guide is a review method, not a claim about a connected Recruit CRM account. The example records are synthetic. Check the account's permissions, duplicate settings, and current vendor documentation before changing a live candidate.

Start with the decision, not the name match

Ask one question first: can the team demonstrate that both profiles represent the same person and that the selected primary record should keep the operational history?

Name similarity cannot answer that question. Recruit CRM says in its duplicate-record guide that its candidate duplicate detection uses email address, phone number, or LinkedIn profile URL. A person who changed email address or has two profiles with different identifiers can therefore need human review even when the names look similar. A matching identifier is useful evidence. It is not permission to discard the other record without checking it.

Use three outcomes:

The boundary is simple. Updating a confirmed existing profile can be a controlled data-change decision. Merging removes a record. Stop there.

Understand what Recruit CRM detects and changes

As checked on November 9, 2026, Recruit CRM documents candidate duplicate detection against email, phone number, and LinkedIn profile URL. When the Allow Duplicates setting is off, its help center says a detected match updates the existing record instead of creating another candidate. When the setting is on, matching records can still be created. Confirm that setting before treating a duplicate count as an application defect.

The current Add Candidate comparison flow has another important detail. Recruit CRM says it fills empty fields from the incoming information before showing a comparison page for fields where existing values can be reviewed and potentially updated. Eligible changed fields are selected by default, and the reviewer can deselect or edit them before applying the update. Required fields must be valid at the point of application.

That behavior gives a recruiter a useful review surface, but it does not settle field ownership. For example, a newly parsed phone number may be more recent than the old value. A source, consent, or availability field may be owned by a different process. Keep a short rule for each field that can affect outreach, job submission, or reporting: which source can update it, what proof it needs, who handles a conflict, and whether the incoming value should wait for a person who knows the candidate's current status.

For an identity and field-ownership method that applies beyond Recruit CRM, use the CRM data quality playbook. It covers the separate task of defining record identity before an automation or cleanup changes data.

Make an ambiguous-match review small and inspectable

Do not send every possible pair into a large cleanup project. Use a review record that makes the decision reproducible:

These are design cases, not an observed Recruit CRM workflow. A good queue records the two record IDs, the evidence considered, the decision, the reviewer, and any follow-up owner. Keep it small. It should not copy a full resume or sensitive notes into an unprotected spreadsheet.

Treat a merge as retirement of the secondary profile

Recruit CRM's current manual-merge documentation says the selected secondary record is permanently deleted and cannot be restored. That makes a merge unsuitable for a tentative identity check or a way to hide an import discrepancy. It also changes the evidence standard: the reviewer must be able to explain why the records are the same person, why the selected primary profile is the right operational record, and what they inspected before removing the other profile.

Before merging, capture the primary and secondary IDs, the identity evidence, the reason for the primary choice, the associated jobs or placements that need inspection, and the reviewer. Recruit CRM also documents candidate-history behavior after a merge, including rules for preserving assignment histories. Read those rules against the records in front of you, especially when the same candidate appears in the same job on both profiles.

After the merge request completes, verify the result in the primary profile and record the completion notification or other account evidence. Do not rely on a planned merge, a queued request, or a reduced duplicate count as proof that the right history survived. Check the record.

Keep imports and merges separate

An import may need duplicate handling, but it is not a substitute for an ambiguous-person review. Recruit CRM's current bulk-import guide says the importer can merge duplicates on one selected identifier for candidates: email, LinkedIn URL, or contact number. It also offers an Override Data choice for imported values.

Choose the match identifier before mapping the file. Exclude an ambiguous pair upstream from the upload and place it in the team's separately implemented review queue; the native importer documents matching by the selected key, not an ambiguous-pair hold. Then test a small, permissioned sample containing an approved clear match, a changed value, and an unmatched record, while separately testing that the ambiguous pair was excluded. For the approved match, document the selected key, Override Data setting, and resulting fields. Keep the sample out of production until the field and ownership rules are agreed.

The Recruit CRM migration-validation guide covers a broader import or reload decision, including source snapshots, mapping, pilot scope, and reconciliation. Use it when the question is whether a batch can safely enter the ATS. Use this guide when the question is whether two candidate profiles can safely become one.

Measure the exception path, not an invented cleanup rate

Start with counts from your own review period: possible matches received, pairs held for evidence, confirmed updates, approved merges, and records that remained unresolved. Keep the source and date with each count. A lower duplicate number is not automatically better if it was achieved by merging records that should have stayed distinct.

If the team needs help setting the record rules, review queue, import acceptance cases, or a connected-system boundary, Recruit CRM consulting can scope the work around the records and decisions that matter. Bring two redacted profiles, the evidence your team would accept as a match, and the person who owns the final merge decision.