What a structured people-change request replaces
A people-change request process outside email and spreadsheets uses one structured request for every change to an employee's job, pay, location or reporting line, routes it to approvers based on the change type, and applies it to the record on the effective date. Everyone involved sees the same request and its status instead of searching their inboxes.
In many enterprises a transfer starts as an email from a manager, picks up approvals in reply-all threads, gets logged by HR in a tracker, and reaches payroll as a forwarded PDF. Nobody can say with confidence which version was approved, or whether IT was ever asked to move the person's system access.
Catalogue every change type before designing the form
List every kind of people change your organisation processes in a year. Typical entries are promotions, lateral moves between departments, moves between legal entities, off-cycle salary adjustments, allowance changes, reporting line changes, conversion from contract to permanent, and changes in working pattern.
For each type, note who usually initiates it, who must approve, which records it touches and which other teams need to act. A move between legal entities may involve new statutory registrations and a fresh contract; a reporting line change may only affect the org chart and approval routes. One generic form hides those differences and invites mistakes.
Expect the first draft of the catalogue to be incomplete. Circulate it to HR partners in each business unit and ask what is missing; local practices such as acting allowances or temporary secondments usually surface at this stage.
Fields every change request should capture
Whatever the change type, the request needs enough information for an approver to decide and for downstream teams to act without asking follow-up questions.
- Employee and current position, pulled from the record rather than typed
- Change type, chosen from the catalogue
- Proposed new values: role, grade, entity, department, manager, location or pay components as relevant
- Effective date, flagged as future-dated or back-dated
- Reason and supporting documents, such as a promotion memo or signed agreement
- Initiator, plus the approval route generated from the change type
- Downstream actions for payroll, IT access, facilities and any letter to issue
Routing approvals by change type and value
Build routes from your delegation of authority. A reporting line change inside one department might need only the two managers involved. An off-cycle salary change might need the line manager, the head of department, HR and finance, with the finance step triggered only above a level your policy sets.
Cross-unit transfers need both the releasing and the receiving manager. Leaving out the releasing side is a common source of disputes over handover and release dates. Keep the routing rules in a table HR can update when the delegation of authority changes, rather than in configuration that needs a support ticket to adjust.
Show approvers before-and-after values side by side, plus the reason. When current values are pulled from the record, approvers stop signing off a 'from' position that a manager typed from memory and got wrong.
Applying the change and alerting the teams that depend on it
Once approved, the change should wait in the record until its effective date and then apply in one step, so the org chart, approval routes and payroll inputs all switch together. Back-dated changes should alert payroll explicitly, because they may need recalculation.
Downstream teams should receive tasks, not just notifications. IT gets a task to adjust access for the new role, facilities gets one if the person moves site, and HR gets one to issue the letter. Each task has an owner and a status the initiator can see. Initiators should also hear when the change has applied, not only when it was approved, so they know the new title or manager is live.
Where a change affects statutory details, such as a move to a different employing entity, check the registration and reporting steps with EPF, SOCSO or your payroll adviser.
Retiring the old email route for good
Pick a cutover date and announce that after it HR will only process changes submitted through the new request. Allow a short grace period for changes already in flight. Managers adapt quickly when HR consistently declines emailed requests and replies with a link instead.
For the first month, review every submitted request for missing fields or wrong routing and adjust the form quickly. Early fixes show managers that their feedback changes the process.
BukuHR is Fasttrade's product for HR teams, covering people records, requests and approvals, onboarding and exit, and team visibility. Fasttrade can discuss whether your catalogue of change types and approval routes fits what BukuHR offers today.
Frequently asked questions
What counts as a people change that needs a formal request?
Any change to an employee's role, grade, pay, legal entity, department, location, reporting line or employment type should go through a formal request, because each one affects payroll, approvals, access or reporting. Minor corrections, such as a typo in a phone number, can usually be fixed directly and logged without an approval route.
How should back-dated people changes be handled?
Allow them, but mark them clearly. The request should record that the effective date is in the past, give a reason, and alert payroll so they can judge whether recalculation is needed. Frequent back-dating usually means managers are submitting changes late, which is worth raising with the business units responsible.
Who should be allowed to initiate a people-change request?
Usually the line manager, an HR business partner, or both, depending on the change type. Off-cycle salary changes are often raised by the manager and validated by HR, while entity transfers may start with HR. Define the initiators for each change type in your catalogue so the form only offers what each role is permitted to raise.
Next step
Explore BukuHR or tell Fasttrade what your team needs.
These articles explain enterprise process design. Product availability and detailed scope are confirmed in conversation.