Transfers and Offboarding
Move an employee to a new department, manager, title or location with the access change computed first, and offboard a leaver with per-system proof that access is gone.
When somebody moves or leaves, the paperwork is the easy part. The question that matters is what happens to their access. These two screens answer it: a transfer computes the access change before you commit it, and an offboarding shows you each connected system’s own answer rather than a checkbox somebody ticked.
When you would use this
- Somebody is promoted, changes department, gets a new manager or moves office.
- Somebody is leaving and you need their accounts gone, with evidence.
- An employee was deactivated months ago and nobody is sure their accounts were removed.
- An auditor asks you to prove that a named leaver no longer has access.
Transfers
To open it: Sidebar → HR → People → Transfers.
Transfers lists every move Muin has recorded, and exactly what access each one adds and takes away. Each row carries Who is moving, From, Effective, Access changes and Status.
| Status | Means |
|---|---|
| Draft | Started, nothing scheduled |
| Scheduled | Has an effective date; nothing has moved yet |
| Applied | The position and the access have both changed |
| Cancelled | Abandoned; nothing changed |
Record a transfer
- Go to HR → People → Transfers.
- Press Start a transfer.
- Pick the employee who is moving.
- Choose the new position: another Department, a new Manager, a new Title, a new Location, or any combination. Fields you leave alone stay Unchanged.
- Set the effective date.
- Press See the access changes. The preview lists exactly what would be granted and what revoked. It writes nothing - leaving the preview changes no record.
- Save. The transfer is created as Scheduled. The position is unchanged and no access moves while it is scheduled.
Apply it
Open the transfer and press Apply the transfer. Three things happen in one transaction: access moves, the new position is written, and the applied time is stamped. If any part is refused, none of it lands.
Applying before the effective date asks you to confirm with Apply early anyway, and Keep it scheduled backs out. Cancel the transfer abandons it; Leave it scheduled backs out of that.
The detail page also shows Where this person’s access stands now, so you are comparing the delta against reality rather than against memory.
Why the access change is a delta
The access change is a delta, not a reset. Access the new position also needs is kept rather than revoked and re-granted, so the person is never briefly locked out of something they are entitled to. If a connected system is added it says so; if nothing changes it says No connected system is added. and No connected system is taken away.
A transfer whose access delta is empty is worth a second look. It means a position moved and no access consequence was computed, which is usually a gap rather than a correct answer.
Changing a position on the employee record itself creates a scheduled transfer rather than editing in place. That is deliberate: a position change with no access review is the exact gap this screen closes.
Offboarding
To open it: Sidebar → HR → People → Offboarding.
Offboarding shows everyone who has left or been deactivated, and whether Muin has actually removed their access from each connected system. The filter has three scopes:
- Left the organization - terminated employees.
- Deactivated - an employee switched off without a termination. This is exactly the case where access was never explicitly revoked, which is why the scope exists.
- Still employed - so you can find somebody and start their offboarding from here.
Offboard somebody
- Go to HR → People → Offboarding.
- Switch the filter to Still employed.
- Find the person and press Start offboarding on their row.
- Set the last day and confirm. Muin deactivates their login, revokes their tokens, and asks every connected system to remove their account.
- Open their row to watch each system answer.
Identity deactivation and employment termination happen together. Deprovisioning through an identity provider alone suspends the login and leaves the employment record active, so the person keeps counting in headcount and team hours.
The per-system record
The detail page lists Accounts Muin asked to be removed, one row per connected system with that system’s own outcome. The page header reads Access fully revoked or Access not fully revoked, and each row is Settled or Outstanding.
| Row outcome | What it means and what to do |
|---|---|
| Revoked | The system confirmed the account is gone. Nothing to do. |
| Failed | The provider refused, and the row carries the provider’s own reason. Retry it; the retry reports what actually happened rather than just succeeding. |
| Not supported | That system has no user-provisioning API at all. Muin cannot revoke it and says so rather than pretending. Somebody has to remove the account by hand. |
There is no revocation task to tick. A task an admin can close by hand reads as “access revoked” whether or not it was, so the per-system row cannot be cleared that way. Offboarding is not finished while a single revoke is outstanding.
Devices are on the same page. N devices still assigned is part of the answer - an offboarding that does not say which laptop is outstanding has not finished. The page also says whether the person is Still linked to a login or has No login linked.
What it affects
- An applied transfer writes a position-history entry on the employee record and changes their place in the org chart and in Headcount Impact.
- A new manager on an applied transfer changes whose My Team the person appears on and who approves their time off.
- Offboarding sets the employment record to terminated, so the person drops out of active headcount and out of team hours.
- Records of the person’s work stay where they are. Offboarding removes access, not history.
- An outstanding revoke keeps the person on the Offboarding list, which is the backlog you should be working.
When it goes wrong
“We could not load transfers.” The list read failed and nothing changed. Retry.
“We could not load this transfer.” Same for one record. The transfer itself is unaffected.
“That did not go through, and nothing was changed. Try again.” An apply or cancel was refused mid-flight. Because the apply is one transaction, a refusal leaves the transfer exactly as it was - no half-moved position, no half-moved access.
The preview shows no access change. Either the new position genuinely needs the same access, or no access is mapped to the position at all. Check the second possibility before applying.
“We could not load this list” on Offboarding. The page says what to do: nothing has changed, and until it loads you should treat everyone’s access as unknown rather than removed.
“We could not load this person’s record.” Open them again from the Offboarding list. The detail page needs an employee - reaching it without one says This page needs an employee. Open somebody from the offboarding list.
A row sits on Failed after several retries. Read the provider’s reason on the row. The usual causes are an expired connector authorization or an account that was already removed on the provider’s side. Re-authorize the connector, then retry.
A row reads Not supported and you cannot clear it. You cannot, and that is correct. Remove the account in that system yourself and record that you did; Muin will not claim a revoke it did not perform.
Next step
- HR overview and headcount - where the headcount change lands.
- Profile change approvals - the other place an employee record change is reviewed before it takes effect.
- Departments and the org chart - the structure a transfer moves somebody within.