What Happens to a Removed Workspace Member's Invoices

Removing a teammate from a workspace is a common enough moment in an agency's life — a contractor's engagement ends, someone changes roles, an account needs tightening up — and the natural worry is what happens to everything that person touched while they had access. The answer, verified against exactly what the removal endpoint does, is reassuring: almost nothing changes except their own ability to get in.

What Removal Actually Deletes

Removing a member from a workspace runs exactly one database operation: it deletes the row in the workspace-membership table linking that user's account to that workspace. That's the entire mechanism. It doesn't touch the invoices table, the payments table, the audit-events table, or any other record the person's work might have created. The moment that membership row is gone, their account simply has no path into the workspace anymore — every subsequent request they make against that workspace's data fails the authorization check that runs before any invoice, client, or report query even executes.

Why This Works: Everything Is Scoped to the Workspace, Not the Person

The reason removal can be this surgical is that virtually every query in the product — fetching invoices, listing payments, pulling reports — filters by workspace ID, not by which specific user created or last touched a given record. An invoice belongs to a workspace; the user ID stored on it is metadata about who happened to create it, not a permission boundary controlling who can see it. So when a member's access to the workspace goes away, every invoice, payment, client record, and report that already belonged to the workspace stays exactly where it was and exactly as visible to the members who remain, because none of those records were ever gated on that specific person's continued membership in the first place.

The Audit Trail Keeps Their Name Attached

Every action a removed member took while they had access — creating an invoice, recording a payment, sending a reminder — left an audit-trail entry referencing their user ID at the time. Removing them from the workspace doesn't rewrite or anonymize that history; the audit trail still shows exactly who did what and when, by their account, even after that account no longer has any way to access the workspace. This is important for anyone relying on the audit trail as an accountability record: losing access doesn't retroactively obscure a person's past actions.

The One Thing You Can't Do: Remove the Owner

There's a single hard restriction on this whole mechanism: the workspace owner can't be removed, and their role can't be changed, through this endpoint. Both the removal action and the separate role-change action explicitly check whether the target user is the workspace's owner and reject the request outright if so. This isn't a permissions nuance that varies by who's doing the removing — it's an unconditional block, which exists because a workspace without an owner would have no clear account of record for billing and ultimate authority, and there's currently no separate "transfer ownership" step that could leave that gap open even momentarily.

What Does Change: New Access, Not Old Data

Where removal does have an immediate, visible effect is entirely forward-looking. The removed person can no longer sign in and select that workspace, can no longer appear in the workspace's member list, and can no longer be assigned as the recipient of anything workspace-scoped going forward. If they were re-invited later, they'd come back in with whatever role they're assigned at that point — there's no memory of their previous role carried across a removal, since the row that stored it was deleted, not archived.

Why This Design Makes Sense for Agencies

For an agency running clients through a shared workspace with a rotating set of contractors and team members, this is close to the only design that holds up. If removing someone also touched the invoices they'd created — deleting them, hiding them, reassigning them — every offboarding would become an exercise in first auditing everything that person had touched and deciding what to do with each item before you could safely remove them. Because access and data ownership are cleanly separated, offboarding a team member is a single action with no cleanup required afterward: their access ends immediately, and the workspace's actual business records — invoices sent, payments received, the history of who did what — simply carry on unaffected by their departure.