An employee information form starts at about a dozen fields and ends up at forty. Nobody adds thirty fields on purpose. Payroll needs a bank account, the benefits administrator needs a date of birth, somebody wants a T-shirt size for the welcome pack, a compliance review adds two declarations, and within three years the new hire on day one is filling in a page that four different departments wrote a piece of.
The result is familiar. A long form, completed in a hurry, with guesses in the fields the employee is not sure about and blanks in the ones they intend to come back to. Then somebody spends a week chasing the blanks by email. The problem is not the number of fields. It is that one page is serving three purposes at once, and separating those purposes is what makes the form short again.
Three different records are hiding in one form
Every field on an employee information form is there for one of three reasons, and the three have different urgency, different audiences and different retention rules.
The payroll and statutory record. Legal name, address, bank details, tax and social insurance identifiers, start date, salary, whatever the jurisdiction requires. This exists so that the employee gets paid correctly and so the organisation can answer a question from an authority. It is the only part with a hard deadline, because a missing bank detail means a missed payment.
The people record. Emergency contact, next of kin, right to work documentation, contract signature, probation dates. Read rarely, kept for years, and sensitive enough that access should be narrow.
The working directory. Preferred name, pronouns if the organisation asks, job title, team, manager, desk or site, work phone, chat handle, equipment issued. This is the part colleagues use daily, and it is the part most likely to be wrong in six months because it changes when someone moves team.
Those three do not belong on one page, and they certainly do not belong in one file with one access list. The directory part should be editable by the employee at any time. The payroll part should be verified and then locked. The people record should be readable by almost nobody. When a single form feeds a single spreadsheet, all three end up with the access rules of the loosest one.
The fields that earn a place on day one
Work from what breaks if the field is missing on the first payroll run. Everything else can wait, and waiting costs less than a form nobody finishes.
| Field | Who consumes it | Needed by |
|---|---|---|
| Full legal name, as it appears on official documents | Payroll, statutory filings | Before first payroll |
| Preferred name | Colleagues, email and accounts | Day one |
| Date of birth | Payroll, benefits, statutory records | Before first payroll |
| Home address | Payroll, statutory filings, post | Before first payroll |
| Personal email and mobile | Whoever needs to reach them before accounts exist | Before day one |
| Bank account details for salary | Payroll | Before first payroll |
| Tax and social insurance identifiers required locally | Payroll, statutory filings | Before first payroll |
| Start date, job title, manager, work location | Payroll, directory, access provisioning | Before day one |
| Emergency contact, name and number | Whoever is on site if something happens | Day one |
| Right to work or eligibility documentation | The people record | As the local rule requires |
Ten groups of fields, and most of them are transcription rather than thought. The field that causes the most rework is legal name, because people fill in the name they use rather than the one on their identity document, and the mismatch is discovered by a bank or a tax authority weeks later. Ask for both, label the difference plainly, and the single most common correction disappears.
Two more mechanics are worth getting right at this size. Bank details should be entered by the employee rather than dictated over a phone call or sent in a chat message, because a transcription error in an account number is discovered on payday. And the address field should be a set of separate inputs rather than one free text box, since an address typed as a paragraph cannot be sorted, matched or exported reliably into a payroll system.
What can wait until week two
Dietary requirements, clothing sizes, equipment preferences, photograph for the directory, professional qualifications, previous employment history beyond what the offer already established, bio for the team page. All of it is reasonable to collect. None of it needs to compete for attention with a bank account on somebody's first morning.
One test settles whether a field belongs on the first form. Name the person who will read the answer and the week they will read it. A field where the answer to either question is vague is a field somebody added because it seemed useful, and it will be answered carelessly because the employee can also tell that nobody is waiting for it. Fields with a named reader and a deadline get accurate answers, which is most of what a form is for.
Splitting the form in two, one short mandatory form before the start date and one optional form in the first fortnight, tends to raise the completion rate of both. The mandatory one is short enough to finish. The optional one arrives when the person has time and an actual reason to care about the answers.
The statutory part is local, and templates do not know where you are
Most employee information form templates available online are written for one country and carry its assumptions silently. Fields for tax withholding, work eligibility verification, pension enrolment and insurance identifiers differ not just in name but in what may be asked, what must be verified against a document, and how long the record has to be kept.
Two rules keep this from going wrong. First, the statutory fields should be confirmed against the requirements that apply where the employee will work, not where the template was written and not where the head office is. Second, nothing in an article or a template substitutes for advice. Anyone setting up this paperwork should confirm the specific list, the verification steps and the retention period with whoever advises the organisation on employment law and data protection.
There is one field group where caution is worth stating plainly. Information about health, disability, ethnicity, marital status or family circumstances is often collected on the same page because it is needed for benefits or for diversity reporting. It usually sits under stricter rules than ordinary contact details, and combining it with the directory means everybody who looks up a phone number also sees it. Where it has to be collected, collect it separately, tell the employee what it is used for, and restrict who can open it.
Who should be able to read which part
The default arrangement in a small organisation is one spreadsheet that the founders, the office manager and whoever does payroll can all open. It works for a while and then it does not, usually the first time a manager asks to see their team's details and the only available answer is to share everything.
A workable split looks like this. The directory fields are open to the whole organisation, because that is what they are for. The payroll and statutory fields are open to the people who run payroll and to nobody else. The people record is open to a named few, with a record of who opened it.
Getting that split with spreadsheet permissions is awkward. A sheet can protect a range from editing, but protection against editing is not protection against reading, and a tab that a manager can open is a tab they can copy. The practical route is either an HR system that models these access levels natively, or separate intake forms whose responses land in separate places with their own access lists. Where a tool charges by the number of people using it rather than by the number of forms or responses, as the pricing of this category often does, splitting one form into three costs nothing extra. The second option is often quicker to set up and it has a side benefit: each form can be sent to the person at the moment its answers are actually needed.
Keeping it accurate after the first week
An employee information form is usually treated as a one-time event, and that is why the directory half of it is wrong within a year. Addresses change, surnames change, people move team, bank accounts get replaced. Almost none of this generates a message to HR unless the employee knows where to send one.
Three habits keep the record usable.
Give the employee a way to change their own details. Anything that requires emailing HR to fix a phone number will not be fixed. A short update form, linked from somewhere findable, costs almost nothing and removes the manual step where a change is retyped from a message into a file.
Record when each record was last confirmed. Without that date, a record entered last month and one entered four years ago look the same. With it, a reconfirmation round can target the fifty stale records instead of asking everyone.
Route changes that have consequences through a person. A new bank account or a new legal name is not a directory edit, because both have payroll effects and both are targets for impersonation. Those changes need an owner, a check and a record that the check happened. A response list where each submission carries an owner and a status is exactly this, and the pattern shows up wherever an organisation takes something in and has to act on it, which is why it recurs across use cases that look unrelated on the surface.
Paper, PDF, spreadsheet, or a form with a response list
| Approach | Strength | Where it fails |
|---|---|---|
| Printed pack signed on day one | Signature is straightforward, nothing to set up | Retyping into payroll introduces errors, no way to tell what is current |
| Fillable PDF returned by email | Familiar, easy to send, no new tool | Arrives as an attachment to be filed by hand, no list view, no completion tracking |
| Shared spreadsheet, filled by HR | One place to look, sortable, exports cleanly | Access is effectively all or nothing, silent overwrites, no audit of who read it |
| Online form into a response list | Employee enters their own data, completion is visible, access can be narrowed | Depends on a login and a network, needs someone to define the fields properly |
| HR system module | Models roles and access natively, connects to payroll | Worth it once headcount and process justify the cost and the setup |
The comparison that matters is narrower than which is best. It is whether somebody currently retypes data from a message into a system, and whether anyone can tell which records are incomplete without opening them one at a time. An arrangement that fails both is generating work that will keep growing with headcount.
What to change first
Split the form. Keep only the fields that block the first payroll or the first day on the mandatory version, move the rest to a second form sent in week two, and add a last-confirmed date to whatever record the answers land in. If the current bottleneck is that completed forms arrive as email attachments somebody has to file by hand, see how a submission that arrives with an owner and a status behaves in the Halict demo.
Q1. How many fields should an employee information form have?
Only the ones that block the first payroll run or the first day, which usually comes to around ten field groups. Everything else belongs on a second form sent in the first fortnight. A long single form gets completed in a hurry, which produces guesses and blanks that cost more time to chase than the second form would have taken to send.
Q2. Can the same form collect emergency contact details?
It can, and many do, but the emergency contact needs a different refresh cycle and often a different audience than payroll data. Collecting it on the same page is acceptable as long as the answer lands somewhere that the person who might need it at night can actually reach, and as long as it gets reconfirmed rather than left at its day one value.
Q3. Is a spreadsheet good enough for employee records?
For a very small organisation it often is, on the condition that access is genuinely limited to the people who need it. The two failures to watch for are silent overwrites, where the last edit wins and the earlier one is only recoverable through version history, and read access, since protecting a range stops editing but not looking.
Q4. How long do employee records have to be kept?
Retention periods are set locally and differ by record type, with payroll and tax records usually kept longest. That makes it a question for whoever advises the organisation rather than something to copy from a template. The practical step is to record which category each field belongs to, so that deleting what is no longer needed does not mean picking through one undifferentiated file.