When a technician leaves

There are three steps, from the menu next to the member on the Members page. For: Admins and Owners.

Disable only blocks access. They can’t sign in to your organisation and their sessions end. Nothing of theirs is lost, and Enable gives everything back.
Offboard hands over what they could read, for when they’re leaving for good. It can’t be undone.
Remove from organisation takes them off your lists, once they’re offboarded.

Disable the member

Disabling ends their sessions: they can no longer sign in to your organisation or reveal anything in it. They don’t take a seat, can’t be picked and get no notifications.

Their keys, devices and the requests and shares sealed to them are kept. If you enable them again, they can open everything they could before. API keys they created keep working.

An open request only they can open is paused: the person it was sent to sees “This request is paused. Contact IT.” until you enable them again. The Disable confirmation lists those requests, and the Requests page marks them.

Your identity provider (over SCIM) or directory sync disables people the same way when they’re suspended, deactivated or unassigned there, and enables them again when they’re back. It never enables someone an Admin disabled or offboarded. The Members page says who disabled them. If you enable someone your directory still has suspended, its next sync may disable them again.

If they sign in to SafeHanded again and belong to no other organisation, they see “Your access to has been turned off. Ask an admin if you think this is a mistake.” They can still choose Create a separate organisation, which shares nothing with yours, unless their email address is on one of your verified domains and you’ve made people on your domains join you.

Offboard them

When they’ve left for good, choose Offboard…, then confirm with your passkey. You see what will happen first:

open requests they could read need a new link, and credentials only they could open become unreadable (unless your organisation recovery key can open them);
the saved keys of shares they sent are deleted, so they can’t reopen those shares;
if they belong to no other organisation, their keys and devices are turned off;
the API keys and SCIM tokens they created are revoked, unless you tick Keep for one (for example a ticketing integration that must keep running), and webhooks registered with a revoked key stop.

Webhooks and integrations set up in the app aren’t tied to a person: review them when someone leaves.

What’s waiting shows the same list before you decide. Nobody is offboarded automatically. If a member stays disabled for 30 days with things still waiting on them, Owners get one email.

Handle their outstanding requests

After you offboard them, a departing technician’s requests fall into three groups, because credentials are encrypted to people. The offboarding page lists each with a one-click action:

Re-issue live links — open requests whose links still encrypt to them. The new link must be issued from the requester’s browser, so the page lets you ask the requesters to re-issue (they get an email and an in-app alert), rather than the server doing it silently.
Still readable — submitted credentials that other recipients, or an Owner with the organisation recovery key, can still open. No action is needed.
Unrecoverable — submitted credentials they were the only one able to decrypt, with no organisation recovery key sealed to them. These can’t be read; the page lets you destroy them (you confirm first) and ask the users for the details afresh.

Remove them from the organisation

Once they’re offboarded and the steps above are done, you can take them off your organisation: open the menu next to them on the Members page and choose Remove from organisation.

Their history stays. The requests they sent, the shares they made, the requests sealed to them and the audit log keep showing who did what, as “Name (removed)”. The history belongs to your organisation.
Their account stays. Only their membership here ends; they may belong to other organisations.
They’re gone from your lists. They can’t sign in to your organisation, don’t take a seat, can’t be picked for anything and get no notifications. To see them, choose Removed in the status filter.
Their photo, extension and notification settings are deleted. Their name is kept only as long as your retention period keeps records that mention them.

The menu says why, and links to the fix, if they can’t be removed yet:

they aren’t offboarded yet;
an open request still lists them (finish the steps above first);
API keys or SCIM tokens they created still work (revoke them first);
their start-over is still in progress.

You can’t remove an Owner or yourself. If your identity provider manages them, unassign them there too, or it may add them back.

Bringing someone back

Invite the same email address again. They come back on the same membership, so their old requests and shares are theirs again once they accept.

Automatic joining doesn’t bring a removed person back, even if their address is on your domain. Invite them instead.

When a member starts over

A member who lost every way into their vault and started over hasn’t left, but their old key is gone. What was lost next to them on the Members page opens the same page, limited to what their old key could open, with the same three groups and actions. Open links move to their new key once you approve it. If you are the only Owner or Admin and you started over yourself, the link is next to your own name.

Revoking a lost device (without leaving)

If a technician just lost a laptop, revoke that device from their device list rather than disabling the person — see Losing or replacing a device.