How Workspace Invitations Actually Work

Inviting someone to your workspace has one requirement that surprises a lot of first-time team owners: the person you're inviting has to already have an account on the platform before you can add them. There's no email-based invite link that lets someone sign up as a side effect of accepting an invitation — the invite flow is a lookup against existing users, not a registration trigger. Understanding why the flow works this way, and exactly what happens at each step, makes onboarding a new team member noticeably smoother.

The Invite Flow, Step by Step

When you invite someone, you submit their email address along with the role you want to assign them. The system's first move is to look up a user record matching that exact email address. If no matching account exists, the invite fails immediately with a message telling you the person needs to sign up first — there's no pending-invite state created, no email queued to go out, nothing stored waiting for them to claim later. You have to actually tell them, outside the product, to go create an account, and then try inviting them again once they have.

If a matching account does exist, the system then checks whether that user is already a member of your workspace. If they are, the invite fails again — you can't invite someone twice, and there's no "resend invite" concept because there was never a pending invite object to begin with. If they're not already a member, a new membership row is created immediately, linking that user to your workspace with the role you specified, and that's the whole flow — there's no acceptance step on the invitee's end. The moment you successfully invite an existing user, they're a member, full stop, and they'll see the workspace the next time they load the dashboard.

Why There's No Registration-Triggering Invite Link

Many tools let you invite someone by email even if they've never signed up, generating a token-based link that creates their account for them the moment they click it. This product doesn't do that, and the reason is really about keeping the account and workspace-membership models cleanly separated: a user account here is independent of any workspace, and every account, however it was created, goes through the same signup path with the same verification steps. Building a second, invite-triggered account-creation path would mean maintaining two different ways a user record can come into existence, with two different sets of edge cases around verification and initial state — one created explicitly by someone typing their own email and password into a signup form, and one created implicitly as a side effect of someone else clicking a link on their behalf. Requiring the invitee to sign up through the normal flow first keeps there being exactly one path into having an account, and the invite step becomes strictly about workspace membership, not identity creation.

Roles Are Assigned at Invite Time

The role you choose when inviting — whatever roles your workspace supports, such as admin, member, or accountant-style read-focused roles — is set the moment the membership is created, not left as a default that needs a follow-up step to configure. There's no intermediate "pending, role not yet decided" state; the person is added directly with full context on what they're allowed to do from their very first login.

Changing a Role After the Fact

Roles aren't fixed at invite time forever — a separate action lets you update an existing member's role later, targeted at a specific member by their user ID within your workspace. The one hard restriction here is that the workspace owner's role can never be changed through this mechanism, by anyone, including the owner themselves — an explicit check blocks any attempt to modify the owner's role, which exists to prevent a workspace from accidentally ending up ownerless or with its owner demoted to a role that can't manage the workspace they created. If ownership genuinely needs to transfer to someone else, that's a distinct operation from a routine role change, and isn't something this endpoint is designed to do.

Removing a Member

Removing someone from a workspace deletes their membership row outright — it's immediate and doesn't go through any kind of pending or grace-period state. The moment a member is removed, they lose access to that workspace's invoices, clients, and data on their next request; there's no lingering read-only access or delayed cutoff. Their user account itself is entirely unaffected — removing them from one workspace has no bearing on any other workspace they belong to, or on their account existing at all.

What This Means for Onboarding a New Team Member

In practice, the smoothest onboarding sequence is: tell the new person to create their own account first (with their own email and password, going through normal signup and email verification), confirm with them once that's done, and then send the workspace invite using the exact email address they signed up with. Because the lookup is an exact email match, a typo or a mismatch between the email you invite and the email they actually registered with will fail the invite with a "not registered yet" message even though they do, in fact, have an account — just under a different address than the one you tried. That mismatch is the single most common reason a seemingly correct invite doesn't go through, and it's worth double-checking the exact email before assuming something's broken.

How This Differs From Client Portal Access

It's worth contrasting this account-required invite flow against how clients get access to their own invoices, because the two systems intentionally work in opposite ways. A client viewing their invoices through a share link or the client portal never needs an account at all — that access is deliberately frictionless, since clients are external parties you want to reach as easily as possible, with no signup barrier standing between them and a document you've sent them. Workspace membership is the opposite case: it grants real, ongoing access to create, edit, and view every invoice, client, and financial report in your workspace, which is a meaningfully higher trust level than viewing one document through a link. Requiring a real, verified account before that level of access is granted isn't an oversight or a missing convenience feature — it's the same account-identity system used everywhere else in the product being applied consistently to the one area where the access being granted is broad rather than narrow.

What Happens to a Membership If the Invited Person Later Deletes Their Account

Membership rows created by this invite flow are tied directly to the invited user's account, and that link runs in both directions: if a team member you invited later deletes their own account entirely, their membership row in your workspace is removed as part of that deletion, the same way it would be if you'd manually removed them yourself. Their name disappears from your member list, and any invoice or comment attribution tied specifically to their user ID goes with it. This is a good reason to be deliberate about who ends up owning a shared workspace in the first place: if the person who owns the workspace is the one who deletes their account, the removal cascades much further than a single membership row, taking the entire workspace with it. That specific scenario, and how to avoid getting caught by it, is covered in full in the guide to what happens when you delete your account — the short version relevant here is that inviting teammates is safest done from an account that isn't also the sole owner of a workspace other people depend on.

What the Available Roles Actually Control

A workspace supports a small set of roles — admin, member, and an accountant-oriented role — assigned at invite time and adjustable afterward through the role-update action described above. The specific day-to-day permission boundaries between roles govern what a member can see and change, but the invite and role-management mechanics described in this article work identically no matter which role you're assigning: the lookup-by-email requirement, the "already registered" gate, and the owner-role protection all apply the same way whether you're bringing someone on as a full admin or a more limited accountant-style collaborator. Deciding which role fits a given person is a separate question from how the invite mechanism itself behaves — get the invite flow right first, using the exact email they registered with, and the role can always be adjusted afterward without needing to remove and re-invite them.