When a candidate should become an active employee

Operationally, a candidate, an employee record, and an active person are three different states. The path that moves someone between them belongs to hire-to-activate onboarding. Product homes are Dayzen onboarding for the new-joiner pipeline and Dayzen employee management for the directory and profiles after conversion. This page names the states so HR does not treat “offer accepted” as “they can punch, log in, and sit in this month’s payroll.” It is not a legal conclusion about when employment begins under a contract, standing order, or statute. Confirm that question with counsel and the instruments you actually signed. Do not retell every hire-to-activate stage here; the guide already owns that narrative.

Teams collapse the three states because the same human is involved. Recruitment still talks about “the candidate.” Finance asks whether “the employee” is in the run. IT asks whether the account is live. If those sentences share one informal meaning, you will activate too early, too late, or twice.

Three states, one person

Candidate

A candidate is a hiring identity: an application against a job, with interview and offer history. They are not yet a row you should treat as headcount. They may have accepted an offer and still be a candidate until HR creates or converts an employee identity. Candidate systems can hold bank details and documents; that does not make the person active. It means the packet is richer than a CV.

Keep candidate IDs searchable after conversion. Deleting the candidate because “they are an employee now” is how you lose the offer payroll later needs to match.

Employee record

An employee record is the HRMS identity for that person: a unique employee ID, legal name, and the keys you will search later. Creating or converting the record is an operations event. It is not the same as turning on access, and it is not the same as a court deciding that employment started. You may create the record days before joining so payroll, attendance, and the org chart have somewhere to attach facts. You may wait until documents clear. Either choice is policy. The requirement is one identity, not a second “temporary” row because the first is not active yet. That failure mode is duplicate employee records.

The record can exist while status is still “joining,” “not yet active,” or whatever label your pipeline uses before activation. Existence is not access.

Active

Active means operational systems should treat the person as currently employed for day-to-day work: directory defaults, attendance queues, leave, and payroll for periods they are in scope. Activation is the dated switch HR (or the onboarding owner) flips when your gate is satisfied — often on or just before the joining date. After that switch, “candidate” language should stop in internal notes except as history. Status taxonomy after join — active, inactive, exited — lives on active, inactive, and exited employee records. Do not use inactive as a parking lot for people who have not joined yet.

Offer accepted is a hiring fact. Employee record is an identity. Active is permission for work systems. Mixing the three is how you get a login without a joining date, or a joining date without a person payroll can find.

What this page is not deciding

When employment legally begins — offer accept, appointment letter, first day of work, or another test — is not answered here. Organisations use different instruments. This page will not mint a nationwide rule. If you need a legal start date for a dispute, read the contract and take advice. Operationally, still pick:

• The date you store as joining date on the employee record (payroll and attendance will trust this).
• The date and time you mark the person active (access and queues).
• The date the offer was accepted (hiring history, not a substitute for joining date).

Those three dates can differ. Write what each is for. Do not let a recruiter’s “they start Monday” overwrite a joining date HR already locked without a revision both sides file.

When to create the employee record

Create or convert as soon as the onboarding packet is accepted and you can identify one person without inventing keys. Search the directory — including exited people — first. Rehires should reopen or continue the old employee ID when policy says so, not mint a new number because the candidate portal felt like a fresh start.

Reasons to create before the joining date:

• Payroll needs structure, bank details you collect, and location before the first cycle, especially for mid-month joiners.
• Pre-onboarding data should land on one row, not a spreadsheet beside the ATS.
• The manager and HR need a place to attach the reporting line before day one.

Reasons to wait:

• Your gate says no employee ID until named documents exist. If that is the rule, write it so TA does not create a shadow row in a sheet.
• The offer is still being revised and identity keys are unstable (name spelling, entity, location).

Waiting is not the same as leaving the person only in chat. If you wait, the candidate record remains the source of truth until conversion, and someone owns the conversion date. Creating the record and leaving it inactive-as-a-workaround is worse than waiting: other modules will disagree about whether the person “exists.”

