Transfers and reporting-manager changes without breaking history

A transfer is a dated assignment, not a silent overwrite

Treat transfers and reporting-manager changes as dated assignment events: who the person reported to, in which department, from when until when. Overwriting the current manager without keeping history makes last quarter’s approvals and “who owned this team” impossible to reconstruct. Internal mobility is a records event. It is not a performance review, and it is not Dayzen PMS — which is a Project Management System, not performance management.

The live org view should show the current line. The profile should still be able to answer who the manager was last month. Those two needs conflict only if you store a single unmanaged text field and type over it. They do not conflict if assignment history is part of the employee record.

This page is about the shape of that event. The employee management process is how you keep people records reliable overall. After the fields change, keep the tree honest using org chart updates after transfers. Later employment events, including further moves and exit, sit on the same person in Dayzen employee lifecycle — without turning this article into a Full & Final walkthrough.

What “internal mobility as a records event” means

Someone already has an employee identity. They are not a new joiner. They are changing home, role label, manager, location, or some combination. The employment trail continues. Payroll, attendance, leave, and assets still point at the same person. What changes is the assignment: the structured facts other modules read for “where does this person sit” and “who approves their requests.”

If you create a second employee row because a transfer felt like a “new start,” you have manufactured a duplicate. If you only update an email signature, the system of record never learned. The useful middle path is one person, new assignment, dated.

Dayzen employee management holds profiles with personal and job information, history, assigned assets, and documents, plus departments, designations, ranks, and an interactive org tree. Employee records are the foundation for recruitment handoff, onboarding activation, and payroll. A transfer should reuse that foundation, not fork it.

What history should be able to answer

A dated assignment history should let HR answer, without searching mail:

• Who was the reporting manager on a given working day?
• Which department (and designation, if it changed) applied in that period?
• When did the current assignment start?
• Was there an acting manager between two permanent ones?

Those answers matter when someone asks why a leave request went to a name that is no longer on the team, or why a department headcount snapshot from last quarter does not match today’s tree. They are operational reconstruction, not appraisal commentary.

Do not overwrite the only copy of the old manager

The failure mode is familiar. HR opens the profile, replaces Manager A with Manager B, saves, and the previous value is gone. The directory looks correct this week. Three months later, finance or a new HR lead cannot tell who signed off attendance exceptions in the earlier period. The team argues from memory.

Overwrite is especially damaging when the old manager has also moved or exited. You lose both the historical line and an easy way to confirm the sequence of events. Keep the current fields for operations, and keep prior rows (or equivalent history on the profile) for the trail.

Current manager is for today’s queues. Assignment history is for yesterday’s questions.

Effective dates close the gap between people

Name a start date for the new assignment. If the previous assignment has no end date, you will double-count or leave a hole. Same-day transfers should still have a clear “from this date” so the org tree and approval routing do not hover in two states. If a move is planned for the first of next month, do not make it look current in operational queues early unless that is an explicit acting arrangement.

Acting managers are still dated assignments. “Until we hire” is a period with a start. Give it an owner on the record so leave does not sit in a dead inbox.

A process for recording the move

Use a repeatable path so transfers do not depend on who happened to be in the office.

1. Confirm it is the same person. Search by employee ID and work email. Do not add a new employee because the designation changed.
2. Classify the change. Manager-only, department-only, designation-only, location, or a combined transfer. Classification stops people from relabelling every move as a promotion.
3. Capture old and new values before you save: department, designation, rank if used, reporting manager, effective date, and who authorised the record change.
4. Write the new current assignment without deleting the previous period. History stays on the profile.
5. Verify the live tree and both managers’ team lists as described in the org-chart-after-transfers sibling.
6. Attach evidence if you keep it — a transfer letter or acknowledgement — on the same employee file. The file supports the fields; it is not the only place the new manager exists.
7. Leave payroll and time on the same identity. They should not receive a “new joiner” event unless the person actually left and returned. Rehire is a status story, not a transfer story.

Who is allowed to change the line

Reporting line and department are system-of-record fields. Employees should not silently rewrite them. Managers may request a team change; a named HR or data owner should apply it with a trail. If two managers can edit each other’s reporting lines without an owner, the tree becomes a negotiation, not a record. That RACI belongs with profile-update practice; here the point is narrower: a transfer is an authorised field event, not a chat agreement.

How past approvals should be read

Leave and attendance approvals already completed belonged to the manager at the time, not to whoever is on the profile today. When you reconstruct a dispute, use assignment history plus the transaction’s timestamp. Do not “fix” history by changing today’s manager to match an old screenshot. That corrupts the current tree to comfort a past argument.

Open requests that straddle a transfer need an operating rule: they follow the manager as of the effective date, or they stay with the old manager until closed. Pick one rule and apply it. The records event makes the rule possible; it does not replace a one-line team policy.

None of this is a review cycle. Do not attach ratings, goals, or “readiness” scores to the transfer record in this process. If your organisation runs performance conversations, they are a separate practice and a separate product conversation. They are not how Dayzen names PMS, and they are not required to move a reporting line.

Transfers versus other lifecycle events

Onboarding activates a joiner on an employee record. A transfer assumes that record already exists and is active. Exit changes status and starts settlement work owned elsewhere. Confusing those three is how you get duplicate joiners, or how you “transfer” someone who has actually resigned without recording an exit.

Employee lifecycle in Dayzen is the commercial home for later events after join — including moves and, eventually, Full & Final as a process you must not duplicate here. Use lifecycle for the event family. Use this article for the records shape of a move: dated manager and department, history preserved, same person.

Assets assigned to the employee remain on the same profile unless you have a separate handover because the kit belongs to a site or a role. Do not create a second people row to “start clean” for a laptop. If something must be returned because of the move, that is an asset event hanging off the same identity.

What not to clone

• A new employee ID because the person changed departments.
• A new profile because the designation is longer than the old field.
• A copy of the personnel file under a nickname that hiring used months ago.
• A parallel manager name in a spreadsheet that payroll never sees.

Clone behaviour is how identity drifts. The transfer event should be boring: same ID, new assignment row, current fields updated, tree checked.

A compact picture of the records shape

Need	Store as	Do not
Who they report to now	Current manager on the employee record	Leave an exited manager attached
Where they sit now	Current department (and designation if the role label changed)	Encode the team only in a job-title string
Who they reported to before	Dated assignment history on the same profile	Overwrite the only manager field
When the move counts	Effective date	Rely on the date the email was sent
Proof	Optional letter or acknowledgement on the employee file	Hide the new manager only inside a PDF

If a column in that table is missing, you will feel it the first time someone asks a historical question — or the first time the org tree and a manager’s queue disagree.

How Dayzen fits without turning this into a product tour

Use employee management as the directory and structure layer: searchable profiles, departments, designations, ranks, interactive org tree, documents and history on the person. Use employee lifecycle as the place later events belong after join. Keep payroll and time pointed at the same employee identity through the move. If you need the visual check after saving, follow the org-chart how-to rather than rebuilding boxes in a slide.

When the assignment is dated and the current fields match the tree, internal mobility is visible to HR and managers without inventing a second person. That is the whole job of this process: record the move, keep the past, and refuse to treat a reporting-line change as a score.