Offboard a member

Removing someone is one click and it does five things at once. This page says what those are, so you can tell a customer exactly when that person's access ended.

What removal does

Open Settings then Members, find the person, and remove them. One transaction then:

Access ends on their next request. There is no window to wait out.

The action filter in Audit Log offers member.deprovisioned. It does not offer member.removed, member.invite_revoked, role.assigned or role.unassigned, so find those rows by filtering on the actor and the date, or export the log and search the file. A role.assigned or role.unassigned row shows under the Other family.

Two removals are refused outright. You cannot remove yourself, and the last owner cannot be removed at all. Make someone else an owner first.

What removal does not do

Machine identities keep working. An identity a person created belongs to the workspace rather than to them. That is deliberate: a pipeline should not break because somebody changed jobs. If your policy says otherwise, find what they issued before you remove them.

Filter the audit log by that person as the actor and look for identity.create and credential.issue. Revoke each one from Machine Identities then All Identities, which needs machine:revoke. Revoking one credential leaves the identity able to hold a new one. Revoking the identity stops everything it holds at once and cannot be undone.

Pending invitations survive. An invitation they sent is still live for seven days. Revoke it on the same page, which writes member.invite_revoked.

Values they saw stay seen. Removing someone does not rotate anything. If they read production credentials, treat it as a credential leaked and rotate.

When the directory does it for you

Your identity provider adds and removes people for you. Setting active to false in the directory runs the same code the remove button runs, with scim recorded as the cause. A directory delete takes the same path.

The membership row is marked rather than deleted, because a directory sets active: false and still expects the row to answer a read. A deprovisioned row that kept billing would be a refund conversation, which is why the seat count reads only the active ones.

Turning active back on restores the seat and the membership. It does not restore the sessions, and it should not.

Narrowing access instead of ending it

Somebody moving off one project does not need removing. Grants live in two places:

• The workspace-wide role, on Settings then Members. Changing it needs member:role_assign, and you cannot grant more than you hold yourself.
• Grants on one project or one environment, on Projects then the project then Access. Adding or removing one writes role.assigned or role.unassigned.

That split is what makes "read staging, nothing in production" expressible without a custom role.

What the record keeps

Everything. The log is append-only at the database level, so nothing about that person's history can be edited or deleted, and the marked membership row keeps their name attached to it. When a customer asks who could reach production and when that access ended, the answer is one filter on the audit log.

Do it in order

1. Filter the audit log by that person as the actor. Note what they touched in the last 90 days.
2. Look for identity.create and credential.issue rows with their name on them.
3. Revoke those identities or credentials in Machine Identities, if your policy calls for it.
4. Revoke any invitation they sent, on Settings then Members.
5. Remove them on that page. If they are an owner, make someone else an owner first.
6. Filter the log by yourself as the actor and today's date, and read back member.deprovisioned and member.removed.
7. Rotate anything they could read in production, oldest and most sensitive first.

Rotate a value