Employee records software should let the right person maintain the right information while making access and changes explainable. Start with a field-by-field purpose and responsibility sheet, then test ordinary user accounts. Keep retention decisions separate from software defaults: a field’s presence does not establish a legal reason to collect it or how long to retain it.
An employee file may combine contact information, working arrangements and highly sensitive details. That does not mean every colleague handling an HR request needs the whole file. Before comparing screens, identify the task each role performs and the minimum information needed for that task. A useful demonstration should include what a user cannot see as well as what an administrator can change.
This guide uses Frappe HR and ERPNext documentation as product-specific examples. It does not establish Zambian employment or privacy requirements, mandatory retention periods or compliance. The original field-access worksheet is a proposed test with fictional people. General business systems and document management remain separate topics.
Which information belongs in the employee master?
Frappe HR’s Employee master captures personal, professional, joining and leave details. Its employee documentation describes a broad record. Translate that breadth into a collection decision rather than treating every available field as an instruction to populate it. Write the purpose, authorised owner and review point for each field group you intend to use.
Frappe HR supports bulk employee creation through Data Import. A proposed import review should therefore examine both the mapping and the scope of the data. Use fictional records in an isolated test copy first. Do not copy a real personnel spreadsheet into a demonstration simply because it is available or contains every column the template could accept.
Frappe HR allows a User ID to be linked to an employee. Frappe HR requires a company or preferred contact email when user creation is required. These documented links deserve a check before import: identify which fictional employee should receive a login and which record should remain an employee record without one. A personnel record and an account entitlement are related but different decisions.
Ask the demonstrator to explain how the proposed configuration separates those decisions. Keep the expected result on the worksheet, including what should happen to a row whose account-creation information is missing. Do not infer that a successful record import proves every linked account has the intended access.
How should access be checked beyond role names?
ERPNext assigns permissions to roles and roles to users. Its role-based permissions guide describes the underlying model. A role called Employee is not itself a complete access specification. Record the documents, fields and actions the proposed user should be allowed to access, then test that account rather than an administrator impersonating the business process informally.
ERPNext supports field groups with separate permission levels. This is a product mechanism to investigate when ordinary HR contact details and more restricted data share a document. Do not assume the mechanism is already configured for your requirements. Ask which field groups are in scope and inspect them through the relevant ordinary test accounts.
ERPNext User Permissions can restrict access to specific documents. Include two fictional employees in the proposed exercise and ask each test user to attempt the same view. Record both allowed and denied access. A screenshot showing one permitted record does not demonstrate that another person’s record is inaccessible.
ERPNext permission rules can distinguish printing, email, import and export access. Check those actions separately from viewing the screen. Your proposed requirement may permit a supervisor to handle a request without permitting a bulk export. This article does not claim that a particular installation has those distinctions configured or that a role name guarantees them.
| Field or action | Proposed business question | Demonstration evidence |
|---|---|---|
| Work contact details | Who needs these for an assigned task? | Ordinary-user view and permitted update |
| Sensitive personal details | Why are these being collected? | Purpose decision and restricted-field result |
| Employee-to-user link | Should this person have a login? | Expected account linkage and actual test result |
| Another employee’s record | Is cross-record access intended? | Permitted or denied result using the test account |
| Export or print | Does the task need a portable copy? | Separately tested action and agreed owner |
| Departing employee | What changes in access and record use? | Exit-state result and a separate account decision |
This is an original requirement sheet. It is not an approved retention schedule, a legal classification or a claim that all these controls are active by default.
What should happen when employment details change?
Frappe HR can store offer, confirmation and contract-end dates. Use a fictional change to one of those fields as a review case. Before editing, write who may request the correction, who checks the supporting information and what evidence the reviewer needs afterwards. These are proposed responsibilities, not documented automatic approval features.
Ask the demonstrator to show the change history that the proposed system actually provides. Record the visible before-and-after information, the actor and any limitations. The sources used here do not establish a complete immutable audit trail, so do not describe the exercise as proof of one. If history is an acceptance requirement, keep it open until the configured behaviour is demonstrated and separately documented.
Frappe HR requires a Relieving Date when an employee is marked Left. Treat that documented record rule separately from user-account access, document retention and deletion. Ask how each of those proposed responsibilities is handled; do not assume that changing an employment status automatically completes every offboarding action.
How can retention decisions avoid becoming guessed limits?
Write a retention decision register with the record category, purpose, responsible owner and authority still to be established. Leave duration unset where the applicable requirement has not been determined. A software setting or a familiar period from another country is not sufficient authority for a legal retention claim.
Include exports and attachments in the discussion. Your proposed process should identify where copies may exist and who investigates them when a retention decision is implemented. This is a design question, not evidence that a particular product locates every copy automatically. Keep legal and policy decisions with the appropriate authorised people rather than embedding invented rules in a migration template.
Original two-person access and correction exercise
Create fictional employees Sample A and Sample B in a separate test environment. Give the exercise only invented, non-sensitive values. Define an employee account, an HR maintenance account and a supervisor account, each with an explicit intended purpose. The test should not require changes to production permissions or real employee records.
For each account, record the expected view of Sample A and Sample B, then inspect the actual result. Test a permitted correction to Sample A’s fictional work contact detail. Attempt the same action using an account that should not perform it. Capture the outcome without labelling an unexecuted test as successful. Record print and export checks separately.
Next, inspect whatever history the configured system actually exposes for the correction. Compare it with the stated requirement and note missing evidence. Finally, prepare a fictional exit-state change and list the separate account and retention decisions that remain. Do not delete records or interpret the employment status as authority to do so.
The resulting sheet should distinguish demonstrated behaviour, unresolved controls and decisions that need another source. To discuss the field boundaries and remaining configuration questions, get started with the fictional matrix. For integration requirements beyond the employee record, see web development.
By Spout Team. AI-assisted drafting by Codex from the linked primary product documentation. No live personnel processing, legal review, tested audit guarantee or customer outcome is claimed.