The danger zone at the bottom of a member's editor offers Disable / Re-enable and Remove. Disabling maps to the server's disabled status; removal for an account holder cancels their pending invites for this tenant, clears their tenant metadata and removes their crew sync row. Retired crew members show as disabled rather than disappearing, because they still own finished work.
Also called: someone quit · deactivate user · remove access · fired an employee
- 1Disable/Re-enable writes status through the same update path as role changes (active → approved, invited → pending, disabled → disabled server-side).
- 2Remove asks Remove permanently? inline, then optimistically drops the row and calls DELETE /api/users/[id] for real accounts.
- 3Rows that only ever existed locally skip the network call — there is nothing on the server to delete.
The roster comment states the design: 'Inactive means retired from the crew, not de-provisioned — the tab already draws disabled as its own state, so reuse it rather than hiding someone who still owns finished work.' Hiding a retired person would orphan the history attached to them.
- There was no reversible way to cut access without erasing a person's record.
- Removals did not clean up pending invitations or tenant membership.
See it on your own jobs
Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.
or keep browsing features →