Employee master data versus supporting documents

Employee master data is structured, searchable fields: name, employee ID, department, manager, status, joining date. Supporting documents are files that evidence or accompany those fields: appointment letters, identity scans, acknowledgements. If the only copy of a designation lives inside a PDF, you do not have master data — you have a folder. Operations run on fields. Audits and letters run on files. You need both, on the same person, stored as different things.

The employee information checklist owns which fields to collect. The employee management process guide owns the records lifecycle. This article owns the split between structured data and attachments. Dayzen employee management holds personal and job information plus documents on the same profile; the software does not decide the split for you if you upload a scan and leave the fields blank.

What master data is

Master data is the set of facts other modules can query without opening a file. A directory filter on department only works if department is a field. A leave approval only finds a manager if reporting line is a field. Payroll calculation only knows a joining date if that date is typed (or handed off) into a date field, not buried in a scanned offer.

Typical master-data groups include identity and contact, employment identity (employee ID, type, joining date), org assignment (department, designation, manager, location), status (active, inactive, exited), and pointers to related objects such as assigned assets. Compensation-related fields, where you store them, are still master data — they are just more tightly access-controlled. Sensitive identity numbers are fields too, which is why they need purpose and access rules of their own; see collecting employee identity fields for that handling discussion.

Master data should be current, unique to one person record, and editable through a known owner. It should not be a paragraph pasted from an email. Free-text “notes” can support operations, but they are not a substitute for the fields the rest of the system reads.

What supporting documents are

Supporting documents are files: PDFs, images, signed scans. They prove a field, illustrate a decision, or satisfy a process that needs an artefact. An appointment letter supports the joining date and designation. An ID scan supports an identity number you stored as a field. A policy acknowledgement supports the claim that the person was informed. None of those files is a department code.

Document classes that usually sit on a personnel file — employment letters, identity proofs, and acknowledgements — are listed in letters, IDs, and acknowledgements on an employee file. Use that sibling when you are naming folders and artefacts. Stay here when you are deciding whether a fact belongs in a column or in an attachment.

Files are poorly searchable as a system of record. You cannot reliably filter “all Accountants hired after June” by grepping PDFs. You also cannot send a manager’s approval queue to a scan of an org chart. Treat documents as evidence attached to fields, not as the place the fields live.

Side-by-side comparison

	Master data (fields)	Supporting documents (files)
Shape	Typed values, lists, dates, IDs	PDFs, images, signed scans
Job	Drive search, workflows, reports	Evidence, letters, acknowledgements
Change	Update the field; keep history where you record job moves	Add a new file with a date; do not overwrite without a trail
Access	Directory fields are widely used; pay and identity fields stay tighter	Often tighter than directory fields; limit who can open scans
Failure mode	Blank or duplicate fields break queues	Unlabelled dumps become an unsearchable drive

Fields are for operations. Files are for evidence. Do not skip a field because a scan exists, and do not skip a letter because the field was typed.

Why mixing them creates unsearchable files

Teams mix the two when a shared drive feels faster than a form. Someone drops “Offer_Ravi_final_v3.pdf” into a folder named after a month. Six months later, HR cannot say which department Ravi is in without opening the file, and the filename no longer matches the role. The directory, if it exists, still says “TBD.” Downstream processes then invent their own shadow lists.

The opposite mix is also common: HR types everything into fields and never stores the letter. That looks efficient until a dispute, a bank, or an internal audit asks for the signed artefact. Fields without evidence are brittle. Evidence without fields is invisible to software.

A third mix is using the filename as the database, for example a scan named as if it were Finance plus Accountant plus employee ID plus join date. Filenames rot. They are not department filters. Put Finance in the department field, Accountant in designation, the code in the employee ID field, and store the PDF as an appointment letter with a date.

What belongs in each place

Put these in fields even if a document also exists

• Legal name and the employee ID you issued
• Work email and phone used for operations
• Department, designation, reporting manager, work location
• Employment type and joining date
• Record status (active, inactive, exited)
• Identity numbers you have a stated purpose to process (stored as fields, not only as a photo of a card)

If a value appears in a letter, still type it. The letter is the proof. The field is what the directory and other modules read. When they later disagree, you have a detectable exception instead of a silent drift.

Put these in documents even if the field is complete

• Offer, appointment, and revision letters
• Identity proofs and other supporting scans your process requires
• Signed policy, SOP, or handbook acknowledgements
• Handover or exit artefacts that need a file, not only a checkbox

Name files by class and date, attach them to the employee record, and restrict who can open identity scans. A pile of personal WhatsApp forwards in a group drive is not an employee file.

A working sequence at join

1. Confirm you are not creating a duplicate person.
2. Capture required master-data fields once — identity, employment, org assignment.
3. Attach the documents that evidence those fields, labelled by type.
4. Do not mark the record “complete” if either side is missing when your SOP says both are required for activation.
5. Hand the same employee ID to attendance, leave, and payroll owners.

That sequence matches the records process guide. The checklist tells you which identity, org, and document items to look for. This page only insists you do not treat a completed checklist row as done if you stored a PDF and skipped the field, or vice versa.

Keeping them in sync after join

Master data changes: promotions, transfers, manager changes, name changes, new emails. Each change should update the field (and job history where the change is an assignment event). Some changes also need a new document — a revision letter, a name-change proof. Attach the new file; do not edit the old PDF in place and pretend history never happened.

Documents can go stale without the fields changing. An old address proof does not update the address field by sitting in the folder. If your process requires a current proof, collect a new file and update the field in the same event. If you only needed the proof at join, say so in the SOP so people stop re-collecting endlessly “just in case.”

When someone exits, status is a field. Full-and-final letters and handover scans are documents. Do not delete the person row to “clean the drive”; you will lose both the master data and the files other processes still need for history.

Access is different for fields and files

Directory fields (name, department, manager) are operationally wide. Managers need them to run a team. Identity scans, bank proofs, and compensation letters are not team bulletin material. Store documents against the profile with limited access rather than in a company-wide folder named “KYC.” Field-level access and file-level access can differ: a manager may see designation and not open the PAN scan.

Dayzen profiles include document views alongside personal details, job history, and assets. Use that attachment point so files travel with the person instead of with a team share that outlives the reporting line. Do not treat document storage as an unmanaged dump. Clear naming, retention awareness, and limited access are operating practice; this article does not state retention periods as law.

How Dayzen stores both — without collapsing them

In Dayzen, employee profiles cover personal and job information, history, assigned assets, and documents. The directory remains the searchable list. The five-step add-employee wizard includes verification documents as a step alongside personal and job data, which is a reminder that both belong at create time. Validation on email, employee ID, PAN, and Aadhaar fields is about data quality in those fields, not a claim that a stored scan has been verified with a government agency.

For field lists, return to the employee information checklist. For operating rhythm, return to the employee management process. For product capabilities, see employee management in Dayzen. For what kinds of files usually sit on the personnel file, use the employee file document types article. For why sensitive numbers are collected at all, use collecting employee identity fields.

A practical test

Pick one employee at random. Without opening a PDF, can you state department, designation, manager, employee ID, and status? If not, master data is missing. Then, without hunting a personal inbox, can you produce the appointment letter or the identity proof your SOP requires? If not, the file side is missing. Fix the gap you actually have. Do not scan the entire cabinet into a folder and call it a system of record, and do not celebrate a complete spreadsheet that cannot show a signed letter.

Master data and documents are teammates. Keep them on one employee record, in two shapes, with owners who understand the difference.