Decide when staffing profiles should stay separate, what must survive a merge, and who verifies that active applications still point to the right person.
A recruiter finds two candidate profiles: an older record with placement history and a newer one with current contact details. Choosing the newest profile and deleting the other looks like cleanup. It can also discard the reference another team uses to manage an interview, a submission or an active assignment.
A duplicate candidate records workflow should end with a documented decision: merge confirmed duplicates through the system’s supported process, retain legitimate separate records, or seek clarification. The objective is a usable record with preserved context—not simply a smaller database.
This operating guide is for staffing operations leads and authorized system administrators. It fits at the Review stage before engagement and onboarding, but the same issue can surface while workers are already on assignment. The controls below are recommended operating practices; the exact merge behavior comes from your recruiting system.
Separate a matching person from a duplicate application
Start by identifying what each record represents. One person can have several valid applications, submissions and assignments. Those relationships are not duplicates just because the name is the same.
Workable’s multiple-application guidance, for example, describes job-specific profiles for the same candidate and says that merging candidate profiles is not supported. A cleanup rule that assumes every person must have exactly one profile would therefore be wrong for that system.
Also separate identity cleanup from supplier attribution. The duplicate candidate submission process resolves competing submissions against the applicable terms. Consolidating a person’s records must not silently decide which supplier earns a fee or erase the evidence needed for that decision.
- Potential match: a shared name or contact detail suggests a review, not a merge instruction.
- Confirmed same person: the identity question is resolved, but the system may still require separate application records.
- Merge eligible: the same-person finding, system capability, field decisions and affected-work checks all support consolidation.
Open a review case before changing either profile
The trigger can be a duplicate alert, repeated recruiter outreach or a candidate reporting conflicting records. Assign a staffing operations owner to coordinate the case. Recruiters supply context; an authorized administrator confirms system behavior and executes any approved merge. Owners of affected applications or downstream systems verify their own references.
Record both original profile IDs and links, the matching signal, the person who reported it and any immediate work at risk. Keep sensitive candidate evidence in its approved restricted location; a broadly shared cleanup tracker needs references, not copied candidate files.
Check relevant existing information and, where needed, clarify contact changes directly through an established candidate communication channel. Do not treat the same name as sufficient proof, or collect national identifiers merely to tidy an administrative duplicate. Conflicting histories or a shared contact address should lead to clarification, not a guess.
Use explicit review states: Open → Clarification needed → Decision ready → Approved for execution → Reconciliation → Closed. “Keep separate” is a valid closing decision. If an interview is imminent, state which recruiter owns communication and what may proceed; do not let the cleanup label silently cancel the candidate’s activity.
Build a merge decision packet
Use the following packet before anyone confirms an irreversible operation. It can be a controlled form or case record. Each row needs an owner and an actual answer; “checked” without the relevant reference is not enough.
| Decision area | Record before execution | Release condition |
|---|---|---|
| Identity and scope | Original IDs, matching evidence, uncertainties, system and record types | Operations confirms same person and identifies which records may legitimately remain separate |
| Surviving reference | Proposed primary ID, reason, affected external references and administrator’s system guidance | Primary choice is compatible with active work; reference changes have named owners |
| Field conflicts | For each material conflict: both values, source/date, intended surviving value and unresolved question | Reviewer approves explicit decisions rather than relying on “newest wins” |
| Applications and assignments | Job IDs, current stages, interview arrangements, placement/assignment links and responsible recruiters | Owners agree what must remain unchanged and what must be reconciled |
| Permission and source history | Submission references, supplier/source evidence, package versions and applicable restrictions | No blanket permission or attribution is inferred from the merged profile |
| Execution authority | Decision, approver, authorized executor, method and any required specialist review | System supports the operation and the executor has the necessary access |
| Closure evidence | Execution outcome, resulting ID, field/application checks, downstream acknowledgements and residual exceptions | Every required check is complete or an authorized exception has an owner and disposition |
The packet is not an instruction to retain every document forever. Follow the organization’s approved access and retention rules, and refer unresolved restrictions to the responsible privacy or records owner before execution.
Choose the survivor by consequences, not age alone
Confirm the system’s actual field rules
There is no universal rule that the oldest, newest or fullest profile should always survive. Greenhouse’s merge documentation explains that the primary profile wins certain field conflicts, while some histories are combined. It also warns that changing the secondary candidate ID can affect downstream integrations. Check the actual record links before choosing the primary profile.
Other systems behave differently. Recruitee’s merge guidance describes keeping recent values for certain fields, choosing a stage when the same job appears more than once, and possible changes to shared access or public profile links. These examples show why a generic merge checklist needs a system-specific execution plan.
For material staffing fields, distinguish a current person-level fact from a job-specific term. A rate attached to one assignment is not automatically the candidate’s rate for another role. An availability statement collected months ago is not current merely because it sits on the selected primary record.
Preserve relationships, not just visible fields
List active jobs, interviews, submitted packages and assignments before execution. Check which systems reference either profile ID and who can verify those references. Do not assume the ATS will repair a separate scheduling, onboarding or finance record automatically.
Keep permission evidence tied to its original opportunity and package. The candidate submission permission workflow explains that boundary. A merged profile should not turn one role-specific authorization into permission for every client or job.
Worked example: one person, two live opportunities
Illustrative scenario: profile C-184 contains a completed placement and a current interview for Job A. Profile C-927 contains a recent CV, a new email address and a submission for Job B. The candidate confirms both records are theirs. The profiles show different rates and availability.
- Identify the relationships. Operations records both profile IDs, Job A’s interview and Job B’s submission receipt. The two jobs are legitimate, not competing copies to delete.
- Resolve the conflicts. Recruiters confirm which contact details are current. They retain each role’s agreed terms with that role and seek fresh availability confirmation rather than copying an old value.
- Verify merge behavior. The administrator checks whether the system supports consolidating the person while retaining both applications, how stages and permissions behave, and which external references will change.
- Make the decision. If the system supports the intended result, the approver names the primary ID and the checks required after execution. If it does not support merging, operations closes with a documented keep-separate arrangement and clear communication ownership.
- Reconcile before closure. Owners verify both applications, the interview reference, approved contact details and any external links. Candidate communication continues through the agreed recruiter.
If the records instead contain incompatible identity evidence, the case remains in clarification. A looming start date does not convert an uncertain match into an approved merge.
Execute once, then reconcile the result
Before execution, recheck that neither profile has gained a new application, interview or restriction since approval. A material change returns the packet to review. The authorized administrator then uses the supported system procedure and records the actual result.
Do not design recovery around an assumed undo button. Greenhouse explicitly says profiles cannot be unmerged. Recovery options depend on the system; a saved worksheet is evidence for investigation, not a guarantee that a merge can be reversed.
After execution, read the resulting record and reconcile it against the packet:
- Confirm the surviving ID and approved field values.
- Verify each expected application, stage, interview and relevant assignment reference.
- Check that permitted users retain appropriate access and unnecessary access has not been introduced.
- Have downstream owners confirm any required reference changes; record pending failures explicitly.
- Confirm recruiters know which record and communication channel to use next.
If the response is unclear or a relationship is missing, stop further cleanup on that case. Inspect the resulting records and escalate to the administrator or vendor support with the original IDs and execution evidence. Do not click merge again or create another candidate profile simply to make an error disappear.
Where Workhint fits
Workhint’s Workflow Engine describes configurable request steps, role-based approval routing and requirements for details, files or notes before work progresses. Those building blocks are relevant to the review envelope: an operations owner gathers the packet, a reviewer makes the decision and an authorized executor receives the approved handoff.
The Staffing Managers solution describes organizing workers through profiles, documents and approval status. That is the surrounding staffing context. Neither description establishes native duplicate detection, profile merging, ATS synchronization or automatic repair of external references.
Treat the workflow in this article as a configuration design to validate. Keep the actual merge in the system that owns the records. Before relying on a proposed setup, confirm how it preserves original references, limits access to candidate evidence and records the execution and reconciliation outcomes.
FAQ
Is the same email address enough to merge candidate records?
It can be a useful matching signal, but the reviewer still needs to establish the same-person finding and understand what the records represent. Some systems intentionally maintain job-specific profiles. A matching signal alone does not establish merge eligibility.
Should the oldest or newest candidate profile survive?
Neither is a universal rule. Choose the primary record after checking the system’s conflict behavior, active applications and external references. Document which values should survive rather than treating creation date as the decision.
Does merging resolve a duplicate supplier submission dispute?
No. Profile consolidation concerns identity records. Supplier attribution depends on the applicable terms and submission evidence. Preserve that evidence and keep the commercial decision separate.
What if the recruiting system cannot merge profiles?
Keep legitimate records separate, document the relationship in a supported way and designate communication ownership. Do not simulate a merge by deleting a record or moving information without understanding the effect on applications and history.
Leave a Reply