Choose HR software by tracing an employee request through identity, access, approval and correction. Define who maintains the employee record, who can act on a request and what happens when responsibilities change. A useful demonstration connects those decisions to a real workflow rather than comparing the number of fields available on an employee profile.
Start with a routine request that the organisation understands well. Leave provides a useful example because it involves an employee, dates, a responsible approver and a recorded decision. Ask the process owner to write the intended journey before reviewing product screens, and keep the organisation’s policy separate from the software’s configurable options.
Which record should own employee identity and access?
Frappe HR’s employee documentation offers a concrete starting point. The employee record can link to a user account. Existing employee records can have user accounts created later. Ask the demonstrator to show which record represents employment information and which account provides access to the application.
A person’s name is useful for recognition, but the team also needs a reliable reference for the intended employee and account. Record how those references relate in the proposed configuration. Include a person who changes their display name or department in the demonstration so ownership does not depend on recognising an unchanged label.
Employee records can store reporting relationships. Default request approvers can be set on the employee record. Discuss whether the line manager and request approver are always the same person in your organisation. If they differ, write the intended relationship explicitly rather than relying on an assumption during setup.
Give someone responsibility for maintaining those assignments. The employee who enters a request should know where it is going, while HR should know how an approver change is reviewed. Decide which parts of the record each role needs to see, then ask for evidence from the selected roles in the test configuration.
What should a leave-request demonstration show?
Frappe HR’s leave-application guide describes the workflow. Frappe HR leave applications let employees request leave and obtain approval. The leave form shows available leave by type. Confirm which leave configuration the demonstration uses before interpreting the displayed balance.
The leave request uses From Date and To Date fields. Ask the employee to enter the intended sample period and explain the information they see before saving. Compare that period with the proposed request record. A familiar-looking calendar control does not settle how the organisation wants a particular absence to be processed.
The documented approval flow allows approval, rejection or cancellation. Give each decision a clear operational meaning in the requirements. Ask what the employee should see afterwards and how the approver records an explanation where the workflow needs one. Retain a separate example for a correction so the handover covers more than the normal approval path.
The documented leave application cannot be submitted after salary processing for the period. Include that condition in the applicability discussion with the people responsible for payroll and leave. Agree the operating route for late information using the selected release and configuration, rather than inventing an override procedure.
| HR question | Requirement to write down | Evidence to request |
|---|---|---|
| Who is requesting? | Employee record and linked account | Intended person opens their request route |
| Who decides? | Assigned approver and authority | Correct person can inspect and act |
| Which period is requested? | Dates and relevant leave type | Stored request matches the sample input |
| How is a correction handled? | Reviewed correction route | Original and revised information remain understandable |
| What changes after departure? | Employment status and access ownership | Intended record and account treatment are demonstrated separately |
This original worksheet helps HR, the employee and the implementer discuss the same outcome. Add requirements that matter to the actual organisation, keeping the responsible person and required evidence alongside each one. Leave unfamiliar policy decisions with the appropriate owner rather than burying them inside configuration choices.
How should staff changes affect pending requests?
Consider the difference between changing a reporting relationship and changing the person authorised to decide a pending request. Ask the demonstrator how the proposed configuration treats both. Record what happens to an existing request as well as a newly created one, because they may need different operational decisions.
Use actual product evidence before describing automatic reassignment or notification behaviour. A field that stores an approver is a useful input, but the team should still demonstrate the intended pending-request journey. Give unresolved behaviour a named owner so a request cannot simply disappear into an administrative gap.
Marking an employee as Left requires a relieving date. Discuss the wider departure workflow separately with the account and record owners. The organisation needs a clear understanding of which information remains available for authorised work and who manages the associated user account.
Keep the review proportionate to the information involved. Ask each role to identify what it needs to complete its task, then verify those views. A comprehensive employee form does not require every colleague to see every field. The access decision should follow the work and the organisation’s actual responsibilities.
Original supervisor-change request exercise
Prepare a fictional employee called Sample Colleague and an approved sample leave request in a separate test copy. Assign an initial supervisor and approver, then propose a change of responsibility while the request is pending. The exercise examines ownership through a handover without using real employee information.
First, have the employee create the sample request. Retain the selected dates, leave type, assigned approver and observed state. Ask the employee to explain how they know the request has reached the intended route. Record any uncertainty as a handover issue to resolve.
Next, apply the approved sample responsibility change. Inspect the existing request and create another sample request afterwards. Ask the current and proposed approvers to follow the intended journey using their designated roles. Record who can see and act on each request, keeping observed behaviour separate from the expected policy.
Then exercise a decision and a correction through the supported test route. Review the resulting employee view and retained request information with the HR owner. If the intended behaviour depends on a configuration change, record that change and repeat the affected part before accepting it.
Finally, assign ownership for maintaining employee details, approval assignments and account changes. Retain the version and configuration used in the exercise. Use the resulting record to compare software fit and unresolved implementation work, with HR and technical owners reviewing their respective responsibilities.
For broader planning, see business systems and software development. Get started with the employee workflow, approval map and access questions you need to resolve.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.