Documents required before employee activation

Documents required before employee activation are the gate: the files and verified fields HR insists on before marking someone active for login, attendance, and payroll. Organisations write their own gate. This page does not publish a nationwide legal packing list and does not say Indian law requires every employer to collect a named set. The path that leads to the gate — form, approval, joining date, ready to activate — stays on hire-to-activate onboarding. Ongoing master-data fields after the person exists (what to keep complete on the profile over time) stay on the employee information checklist. Product context is Dayzen onboarding: new-joiner pipeline, pre-onboarding forms, auto-fill from that data, activation emails and account setup. Dayzen does not provision IT devices and does not file with the government. Activation is an HRMS state, not a statutory filing.

Activation is a switch with a reason

Active means the employee record is in the state your operations treat as “this person may use employee systems and appear in attendance and pay cycles as an employee.” It is not a legal ruling about when employment began. Offer accepted is not activated. Form submitted is not activated. A folder of PDFs is not activated until someone with authority marks the gate passed.

Write the gate as a short, named list plus exceptions. If the list lives only in a senior HR manager’s head, joiners will be activated on charm or blocked on mood. If the list is forty items including optional handbook acknowledgements, nobody will know which line actually blocks pay.

Separate three piles:

1. Blockers — without these, you will not activate (example: identity you cannot match to the offer, or bank details if your first-cycle process cannot run without them).
2. Open items allowed through — dated, owned, still required, but policy lets the record go active (example: relieving letter expected after the previous employer’s last day).
3. Later hygiene — fields the information checklist will nag over the first months, not this gate (blood group, extra emergency contacts, a second address you do not use).

Putting pile three on the gate is how activation waits on a hobby field. Putting pile one only in a chat is how someone becomes active with no identity key and you later create a duplicate to “fix” it.

How to choose blockers without inventing a statute

For each candidate item, finish one sentence: “We cannot activate because without this, this operational process cannot start.” If the process is “payroll calculation for the first cycle,” bank and tax identifiers you actually use may be blockers. If the process is “we like complete files,” it is not a blocker; it is hygiene. If the process is “a vendor BGV must be clear,” that is a policy you wrote — not a claim that Dayzen ran the check, and not a claim that every Indian employer must wait on BGV.

Common operational categories organisations may put on the gate (illustrative, not mandatory):

• Identity match — legal name and a photo identity copy that matches the offer person, stored against one employee ID.
• Joining date locked — not a PDF, but a fact the gate needs; activating with “sometime in June” breaks attendance and proration.
• Pay structure as offered — so the first cycle is not invented at freeze. The numbers come from the offer packet, not from the joiner’s memory on the form.
• Bank details — if you will pay through a process that needs them. Dayzen does not pay the bank; you still may refuse to activate a payroll-using employee with a blank account if that is your rule.
• Named statutory inputs you actually configure — only those your payroll calculation will use, collected as fields or copies per your process. This is not auto-enrolment and not a filing.
• Signed offer or appointment you treat as the employment artefact — if your process stores it before active. This is not advice on which letter is enforceable.

Education certificates, family details, and address proofs often belong on the form or in a BGV packet and still might be open items rather than blockers. Decide in writing. Do not block activation on a ten-year-old marksheet if payroll and login never read it.

Pre-hire BGV inputs are a different article and a different moment. If your gate includes “BGV report clear,” name the report and the owner. Dayzen does not produce it. Do not stall activation on “BGV” when you never sent a packet.

The gate versus the information checklist

The employee information checklist is a hygiene list for master data: what should be present, current, and correctly permissioned on an employee over time. It is the right place for field groups you audit quarterly. It is the wrong place to hide the activation switch.

Example split:

• Gate: PAN present if your first TDS calculation needs it, bank account present if you pay salary that way, joining date, department, manager.
• Information checklist later: nominee extras, alternate email, skills tags, a second emergency contact, data-quality cleanup on spellings.

