.svg)
Product
.png)
Table of content
Every recruiting team has run this play without meaning to.
A candidate applies through your career site on Monday. On Wednesday, an agency submits the same person for an adjacent role. On Friday, an employee refers them. By the following week three recruiters are working the same human being, and each one believes they found a fresh lead.
Nobody made a mistake. The system simply allowed one person to exist three times.
That is the gap a duplication check closes. It rarely wins a demo, and it usually decides whether the hiring data you report to your CHRO six months from now is worth reporting at all.
What a duplication check actually does
A duplication check compares incoming applicant data against records that already exist in your ATS, and flags anything that matches. The matching runs on unique identifiers and defined field combinations, so a returning candidate is recognized as the same person rather than created as a new profile.
The purpose is not to block candidates. It is to make sure one person equals one identity in your system, whichever door they walked through.
What duplicate records actually cost you
| What breaks | The risk it creates | Who feels it first |
|---|---|---|
| Applicant counts and funnel rates | Decisions made on inflated numbers | Head of TA, CHRO |
| Source attribution | Disputed agency fees and referral payouts | Finance, vendor management |
| Recruiter time | Hours lost reconciling profiles | Recruiters, TA Ops |
| Candidate communication | Three recruiters, one candidate, one bad impression | Candidate experience owners |
| Data subject requests | Deletion that misses half the records | Data protection officer |
1. Duplicates corrupt the numbers before anyone reads them
If the same candidate exists three times, your applicant count is wrong, your source mix is wrong, and your conversion rates are wrong. Every dashboard built on that data inherits the error, and the team ends up optimizing a version of hiring that does not exist. This is the quiet kind of recruitment debt that compounds until someone tries to reconcile a quarter and cannot.
2. Source attribution decides who gets paid
This is where duplicates become expensive rather than untidy. Source identification drives accurate reporting, cost allocation, and any honest read on which recruitment channels are working. When one candidate lands under three sources, you cannot answer basic questions. Do we owe the agency a fee? Does the employee get the referral bonus? Is the career site performing, or absorbing credit for candidates sourced elsewhere?
Duplicate records turn attribution into a negotiation. Clean records turn it into a fact.
3. Recruiters absorb the reconciliation
Multiple applications for the same role create duplicate entries, which means more administrative overhead sorting profiles, harder progress tracking, and delays in the hiring process. None of that work shows up in a report, and every recruiter feels it. At high application volume, it stops being an irritation and becomes a capacity problem.
4. Candidates notice, and it costs you
A candidate contacted three times about the same job by three recruiters does not conclude that your company is thorough. Preventing repeated contact and consolidating communication is a candidate experience control, not only a data hygiene one.
5. Fragmented identity makes privacy harder
Deletion requests, retention clocks, and audit trails all assume you know which records belong to which person. Under the DPDP Act and GDPR, a candidate asking to be forgotten expects that to clear everywhere. If one person exists as four records, one request becomes four problems, and the one you miss is the one an auditor finds.
How RippleHire handles duplication
RippleHire treats duplication as a configurable control rather than a fixed rule, because a hiring process in India and one in the US need different definitions of the same person.
It matches on the identifiers that actually identify
Duplication checks run on exact matches across:
- First name + Last name + Date of birth, where all three must match
- Email ID
- Phone number
- PAN number
When a potential duplicate is detected, the system flags the candidate record rather than silently creating a second profile.
The combination is yours to choose, per entity
Rather than forcing one rule across a global workforce, RippleHire offers five pre-built combinations that administrators select at entity level.
| Option | Matching logic |
|---|---|
| 1 | First Name + Last Name + DOB, or Contact Number, or Email ID, or PAN Number |
| 2 | First Name + Last Name + DOB, or Contact Number, or Email ID |
| 3 | Contact Number, or Email ID |
| 4 | Email ID |
| 5 | Email ID, or PAN Card |
Options 1, 2, or 5 are recommended for India. Options 2, 3, or 4 are recommended for the US. If date of birth is not a mandatory field on your application form, options 3 or 4 are the safer choice. One duplication check is enabled per entity, which keeps behavior predictable for everyone working inside it.
Setup takes four steps. Go to Admin Settings, then Candidate Settings, then Application Setup, then Duplication Check. Select a combination and submit. The check applies to the candidate application form immediately.
Aadhaar and SSN are excluded on purpose
Neither is supported as a duplication parameter, and that is a design decision rather than a gap.
Data privacy best practice requires collecting the least sensitive data necessary, and email, phone, or name plus date of birth already achieve reliable de-duplication without asking a candidate for a government ID. There is a conversion argument too. Asking for Aadhaar on an application form drives candidate drop-off, which means the field costs you applicants as well as compliance exposure.
Cool-off settles who owns the candidate
Preventing duplicate records is half the problem. The other half is deciding which channel owns a candidate when two of them claim the same person. RippleHire handles this through candidate cool-off, a configurable mechanism that limits source exclusivity for a defined period.
During cool-off, the original source retains ownership, other sources cannot treat the candidate as a fresh applicant, and duplicate validation stays active so duplicate submissions are blocked.
Cool-off rules are built from four components: the source, the round or stage, a time period calculated from the application date, and an optional extension rule tied to a specific stage. A typical configuration gives a vendor six months of ownership across Applied through Technical Round 1, extending by three months if the candidate reaches Offer Accepted.
When the period expires, the system acts on its own. The source updates to Direct, duplicate errors stop firing, and the candidate becomes available for fresh consideration. No manual intervention, no support ticket, no argument about who submitted first. Teams use this to manage agency and employee referrals fairly, control cost per hire, and keep an audit trail that holds up.
Identity survives the candidate's journey
Each candidate is anchored to an RHID. After cool-off expiry, a reapplying candidate keeps the same RHID while the previous application is archived for reference, so history, collaboration notes, and source changes stay traceable. Archival works differently: it generates a new RHID and treats the person as a new profile. Two tools for two intents, and recruiters can see which one applied.
The exceptions are built in
- Restricted stages are protected. A candidate sitting in a stage such as Hired cannot be re-submitted. The system blocks reapplication and raises a duplicate profile error.
- Archived candidates are ignored during duplicate checks, so closed-out records do not generate noise.
- Bulk uploads self-clean. If duplicate resumes are uploaded for the same candidate, the duplicate is not processed.
- Cloning bypasses the check deliberately. When a recruiter uses Add Candidate to Another Job, the new application is tagged to the candidate's existing profile with its own RHID, because reusing a strong candidate across openings is a good outcome rather than an error. Administrators control who can do this, and who may change source while doing it.
That last point matters more than it looks. A rigid duplication check is as painful as no check at all. The useful version knows the difference between an accidental duplicate and a deliberate one.
Configure it properly: a checklist for TA Ops
Run through this before you call the setting done.
- Pick per entity, not globally. Match the combination to the geography and to which fields are mandatory on that entity's application form.
- Check DOB first. If date of birth is optional on your form, options 1, 2, and 5 will behave inconsistently. Use 3 or 4.
- Map your cool-off rules to your vendor contracts. The ownership window in the system should match the window in the agreement, or you will still be arbitrating fees by email.
- Decide who can clone, and who can change source while cloning. These are separate permissions for a reason.
- Test a reapplication. Submit the same candidate from a second source during cool-off, confirm it is blocked, then confirm the RHID is retained after expiry.
- Test a deletion request. Confirm it clears every application linked to the email, across entities.
Choose RippleHire for hiring data your reports can stand on
Duplication check is not a headline feature. It is infrastructure, and it shows up in the things leadership actually asks about.
- One candidate equals one identity, with configurable matching per entity and geography
- Source attribution that survives multi-channel sourcing, so referral and agency payouts have a defensible answer
- Cool-off rules that enforce source exclusivity automatically, without recruiter intervention
- RHID-anchored candidate history, with audit logs and collaboration records maintained across reapplication
- Privacy-conscious matching that achieves de-duplication without collecting government ID numbers
Recruiters stop reconciling profiles and start working candidates. Finance gets an answer it can sign off on. Candidates hear one coherent voice from your company instead of three.
If your source reports and your referral payouts currently disagree with each other, duplication is usually the reason. Book a RippleHire demo and we will walk through the configuration options for your entities and geographies.
Frequently asked questions
What is a duplication check in an ATS?
It is a control that compares incoming applicant data against records already in the system and flags matches, so the same person is not created as multiple candidate profiles. Matching runs on unique identifiers such as email, phone, or a name and date of birth combination. The goal is a single identity per candidate regardless of which sourcing channel they arrived through. Without it, applicant counts, source reporting, and candidate communication all drift out of accuracy.
Which fields should a duplication check match on?
It depends on your geography and on which fields are mandatory in your application form. Email is the most universal identifier and works everywhere. Phone number and a name plus date of birth combination add coverage where candidates use multiple email addresses. PAN suits Indian hiring where it is already collected. If date of birth is optional on your form, avoid any combination that depends on it, because the check will behave inconsistently.
Should Aadhaar or SSN be used to detect duplicates?
No. Data privacy best practice requires collecting the least sensitive data necessary, and email, phone, or name plus date of birth already achieve reliable de-duplication without a government ID. Collecting national identifiers at application stage expands your compliance obligations for no matching gain. There is a practical cost too, since asking for Aadhaar on an application form increases candidate drop-off.
How does a duplication check affect employee referrals and agency submissions?
It decides who owns the candidate when more than one channel submits the same person. A cool-off rule gives the original source exclusivity for a defined period, during which other sources cannot treat that candidate as a fresh applicant. When the period expires, the source typically converts to Direct and the candidate can be re-engaged. This is what turns referral and agency fee disputes into a system answer rather than a negotiation.
Does a duplication check stop a candidate applying to more than one job?
It should not, and a well-configured one does not. Applying to several roles is a legitimate outcome, and recruiters often want to move a strong candidate to an additional opening themselves. In RippleHire, cloning a candidate to another job deliberately bypasses the duplication check, tagging the new application to the existing profile with its own RHID. The check exists to prevent accidental duplicate identities, not to limit genuine interest.
