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.
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 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 |
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.
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.
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.
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.
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.
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.
Duplication checks run on exact matches across:
When a potential duplicate is detected, the system flags the candidate record rather than silently creating a second profile.
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.
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.
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.
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.
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.
Run through this before you call the setting done.
Duplication check is not a headline feature. It is infrastructure, and it shows up in the things leadership actually asks about.
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.
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.
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.
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.
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.
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.