When someone leaves a team, removing access is not a single switch. Their mailbox, shared responsibilities and sign-in permissions may be handled through different controls, and what an administrator can change depends on their role, the workspace plan and how the account was provisioned. A careful departure process limits unnecessary access without losing business information the organisation needs. Work through the person’s access and responsibilities, follow your organisation’s records policy, then confirm each change using the controls available to you. Keep a record of what you checked and what remains unresolved.
The useful bits
- Inventory access and responsibilities before changing anything.
- Handle business records according to organisational policy.
- Verify each change in available controls; permissions vary by role and provisioning.
Start with a bounded access inventory
Before making changes, identify the person’s work account and what they are responsible for. Check the workspace information available to you, such as mailbox administration, and compare it with an authorised handover or team record. Look for responsibilities as well as account access: a departing person may be the point of contact for a domain, an external-sending policy, a task, a calendar item or a chat. Do not assume that every workspace exposes the same controls or that you can see every resource.
Keep the review limited to work-related access you are authorised to administer. Note which items need a new owner or a follow-up, rather than making broad changes just because they are available. If your role does not expose a needed control, ask an appropriately authorised administrator to handle it.
- Record the account and responsibilities to review.
- Mark each item as change, transfer, retain under policy, or confirm with another administrator.
Plan the change before removing access
Agree on the timing and sequence with the appropriate people in your organisation. If a responsibility must continue, arrange its handover before removing the departing person’s ability to perform it. For example, identify who will handle an ongoing customer conversation or a scheduled team task. Avoid assuming that assigning another person automatically transfers messages, calendar entries or ownership; confirm what the available workspace controls actually do.
Review how the account was provisioned and what role-based permissions apply. A mailbox, an alias and a workspace role are not necessarily interchangeable, and an alias is not automatically an independent mailbox or login. If the relationship involves a personal mailbox rather than an organisation-managed account, do not treat it as though you administer it.
Example handover note: Account: [departing-user@example.com] Responsibility: [team calendar item] Next owner: [new-owner@example.com] Action: [confirm assignment using available workspace controls] Open question: [whether related records must be retained under organisational policy]
Handle business records under policy
Decide what business records need to be retained, transferred or left in place by following your organisation’s policy. This may include work correspondence or information needed for an ongoing responsibility, but the correct handling depends on your organisation’s rules and the account’s available controls. Do not copy a mailbox wholesale or forward messages to a personal address as a shortcut. If the policy or the control’s effect is unclear, pause and ask the appropriate internal owner before acting.
When using a control intended to preserve or transfer information, check its scope. Confirm whether it affects only the selected record or changes access more broadly. Avoid opening or distributing personal content beyond what your authorised role and organisational policy allow.
- Identify the records in scope and the policy that governs them.
- Use only an authorised, available method; escalate unclear retention or transfer decisions.
Apply access changes in available controls
Once responsibilities and records are addressed, make the approved access changes through the workspace controls available to your role. Workspace administration can include domain and mailbox management, but specific permissions and actions depend on role, plan and provisioning state. Do not rely on an assumed menu name or a change you cannot see. If the expected control is absent, ask an authorised administrator to review the account rather than trying an unrelated workaround.
Consider the different access paths relevant to the person’s work. A mailbox change alone may not address a separately assigned task or calendar responsibility; conversely, changing a responsibility does not necessarily alter mailbox access. Make only the changes authorised by your organisation, and note any action that must wait for another administrator or a provisioning change.
For instance, if a departing colleague handled [project calendar item] and [work mailbox], verify the handover for the calendar item separately from the mailbox access change. Treat each as a distinct check unless the available control clearly shows otherwise.
Confirm the result, not just the request
After changes are made, return to the controls you used and check the account or responsibility’s current state, where that information is available to your role. Confirm that the intended person or team now owns ongoing work, and that the departing person’s access has changed as approved. A request submitted or a handover message sent is not, by itself, confirmation that a workspace change took effect.
If the result is not visible, the displayed state conflicts with the plan, or a control reports that the action is unavailable, do not claim the departure is complete. Record what you can verify and escalate the remaining item to an authorised administrator. Keep confirmation limited to the workspace state you can actually observe; do not imply that it proves access is removed from every external service or device.
- Check the resulting state in the available workspace controls.
- Record completed changes, pending items and who will follow up.
- Confirm retained or transferred records were handled under organisational policy.
Close the loop with a concise checklist
A short, specific record makes the process easier to review later. Note the account reviewed, the responsibilities considered, the policy-based records decision and the changes you could confirm. Avoid storing passwords or one-time codes in the record, and do not share credentials as a substitute for transferring responsibility. If the account’s role or provisioning limits what you can verify, say so plainly and route the item to someone authorised.
Use the checklist below as a completion aid, not as a claim that every workspace has identical settings. The departure is ready to close when the approved actions are confirmed or clearly assigned for follow-up—not merely when someone has asked for access to be removed.
- Account and role reviewed within your authority.
- Work responsibilities handed over or assigned for follow-up.
- Business records handled under organisational policy.
- Available access changes confirmed; unavailable or uncertain items escalated.
About this guide
Prepared with AI assistance for the BITTU Mail editorial library. Check important details against your original messages and current account settings. Product access depends on your role, plan and provisioning state. Provider interfaces and requirements can change.
View current plans · Security information · Suggest a correction