If you dump the whole information checklist into “Ready to Activate,” you will either activate with fake completeness or delay people who could already work. Keep the gate short. Run the checklist on a calendar after they are active.

Master data versus document files is also a split: a PAN number on the profile is a field; a PAN scan is a file. The gate may require both, or the field plus a file stored elsewhere. Do not activate on a filename in a recruiter chat with no field on the employee. Auto-fill from the pre-onboarding form should land in fields, not only in an attachment pile.

Who may pass the gate

Name a role: HR operations, onboarding owner, or a small dual-control (HR plus payroll) if pay structure is in scope. Hiring managers should not mark Active because the person showed up. Managers do not see bank scans in a well-run process; they should not own the switch.

Passing the gate is a dated event: who, when, against which list version. If you use Dayzen’s pipeline, that is the move into Activated (or the last step your process uses before it). Humans still decide. The software will not know that a blurry scan is unusable unless a reviewer says so.

Rejected at the gate is not the same as withdrawn as a candidate. If they will join later, keep one identity, list the missing blocker, and a new date. If they will not join, use your withdrawn or cancelled path. Do not leave them in Ready to Activate forever.

Exceptions, not silent skips

Write the exceptions you actually allow:

• Relieving letter after the previous employer’s last day, with a latest acceptable date.
• Bank account opening in progress, with a temporary hold on payout method that payroll agrees to — not a surprise at freeze.
• Name mismatch with a documented alias while a corrected identity copy is in flight.

Each exception has an owner and a chase date. An exception is not “activate anyway and forget.” If you cannot name the chase, it is not an exception; it is a skip. Skips reappear as duplicate employees, wrong net pay, or an attendance enrolment that never happened.

Do not invent a legal exception category here (“as permitted under law”). If counsel has given you a rule, put it in policy. This article only requires that operational exceptions are written.

Failure modes at the gate

Symptom	Gate mistake	Fix
Active but cannot be paid	Bank or structure was hygiene, not a blocker	Move those items into pile one if the first cycle needs them
Not active, sitting at a desk	Gate includes classroom or laptop	Induction and IT are parallel; Dayzen does not provision devices
Two profiles	Blocked row abandoned; new add-employee	Search, convert, same ID
Activated on a nickname	No identity match to the offer	Block on legal name alignment
Forever “pending KYC”	Unnamed list, no exceptions	Publish blockers versus open items

Government filing is never the gate inside Dayzen. Calculating a statutory component later is payroll. Filing a return is outside this product. Do not hold activation because “PF must be filed this week” as if the HRMS were a department portal.

How the form and the checklist feed the gate

The pre-onboarding form is the intake. The gate is the decision. Review the submitted payload against the blocker list. Send back specific gaps. Auto-fill the employee details when you accept. Then, and only then, move the pipeline if your remaining blockers (signed letter, BGV report, joining date) are green or exceptioned.

The onboarding checklist can include “gate review” as a task. It should not become a second legal catalogue. The hire-to-activate guide can describe Ready to Activate as a state. This page supplies the content of that state: which documents and fields you treat as must-have.

If recruitment already collected identity in the handoff, the gate checks presence and match; it does not demand a third upload for sport. Duplicate scans are a privacy cost and a version problem (which PAN is current?).

A gate list you can start from and then cut

Start with identity match, locked joining date, role and manager, pay structure as offered, and the payment and tax fields your first cycle actually consumes. Add BGV-clear only if that is written policy. Add a signed employment artefact if you store it pre-active. Cut everything you cannot attach to a process that starts at activation. Show the list to payroll (necessities) and keep culture PDFs off the switch. When you add a blocker, say from which joining date it applies.

Activation is a gate with named blockers and named exceptions. It is not a nationwide document statute, not the information checklist, and not IT imaging. Pass it on one identity, then let hygiene and classroom work continue in their own lanes.

Keep hire-to-activate as the pipeline. Keep the information checklist as ongoing fields. Keep Dayzen onboarding as the system that can auto-fill and then activate — after a human says the gate is met. Stop before you publish a packing list you cannot defend.