Pre-onboarding forms explained

A pre-onboarding form is one artifact: the structured questionnaire the future employee completes after offer accept and before activation, so HR does not re-key bank, address, and identity fields on day one. It is not the full hire-to-activate story. That pipeline — converting the person, remaining papers, joining date, ready-to-activate, active — stays on hire-to-activate onboarding. Post-offer HR tasks stay on the employee onboarding checklist. Product behaviour is on Dayzen onboarding: candidate pre-onboarding forms (tokenized) and auto-fill of employee details from that data. The offer-to-onboarding handoff packet is a sibling: what recruitment already collected. This page owns the form the joiner still has to type.

One artifact, not a second pipeline

Teams often copy every onboarding stage into the form (“welcome, IT, assets, payroll, culture”). That produces a 40-field survey nobody finishes and a pipeline nobody trusts. The form’s job is narrower: capture facts that will live on the employee record, from the person who knows them, once, in a format HR can accept.

If a fact already arrived in the handoff (legal name on the offer, CTC, joining date, requisition), the form should confirm or complete — not invite a conflicting rewrite. If the joiner types a different joining date than the signed offer, that is an exception for recruitment and HR to resolve, not a silent overwrite.

Dayzen onboarding includes tokenized candidate forms so you send a link, not a Word file that returns as a screenshot. Auto-fill means accepted form data can populate employee details instead of a second typing pass in the add-employee wizard. Auto-fill is not activation. Someone still reviews and the pipeline still has to reach active. Dayzen does not provision laptops, MDM, or SSO as onboarding.

When the form opens, and when it should close

Open the form after the organisation treats the offer as accepted — signed letter, portal accept, or the written channel you file — and after the handoff is accepted enough that you know which person you are collecting for. Opening it during first-round interviews trains candidates to dump bank details into a process that may reject them. That is a privacy cost with no onboarding benefit.

Set a completion deadline that leaves HR time to review before the joining date. “Anytime before Monday 9am” is how you get an empty form at 8:50. The deadline is an ops fact. It is not a legal cooling-off period.

Close the form when the data is submitted and accepted, or when the candidate is withdrawn. Do not leave a live token on a person who declined. If they later re-accept a revised offer, issue a new token against the same identity. Do not create a second candidate because the first form “expired.”

What belongs on the form

Collect fields you will store on the employee and that the joiner is the best source for. A practical core:

• Identity confirmation — legal name as they want it on the record, personal email, phone, date of birth if you collect it at this step, and identifiers you have a stated purpose for (for example PAN when payroll setup will use it). Do not turn this page into an identity-law essay; purpose and access habits for those fields live in employee-information practice.
• Address — current correspondence address, and permanent address only if you have a purpose.
• Emergency contact — a name and number you can actually call, not three relatives “in case.”
• Bank details — account name, number, IFSC if you pay salary through a process that needs them. Dayzen does not pay the bank. Collecting the fields is still how payroll later calculates against a record that finance can use.
• Family or nominee fields — only if your process actually uses them at join. Empty nominee columns that nobody processes are collection without a job.

Documents can attach to the same form when you want remaining papers in one sitting. The gate of which files block activation is a different article. The form is the intake surface, not a legal packing list. Do not put interview feedback, offer CTC rewrite, or a culture handbook that will make people abandon the data fields.

What does not belong

IT device size, VPN client version, and badge photo specifications are provisioning work. Dayzen onboarding does not do IT provisioning. If IT needs a form, it is IT’s form, linked from the checklist as a parallel task, not smuggled into the HR pre-onboarding token as if the HRMS will image a laptop.

Government filings do not belong here. Filling PF or tax nomination inside your HR form is not a filing with a department. If you collect nominee names for later use by payroll or a vendor, say that. Do not tell the joiner that submitting the form enrolled them in a statutory scheme. Dayzen does not file returns.

The full stage list from hire-to-activate does not belong as a table of contents on this page or inside the form. Stages are system states. The form is data capture that usually sits in “filling details” as an activity — not a reason to reprint Offer Sent through Activated here.

