Members and invitations

Inviting people, what the invitation link is, why an invite can be refused, and the rules around removing someone.

Everyone who works in a workspace gets there by invitation. This page covers sending them, what can go wrong, and what happens when someone leaves.

Sending an invitation

Invitations live in settings, under Members. Only a workspace Owner or Admin can send one.

One invitation sets three things together, so the person arrives ready to work rather than in an empty workspace with no access:

  1. Their email address.
  2. Their workspace role — Admin or Member. This is the administration axis: who can invite people, change settings and manage billing.
  3. The teams they join, and their role on each. This is what actually gives them access to documents. A workspace role alone shows them nothing.

You can place someone on several teams in a single invitation, with a different role on each. If you send an invitation with no team, they arrive able to see the workspace and none of its documents — occasionally what you want for an administrator, rarely what you want for anyone else.

The default team role is the one that can write and submit but not approve. That is the right default: it is the useful rung, and approval authority is worth granting deliberately.

Which role to pick is on Roles and permissions.

The invitation itself

The invitation is a single-use link tied to that email address. It expires, and the expiry is shown to you when you create it.

Whether Alchex emails the link or hands it to you to share depends on how your workspace is configured. If no email goes out, you will be given the link — send it however you normally send things. Either way it is the same link, and it works once.

The person following it can sign up, sign in, or use a single-sign-on provider — the accept page handles all three. There is no separate in-app screen where they paste a code.

Their access is created on their first sign-in, not when the invitation is sent. So a pending invitation is a promise, not a membership: until they accept, they hold no role and appear in the pending list rather than the member roster.

If an invitation is lost, resend it — that costs you nothing and cannot be refused, because the invitation is already holding its licence.

Resending one that has expired is a different act. An expired invitation has already given its licence back, so re-issuing it is checked against your licences exactly like a brand new invitation, and can be refused for the same reason. Otherwise every invitation a workspace ever let lapse would be a licence you could keep claiming for free.

Why an invitation can be refused

Three refusals account for nearly all of them:

You are out of licences. An invitation reserves a licence at the moment you create it, so the refusal happens up front rather than when the person accepts. On the free plan this is the third member, and you are offered an upgrade. On a paid plan it means your members and pending invitations already fill every licence you have bought — and there you are offered the choice rather than simply stopped: add a licence, with the cost shown before you agree, and the invitation goes out immediately after. Nothing is ever bought unless you accept it, and buying licences ahead of time on the billing page works too. See Seats and licences.

You are in a personal workspace. A workspace of one cannot take invitations at all. Create or switch to a proper workspace first. See Workspaces.

You are not an Owner or Admin. Sending invitations is a workspace-administration action.

The member roster

The Members screen lists everyone whose access is live. Pending invitations are listed separately, because the two are genuinely different states.

Each row shows the person's workspace role. Their team roles are managed on the teams themselves, not here — one person can hold several, so there is no single team role to show on a workspace roster.

Removing someone

Removing a member ends their access to the workspace immediately: every team, every document. It does not delete anything they wrote. Their drafts, comments, submissions and approvals stay exactly where they are, still attributed to them, because the record of who approved what has to survive them leaving.

Two rules apply:

  • The last Owner cannot be removed. A workspace with no Owner would have nobody able to administer it, so the final Owner is not removable — by anyone, including themselves. Promote someone else first.
  • Removing a member frees their licence. It returns to your pool for the next person. Whether you also stop paying for it is your call at that moment: the remove dialog offers to release the seat as well, and left unticked — the default — you keep the licence. If the release is attempted and fails, you are told, rather than left paying for it in silence. See Seats and licences.

If someone is leaving but their approvals matter, remove them rather than deleting anything. Removal preserves the history; there is no action that scrubs a person out of the audit trail, by design.

Changing what someone can do

  • Workspace role — Owner or Admin changes it on the Members screen.
  • Team role — changed on the team, by a team Owner or a workspace Admin/Owner.

Both take effect immediately. Because permission decisions are made on the server for every request, a role change lands even on a browser tab the person left open.

Next