Removing someone who has left
Taking away access, what happens to their conversations, and the order to do it in.
Do this on their last day rather than eventually. A live login belonging to somebody who no longer works for you is the most ordinary security problem there is.
Before you remove them
If they are an owner, appoint another one first. You cannot remove the last owner, and discovering that at the point you are trying to is a bad time.
Reassign their open conversations. Removing somebody does not close or reassign what they were working on, and a chat assigned to a person who no longer exists is a chat nobody is looking at. Filter the inbox by them, and hand the live ones over.
Removing them
Settings → Team, on their row. Their access ends immediately and the seat comes back to your plan.
What stays
Their conversations. Everything they said stays exactly where it is, with their name on it. A support history with holes in it is worth much less, and it would be a strange thing to rewrite because somebody changed job.
The transparency log. What they did in the workspace stays recorded, which is rather the point of having one.
What to do about shared logins
If the person leaving was sharing an account with somebody else, remove it and give the remaining person their own. It is the moment to fix it, because a shared login means the transparency log cannot tell you who did anything, and you have no way to remove one person’s access without removing both.
If they had an API key
An API key belongs to the workspace rather than to a person, so removing them does not revoke it. If they created keys, review them and delete any that were really theirs.
The same goes for webhooks pointing at something only they ran.
Last updated 22 September 2026.