Preventing duplicate people records at join

Search before you activate — every time

Prevent duplicate people records by searching before you activate: work email, personal email, prior employee ID, PAN where you collect it, and candidate ID. Duplicates usually appear when recruitment, onboarding, and HR each create “a new person.” Hire-to-activate is the pipeline; this article is the failure mode when that pipeline creates a second identity.

One living person should have one employee identity in the system of record. A second row looks harmless on day one and expensive by month three: two attendance histories, two document piles, payroll pointed at the wrong ID, and a rehire that cannot see the first employment.

Follow the hire-to-activate onboarding path so a candidate becomes an employee on purpose. Dayzen onboarding is the commercial activation surface. Dayzen employee management is the directory those activations must land in. How numbers are issued without cloning a person is the sibling employee ID issuance article. The employee management process includes confirming the person is not already in the directory before you add them — this page expands that failure mode.

Where duplicates actually come from

They rarely come from a villain. They come from handoffs that each feel locally reasonable.

Candidate already exists

Recruitment created a candidate. Someone in HR cannot find that card — different spelling, personal email versus work email, or a phone-only record — and adds an employee from the offer letter. You now have a candidate and an employee who are the same human. Conversion should be a handoff of one identity, not a copy-paste into a new row.

Employee records are the foundation for recruitment handoff and onboarding activation. If the handoff is “export names and retype,” duplicates are the default, not the exception.

Delayed joiner

The person was created for a start date that slipped. A week later, another operator “adds the new joiner” because the profile is not in the default active list, or because onboarding status is unclear. The first row still exists: incomplete, inactive-looking, or sitting in a pipeline view nobody opened. Delayed start is a status on the same person, not a reason to issue a second employee ID.

Rehire

An alumnus returns. The exited record is still there — or should be. Someone treats them as a campus hire and runs the add-employee wizard again. You lose easy access to prior documents, asset history, and pay history, and you may issue a second ID. Rehires should reopen or relink the existing identity, then return the status to active with a new assignment period. Do not clone.

If exited rows were deleted to “clean the directory,” rehire is forced to invent a new person. Keep alumni as exited records; that taxonomy is a sibling topic. Here, the rule is search the alumni, then activate.

Nickname, spelling, and contractor-to-employee

Same person, different string: “V. Sharma” versus “Vikram Sharma,” a maiden name, a personal Gmail on the candidate and a company email on the employee. Contractors who later join as employees are a planned conversion if you kept one identity; they are a duplicate if you kept two lists that never met. Search more than legal name. Use employee ID, emails, and (where you collect it for a stated purpose) PAN as match keys — not as a fishing expedition for extra documents.

A search-before-activate habit

Make the search a named step, not a courtesy. The add path should be blocked in process even when software still allows a save.

1. Collect match keys from the offer or joining pack: intended work email, personal email, phone, prior employee ID if they mention one, candidate ID from recruitment, PAN if you already hold it for a stated purpose.
2. Search the employee directory (including exited and any inactive holds), not only the default active view.
3. Search candidates in recruitment for the same keys.
4. If you find a match, stop creating. Convert, relink, or resume that row. Do not “add anyway” because the wizard is open.
5. If you find a possible match, resolve it with a human: same person or not. Do not guess from a common name alone.
6. Only then activate along hire-to-activate: unique employee record, department, designation, manager, documents as required, then handoff to attendance, leave, and payroll on the same ID.
7. Issue or confirm the employee ID from one sequence. Auto-generated IDs with organisation prefixes help only if they attach to a unique person. Two prefixes on two rows is still a duplicate. See the employee ID issuance sibling for format and uniqueness rules.

The wizard is not a search. Search first, then open the wizard on the right identity.

What Dayzen already gives you to hang this habit on

Dayzen employee management includes a paginated directory with search and role or department filters, profiles with personal and job information, history, assets, and documents, and a five-step add-employee wizard with validation for email, employee ID, PAN, and Aadhaar fields, plus auto-generated IDs from organisation prefixes. Validation is data quality. It will not notice that Vikram-the-candidate and Vikram-the-employee are the same human if you never searched. Onboarding is the activation path; the directory is where a second save does the damage.

Conversion, not copy-paste

Candidate-to-employee should change the role of the identity: the person is now an employee record that time and payroll can reuse. Copying fields into a fresh row guarantees drift the moment someone updates only one side.

If your tools require a new employee object, still treat it as a continuation: same IDs where policy allows, explicit link to the candidate, and a rule that the candidate is no longer a second living person. The operating test is simple. After activation, one search by email or employee ID returns one operational profile.

Delayed joiners stay on that same profile with a start date you can change. Do not create “Joiner 2” because the laptop request was raised twice.

If you already have duplicates

Do not delete first. Deleting the “wrong” row often deletes the payslips or documents you needed. Work out which identity other modules already used — payroll runs, attendance punches, asset assignments — and make that the survivor. Then stop using the extra row: mark it so nobody activates it, and move unique documents or notes onto the survivor if they exist only on the clone.

Merging is an operations decision with an owner. This article does not invent a one-click merge product claim. It does say that two active rows for one human is an incident, not a filing system.

Situation	Do	Do not
Candidate plus new employee	Convert or link; keep one identity for activation	Keep both as if they were different people
Delayed start, second add	Reuse the first row; update joining date and status	Issue a second employee ID
Rehire	Find the exited record; return to active on the same person	Run add-employee as a campus-style new hire without searching
Two active rows discovered later	Pick the identity payroll and time already used; retire the extra	Delete both and start a third

Why payroll and the org tree care

Payroll calculation reads the employee identity, joining date, and assignments. Two identities split LOP, reimbursements, and statutory setup into stories that never match the bank file you intended. The org tree will show two nodes, or one node and a ghost in a filter. Managers will approve the wrong person’s leave.

Assets and documents on Dayzen profiles only help if they hang off the person who actually works there. A duplicate means the laptop is on row A and the appointment letter is on row B. Fix identity before you chase the files.

Roles that must share the same search

Recruitment, onboarding coordinators, and HR admins need the same match keys and the same “do not add” rule. If only HR searches the directory while recruitment always creates candidates from a CV parse, you will meet in the middle with two records. Put the search step in the hire-to-activate checklist your team actually uses, not only in a guide nobody opens on a busy Friday.

Managers should not create people records to “get someone on the org chart.” Requests go to the owner of the system of record. A side list of joiners in a spreadsheet is how the third duplicate is born.

What this page does not own

It does not replace the hire-to-activate guide’s pipeline stages. It does not replace onboarding’s product page. It does not replace employee ID format rules. It does not walk Full & Final. It does not tell you to store extra identity documents without a purpose — collection of PAN and Aadhaar is a separate, purpose-limited topic. Here the only job is: before a person becomes an active employee, prove they are not already in the building as a candidate, a delayed joiner, or an alumnus.

When search-before-activate is boring, duplicates become rare. When it is skipped, no org tree and no payroll close will look trustworthy, because you will not know which person the numbers belong to.