Letters, IDs, and acknowledgements on an employee file

Three document classes on the employee file

An employee file usually holds three document classes: employment letters (offer, appointment, revisions), identity and supporting proofs, and acknowledgements (policies, SOPs, handovers). Store them against the employee record with dates and access control. Files evidence fields; they do not replace department, manager, or status.

The employee information checklist lists fields to collect. The sibling article on master data versus supporting documents explains why searchable fields and PDFs are different jobs. This page lists the document classes that sit beside those fields on a personnel file. Later employment events that generate more letters or handovers belong with Dayzen employee lifecycle, not as a second letter-catalogue article.

Dayzen employee management keeps documents on the same profile as personal and job information, history, and assigned assets. Use that profile as the file, not a parallel folder named after the person in a shared drive that payroll cannot see.

Why classes matter more than a pile of PDFs

An unlabeled dump is how you lose the appointment letter behind five ID scans, or how you store a signed policy under “misc.” When a manager or auditor asks for a class of artefact, you should be able to filter or name it. Classes also support access: identity proofs usually need a smaller audience than a generic welcome PDF.

Do not store the only copy of a designation or reporting manager inside a scanned letter. If the letter says “Assistant Manager, Finance, reporting to Priya,” those facts still belong in master data so the org tree and payroll can read them. The letter is evidence that the assignment was communicated.

The file proves the record. The record runs the company.

Class 1: employment letters

These are the documents that state the employment relationship and later changes to it. Typical examples include:

• Offer letter (pre-join; may live with the candidate until activation, then on the employee file).
• Appointment or employment letter once the person has joined.
• Revision letters: compensation change, designation change, or other terms your organisation issues in writing.
• Transfer letters when an internal move is confirmed in writing.
• Experience or relieving letters at exit — generated by your exit process, stored on the same identity that is now exited.

This is not a catalogue of every letter type your counsel might draft, and it is not a substitute for a missing public article on employment-letter types. Keep the class small: documents that state terms or confirm a change of employment. Templates and legal wording are your HR and legal owners’ job.

When you attach a letter, record a date (issue date or effective date) and a short label. A file named only “scan” helps no one. After a transfer, the letter supports the dated assignment; the department and manager fields still have to change for the org tree to move.

Letters versus the hire pipeline

Offer letters often exist before the employee record is active. Hire-to-activate should land the person on one identity so the offer and the appointment are not filed under two different humans. Duplicates split the file. Keep letters with the surviving employee profile after activation.

Class 2: identity and supporting proofs

These files show who the person is for operational purposes you have already decided to collect: identity documents, address proofs, education or prior-employment proofs if your process requires them, photographs used for the directory or ID card, and bank-detail proofs if you collect those as documents rather than only as fields.

Examples teams commonly store (only if your process actually needs them):

• Government identity scans used in your joining pack (for example PAN or Aadhaar copies, where you collect them with a stated purpose).
• Address proof used at join.
• Passport-size photo for the ID card or directory.
• Cancelled cheque or bank proof if that is how you verify disbursement setup.
• Educational or previous-employment certificates if your role requires them.

Field-level collection — including a stated purpose for PAN, Aadhaar, and bank details — is owned by the information checklist, not by this page. Here the point is storage class: proofs are sensitive, should be fewer people’s business than a welcome SOP, and should sit on the employee profile rather than in an open drive. Dayzen’s add-employee wizard can validate that some identity fields are well-formed; that is not government verification, and a scan in the file is not KYC-as-a-product.

Do not treat a proof as master data. A PAN field that payroll can read is not replaced by a JPEG. If you keep both, the field is for operations; the image is evidence.

Class 3: acknowledgements

Acknowledgements show that the person received, read, or handed over something. They are not the policy itself and not the org assignment. Examples:

• Signed or recorded acceptance of an employee handbook or named policies.
• SOP read receipts or signed acknowledgements where you still keep a file artefact. Process ownership of SOP assignment lives with SOP management; the signed file is the artefact on the people record if you choose to store it there.
• Asset handover or return acknowledgements (laptop, id card, access tokens) that accompany asset records on the same profile.
• Code of conduct or confidentiality acknowledgements your organisation requires.
• Training or induction completion notes if you file them on the personnel file rather than only in a learning tool.

Lifecycle events generate many of these: join, transfer, and exit each tend to add a short stack of “I received / I returned / I read.” Store them on the same employee, dated. Do not open a new people row so the handover “starts clean.”

How the three classes sit next to fields

Class	Typical artefacts	What the record must still hold as fields
Letters	Offer, appointment, revisions, transfer confirmation	Department, designation, manager, status, joining or exit dates, compensation-related fields your payroll owns
Proofs	ID scans, address, bank proof, photo	Name, employee ID, validated identity and bank fields you actually use
Acknowledgements	Policy sign-off, SOP receipt, asset handover	Asset assignments, SOP assignment where the module tracks it, current status

If a cell on the left exists without the cell on the right, you have a folder, not a system of record. If the right exists without any left-side evidence your policy requires, you may still operate day to day — but you will scramble when someone asks for the letter. Collect on purpose, not “just in case,” especially for identity proofs.

Access, naming, and the profile as the file

Fewer people should see identity and bank proofs than directory fields. Letters can be slightly broader (HR, sometimes the employee via self-service if you offer that) but still not a company-wide share. Acknowledgements may be visible to the process owner (IT for a laptop sign-off, HR for a policy). This is operational access design, not a security-certification claim.

Name files so a future HR admin can scan the list: class, short description, date. Attach them on the Dayzen employee profile rather than only in mail. History on the profile should remain after the person exits; deleting the row to tidy the directory also deletes the file. Status taxonomy belongs in the active / inactive / exited article; the document lesson is the same identity must remain to hold the PDFs.

Self-service versus HR-held artefacts

Employees may upload some proofs during onboarding and may download their own letters if you allow it. HR (or a named owner) should still control what becomes the official file and what is a draft. Managers generally do not need identity scans for the whole company. They need team operational data. Keep proofs off the org-tree screenshot culture.

Lifecycle without turning the file into a process guide

Join: gather the proofs and letters your checklist requires, activate one employee record, store acknowledgements for induction and assets. Transfer: add a transfer letter or acknowledgement if you issue one; still update structure fields so the interactive org tree moves. Exit: store relieving-related letters and return acknowledgements on the exited profile; run Full & Final as its own process — do not restate that settlement here.

Dayzen profiles already group documents with job history and assets. Employee records remain the foundation for recruitment handoff, onboarding activation, and payroll. The file is part of that foundation only when it is classified, dated, and attached to the correct unique person.

A practical filing pass

1. Open the employee profile you already searched for uniqueness — do not start a second file for a nickname.
2. Place new artefacts into one of the three classes. If it does not fit, it may belong in another module (a project file is not a personnel proof; Dayzen PMS is project management, not a second HR folder).
3. Set a date and a human-readable name.
4. Confirm the matching master-data fields are updated (manager, department, status, identity fields you use).
5. Restrict access according to class, especially proofs.
6. Do not use the personnel file as the only org chart or the only payroll source.

When letters, proofs, and acknowledgements are separate classes on one profile, the employee file is usable. When they are a single unlabeled pile — or when they try to replace fields — you will search, fail, and recreate documents that already existed under another spelling of the same name.