Token, identity, and the employee row

The token should point at one candidate identity that already has an application or offer record. When the person submits, HR should search the directory — including exited people — before creating an employee. Rehires especially: the form completes the existing person; it does not justify a new employee ID. Duplicate rows after a “fresh” add-employee because the form lived in someone’s inbox are a known failure mode.

Auto-fill from submitted data is useful only if field names match what the employee profile expects. If the form says “account no” and the profile says “bank account,” someone still maps them once in setup. After that, do not retype. If auto-fill is wrong, fix the mapping or the submitted value; do not keep a shadow spreadsheet “because the wizard looks empty.”

Submitted is not approved. A joiner can mistype IFSC or invert a date of birth. HR review is a named step: completeness, obvious format issues, and conflicts with the offer packet. Dayzen can hold the submitted state in the new-joiner pipeline. Humans still decide whether the data is good enough to proceed toward activation.

Who owns chase, review, and exceptions

Name owners:

1. Sender — HR operations or onboarding owner sends the token and the deadline.
2. Joiner — completes the form. They are not “bad at onboarding” if a field was unclear; fix the label.
3. Reviewer — accepts or sends back with a specific gap (“page 2 of address proof missing”), not “KYC pending.”
4. Exception owner — recruitment if offer facts conflict; payroll if bank details will not work in their process; the joiner if only they can supply a missing scan.

Chase with the same identity and the same token. A second email with a blank Excel attached is how you get two versions of the truth. If the person cannot complete a field yet (bank account not opened), record an open item with a date. Do not block the entire form if your policy allows partial submit plus a named remainder — and do not pretend a partial is complete.

The onboarding checklist can include “pre-onboarding form sent / received / reviewed” as HR tasks. It should not duplicate every field. The form is the artifact; the checklist is the task list around it.

Failure modes that are about the form, not the whole pipeline

Symptom	Form problem	What to do
Empty profile on joining date	Token sent late or never closed	Deadline before join; chase on one link
Bank details retyped three times	No auto-fill, or mapping ignored	Accept once; populate employee details from the form
Two employees, one human	Form treated as a reason to add a new row	Search, then convert; keep one identity
Joiner rewrites CTC	Compensation fields left editable	Lock offer facts; confirm only personal data
IT angry, HR confused	Laptop questions stuffed into HR form	Split IT’s request; Dayzen does not provision devices

None of these require retelling every pipeline column. They require a form that is short, identified, reviewed, and mapped.

Copy and instructions the joiner can finish

The token page should say, in plain language: why you are asking (to build their employee record before day one), what to have nearby (identity copy, bank details if you collect them), the deadline, and who to mail if a field fails. Do not hide required uploads at the bottom of a legal wall of text. This is not consent-law advice; it is usability so the artifact actually arrives.

Use field labels the person understands. “IFSC” needs an example format. “Legal name” should say “as on the offer / identity document,” not “full name” if you will later fight nicknames. Optional fields must look optional. A sea of red asterisks is how people paste dummy numbers.

If you support save-and-resume, say so, so they do not start the form on a phone in a lift. Tokenized forms still need those human instructions.

Where this artifact sits relative to siblings

Recruitment’s handoff is what TA already has. Prefer “confirm this name and email” plus new fields; do not re-ask every scan the reviewer can already see. Hire-to-activate owns when filling-details becomes submitted, approved, and activated — neighbourhood of the form, not a reprint. The onboarding checklist owns send / nag / review. Welcome SOP assignment, when you use it, happens on activation — after this form, not inside it.

If you cannot point at one token, one identity, and one submitted payload that can auto-fill employee details, you do not have a pre-onboarding form. You have another inbox.

Keep Dayzen’s candidate pre-onboarding forms as the container. Keep hire-to-activate as the stage narrative. Keep the checklist as the HR task list. This page stops at the artifact so you do not maintain three pipeline guides.