When to mark them active

Activation should follow a written gate: the fields and files you require before login, attendance enrolment, and inclusion in operational queues. Typical operational (not legal) inputs include identity keys, joining date, role and manager, and whatever documents your policy lists. The documents-before-activation article owns that packing list as a gate. This page only insists that “active” is a decision with an owner and a timestamp, not a side effect of sending a welcome email.

Common timings, all policy choices:

• On joining date, morning of. Matches “they are here.” Risk: payroll and access scramble if the record was incomplete.
• One working day before joining. Gives IT and HR a buffer. Risk: someone appears in queues before they are employed in your operational sense — write whether that is acceptable.
• After first-day documents. Safer for your gate. Risk: they work a day without a punch path unless you have a manual exception.

Do not activate because the portal says Submitted. Submitted means data arrived. Approved and joining date set are later hire-to-activate facts. Do not invent a parallel “really hired” flag in email.

Do not activate a duplicate. If two rows exist, stop. Merge or retire the extra identity before either is active. Two active rows for one human will double-count headcount and confuse payroll.

What “active” is allowed to turn on

Once active, the employee record is the identity other modules should read:

• Directory search and org reporting line.
• Attendance and leave, from joining date forward (not from offer-accept date unless you wrote that, which is unusual and confusing).
• Payroll calculation for periods that include the joining date, using the structure on the record. Calculation is not filing, remittance, or bank payout.

Activation is not IT device provisioning, MDM, or SSO auto-provisioning as a Dayzen claim. If your company issues a laptop on a ticket, that ticket is a parallel ops stream. Do not delay the employee identity because a device is late, and do not treat a device as proof of employment start.

Welcome work after activation is not this definition. Assigned welcome SOPs are actions on an already-active person, not a substitute for the status decision.

Signals that the three states have been mixed

Symptom	Likely mix-up	Fix
Payroll asks “are they an employee?” and TA says “they accepted”	Candidate treated as record	Convert one identity; store joining date
Login works, joining date blank	Active without record completeness	Block activation on the gate; do not backfill from chat
Two IDs, one human	Record created because “not active yet”	Search, convert, retire the extra row
Delayed joiner marked inactive	Pipeline person stuffed into employee status	Keep them in hire-to-activate until activate or withdraw
Rehire gets a new employee number	Candidate portal treated as a new person	Search exited records first

Withdrawn, delayed, and “they might still join”

If the offer is withdrawn or declined after a record exists, do not leave the person active. Close the pipeline state (withdrawn) and do not treat them as current headcount. If you already created an employee ID, follow your rule for unused IDs: keep the row as never-joined history, or a documented non-employee close — but do not delete identity keys you may need if they apply again.

If joining slips, change the joining date on the same person. A slip is not a new candidate and not a new employee. Recruitment renegotiates the date; onboarding updates the record; activation waits for the new date and the same gate.

If they start walking the floor before activation because “everyone knows they’re here,” you have an exception, not a new state. Either complete the gate the same day or record a dated exception with an owner. Silent floor-start plus delayed activation is how first-week attendance and first-month pay disagree.

Owners at the seam

Recruitment owns the candidate and the accepted-offer facts until the packet is accepted. HR operations (or onboarding) owns conversion and the activation switch. Managers own work after active; they do not mint employee IDs. Payroll consumes joining date and structure; it should not create a parallel person in a salary sheet.

Dayzen employee management is the directory after you have an employee identity. Dayzen onboarding is the pipeline that should feed that identity without a second typing pass. Hire-to-activate remains the stage story. This page only answers: which noun are we using, and has the active switch actually been thrown?

---

A candidate is a hiring identity. An employee record is one person in the HRMS. Active is the operational switch for work systems, usually on or just before the joining date you stored. None of those sentences is a legal start-of-employment ruling. Keep the path on hire-to-activate, keep profiles on employee management, and refuse a second row because the first is “not active yet.”