Skip to content

Offboarding and knowledge handover

When an engineer leaves, context usually leaves with them: why this queue was chosen, where the pitfalls are, what was agreed with a client. In an MMW organization that context stays with the company.

By the end of this page you will know:

  1. how to offboard someone and who receives their knowledge;
  2. what happens to their keys and access;
  3. how the recipient opens handed-over records to the team.

Example: Ben from the Backend unit is leaving Northwind. Anna, head of Backend, offboards him and names herself as the recipient.

WhoWhom
AdminAnyone except themselves
HeadPeople inside the subtree they head, except admins

The last admin cannot be offboarded. The recipient can be any other active member of the organization.

  1. Anna opens the People tab, finds Ben and clicks “Offboard”.

  2. In the Offboarding dialog she chooses whom to hand knowledge to and reads the warning: “Their keys are revoked at once and access to the organization closes. The recipient sees their records, drafts included.”

  3. She clicks “Start offboarding”. At that moment:

    • Ben’s status becomes “offboarding”, and he can no longer read or write anything in the organization — neither in the account nor through an agent;
    • all of his organization keys are revoked;
    • the recipient starts seeing all of Ben’s records.

    The account shows a summary: “2 keys revoked · 148 records handed over · 3 uploaded sessions”.

  4. When the handover is done, Anna clicks “Complete offboarding”. The status becomes “left” and the seat is freed.

Before offboarding After "Start offboarding"
────────────────── ─────────────────────────
Ben: keys active Ben: keys revoked, no access
Ben's drafts: only Ben sees them Ben's drafts: the recipient (Anna) sees them
"Unit" records: the unit sees them "Unit" records: the unit sees them, as before
Anna: cannot see Ben's drafts Anna: sees all of Ben's records

The recipient sees all of the leaver’s records — any visibility, including “author only” drafts:

  • in the account — the Handed-over knowledge tab: from whom, status (“offboarding” or “left”), how many records were handed over, how many uploaded sessions, and an “Open records” button (shows up to the 500 most recent records);
  • through their own agent — these records show up in the recipient’s search results just like their own.

Ask the agent:

Search MMW for what Ben found out about replacing the queue.

Anna’s agent also finds Ben’s draft “Candidate to replace the queue: NATS, still comparing”, which nobody but Ben could see before.

The recipient decides what others need. In Handed-over knowledge → “Open records”, every record has a “Visible to” selector: only me, the unit, the project, the whole organization.

Anna opens Ben’s queue comparison to the unit and keeps his personal note as “only me”. Every such change is written to the audit log.

Everything that happens to handed-over knowledge stays in the organization audit log:

EventWhat is recorded
Offboarding startedWho, whom, the recipient, keys revoked, records by visibility, sessions
Offboarding completedWho and whom
Handed-over knowledge readWho read, whose knowledge, how many records, and where: account or agent
Visibility of a handed-over record changedWho, record ID, new visibility

Memory content never goes into the log.

  • Managers never see drafts of current employees. Access to drafts appears only for the recipient and only once offboarding starts.
  • Knowledge is not deleted. A leaver’s records stay in the organization; a person who left takes no seat, and their knowledge is kept free of charge.
  • The seat is taken until completion. Someone in “offboarding” status still counts as a seat — remember to click “Complete offboarding”.
  • You cannot offboard yourself, and if you pick the leaver as recipient the account asks you to choose another active person.