Skip to main content
A transfer moves an employee who is already on the books into a new department (org unit), position, manager, work location, or employment type — without re-hiring them. It always operates on an existing active employment, ends the current contract, and opens a fresh one carrying the new details forward. Because a transfer is a no-pay-change event, the employee’s salary structure assignment is carried across automatically so payroll keeps running uninterrupted. This page covers the “Transfer” action on the employee profile, the fields you fill in, the effective date, and how a completed transfer shows up in the employee’s Work History. You’ll find this at: /hr/employees/:id (the Transfer button in the employee profile header)
📷 Screenshot: Employee profile header showing the Transfer button next to Edit — to be added.
Hitaji 360 is multi-business. A transfer belongs to the same business as the employee’s source contract, and it cannot move someone across businesses (see Cross-business below). Make sure the correct business is selected in the switcher before you start.

​
Two transfer paths (important)

Behind the scenes the system has two transfer mechanisms, and it helps to know which one you are using:
  1. The Transfer button on the employee profile (what most people use). This calls the original, immediate transfer path. It ends the current employment and creates a new active one straight away — there is no scheduling and no approval step. The change takes effect on the date you choose.
  2. The Employee Transfer doctype (/api/hr/employee-transfers). This is a newer, fuller transfer record that supports a draft → submit → apply lifecycle, scheduling for a future effective date, a status trail, and per-field before/after history. It is currently API-only.
⚠️ Current state: These two paths are not yet joined up. The Transfer button uses path 1 (immediate). The richer Employee Transfer doctype (path 2, which feeds the Work History timeline) is only reachable via the API today — there is no screen for drafting, scheduling, or approving a transfer. As a result, a transfer done from the button applies immediately and does not currently appear as a “Transferred” event in Work History (the timeline reads from the doctype records, which the button doesn’t write). The profile page also checks for a pending Employee Transfer approval, but the button’s path never raises one, so that approval state will not appear for button-driven transfers. Both behaviours are flagged for the team.
The rest of this page describes the Transfer button flow first, then the Employee Transfer doctype for completeness.

​
Transferring an employee (the Transfer button)

The Transfer button appears in the employee profile header only when:
  • you hold the hr:write permission, and
  • the employee’s status is ACTIVE, and
  • the employee has an active employment record.
If any of those are false, the button is hidden — there is nothing to transfer from. Click Transfer to open the Transfer Employee dialog.
📷 Screenshot: Transfer Employee dialog with the New Org Unit, New Position, New Manager and Effective Date fields — to be added.

​
Fields

The dialog reminds you up front that at least one of org unit, position, or manager must change to make a meaningful transfer.

​
What happens on submit

When you confirm, the system:
  1. Ends the employee’s current active employment (end-dated the day before the effective date).
  2. Creates a new active employment carrying the new org unit / position / manager forward, and copying over the unchanged details (employment type, country, pay currency, payroll calendar).
  3. Seeds leave entitlement for the new employment.
The change is immediate — you’ll see a success toast. There is no approval queue on this path today.
The dialog contains a “submitted for approval” message that only shows if the API reports an approval is required. The current immediate path never reports this, so in practice you will always see “Employee transferred successfully”.

​
The Employee Transfer doctype (API-only)

The newer Employee Transfer record (/api/hr/employee-transfers) is the enterprise-grade version of a transfer. It is not yet surfaced in the web app, but it is worth understanding because it drives the Work History timeline and supports scheduling. A transfer record is created as a Draft, then submitted. On submit:
  • if the effective date is today or earlier, it is applied immediately;
  • if the effective date is in the future, it is marked Scheduled and a daily job (runs at 04:00 UTC) applies it on the day it falls due.
When it applies, it ends the source contract, creates the successor contract, carries the active salary structure assignment forward (so payroll doesn’t silently skip the employee), and writes a before/after history row per changed field.

​
Fields (Employee Transfer doctype)

Only the fields that actually change are recorded as before/after pairs — a department-only transfer leaves position, manager, etc. untouched.

​
Status values (Employee Transfer doctype)

​
Cancelling

A transfer can be cancelled only before it applies (while it is Draft or Scheduled). Once it is Applied the new contract already exists, so you must issue a fresh transfer in the opposite direction rather than cancelling.

​
Cross-business transfers

Transfers stay within one business. If you point a transfer at an org unit that belongs to a different business, the system stops you with a clear error and asks you to create a new contract in the target business manually instead. Full cross-business transfer (ending the contract in business A and opening one in business B) is not yet supported.

​
How a transfer shows up in Work History

The employee profile’s Work History timeline builds its events from applied Employee Transfer doctype records (plus contracts and promotions). A transfer appears as a “Transferred” entry on the effective date, with an expandable Details section listing each changed field as from → to (for example, orgUnitId: Sales → Marketing).
⚠️ Current state: Because the Transfer button uses the older immediate path (which does not write an Employee Transfer doctype record), button-driven transfers will not currently produce a “Transferred” timeline entry. Only transfers created through the Employee Transfer doctype API appear in Work History today. Flagged for the team.

​
Permissions