Invite your team and choose their roles

A workspace starts with exactly one person: you, as its owner. Everyone you add afterwards gets their own account in this workspace, sets their own password, and holds one of three roles.

Start with the part that decides how many people you can have at all.

Seats

The free plan seats two: you, and one teammate. Which role that teammate gets is your choice — an operator to share the inbox with, or an admin who can also write the knowledge base.

A seat is held by an active teammate and by an invite nobody has accepted yet. That is deliberate: without it, a workspace could send twenty invites on a plan with five seats and find out only as they were accepted, one refusal at a time. A teammate's role has nothing to do with it — the quota counts people, not what they may do.

A deactivated teammate holds no seat. That is what makes deactivating somebody the way back under your plan's limit, and it is also why bringing them back is a request that can be refused.

Once every seat is spoken for, the Team page replaces the invite form with a banner saying how many of how many seats are in use.

Send the invite

Team in the console, then Invite teammate. Three fields — full name, email, role — and one button.

What happens next is entirely between us and them:

• They get an email, "You've been invited to your workspace on Replium", naming you as the person who invited them.
• The link in it is good for 7 days.
• Opening it asks them to choose a password — at least 8 characters, with a letter and a digit — and signs them straight in.

You never see, set or need their password. If a colleague asks you what their password is, the honest answer is that nobody here knows it.

Until they open that link, the Team page shows them as invited: the row exists, the seat is spent, and the account cannot sign in yet because it has no password at all.

What each role may do

Two things this table is really saying:

• An operator's job is the conversation. They answer chats, hand them over, and read the templates and the knowledge base — and everything that configures the workspace is closed to them. That is why the inbox has no per-verb restriction for them: an inbox you may read but not reply in is not an inbox.
• Owner and Admin are the same role in practice, except where the owner role itself is concerned: only an owner can grant it, and only an owner can change or end the standing of another owner.

Changing a role later

Roles are not decided once at invite time. On the Team page each row carries its role as a control, and picking a different one applies immediately — no re-invite, no new password, nothing on the teammate's side to do.

Three rules govern it, and a row you may not change shows its role as plain text with the reason next to it:

• Nobody changes their own role. Not even an owner — the button is not there for your own row.
• Only an owner may change an owner's role. For an admin, an owner's row is read-only.
• Only an owner may grant the Owner role. An admin's role picker simply does not offer it.

A deactivated teammate's role is locked too — bring them back first, then change it.

Together those keep the thing nothing else guards: a workspace always has at least one owner. The last owner cannot be demoted or deactivated by an admin, and cannot do either to themselves. Changing a role never affects seats — a seat is a person, whatever they may do.

Taking somebody off the team

The last column of the Team table carries exactly one action per row, and which one it is depends on that row's status:

The rules are the same two that govern a role change, and they hold the same invariant: nobody does this to themselves, and only an owner does it to an owner. A row you may not act on carries no action at all.

Deactivate

It asks you to confirm first. Then, at once:

• They are signed out — every session they hold is ended.
• Their open conversations go back to the queue, unassigned. A conversation assigned to somebody who can no longer sign in is one nobody is answering and nobody can see is unanswered. Closed conversations keep their operator: there the name is the record of who dealt with it, not a job waiting to be done.
• Their seat is freed.
• Their personal integration tokens stop working, so an AI client signed in as them stops too.
• The row reads Deactivated, and the green online dot goes out.

One caveat worth knowing rather than discovering: if they have the console open at that moment, that tab can keep working for up to ten minutes. Sessions are ended immediately, but the short-lived token already in their browser is checked by its signature rather than against their row, so it runs out instead of being torn up. It is the same lag a role change and a password reset have. Anything that needs a fresh one — a reload, or simply waiting — stops.

Deactivating is not deleting. Their name stays on every message they sent and every article they wrote; only the ability to sign in and take up a seat goes away.

Reactivate

This one acts on the click, with no confirmation step — it gives access back rather than taking it away.

• Their old password still works. This is not a fresh invite: no email is sent, and there is nothing for them to accept.
• It takes a seat, so it can be refused by a plan that filled up while they were away. Free a seat or upgrade, then try again.
• Their old conversations do not come back to them. Those went into the queue when they left, and somebody has presumably picked them up since.

Revoke invite

This one is only offered for somebody who never opened their link. The row itself is deleted, which means:

• the link you mailed them stops working;
• the seat is released;
• and the address is free to invite again — which is the whole point, because otherwise a mistyped or abandoned invite would hold that address forever.

Somebody who has already accepted cannot be un-invited — deactivate them instead. And a deactivated person's address is not free either: the answer for them is Reactivate, not a new invitation.

Fixing an invite that went wrong

There are two levers, and they fix different mistakes.

Invite the same address again, while that invite is still unaccepted. This issues a fresh link and kills the previous one, and spends no new seat — the row was already there and already counted. Use it when the invite expired, went to spam, or carried a typo in the name.

Revoke it and start over. Use it when the address was wrong, or when you simply do not want that person any more.

The second lever is also the way out of a tight spot on the free plan. The Team page hides the invite form once every seat is spoken for, and on the free plan "you, plus one invite that expired" is already both seats — so the form you would fix it with is not on screen. Revoke the invite: that frees the seat, and the form comes back.

What still cannot be done

A teammate cannot be permanently deleted. Deactivation is as far as it goes, and that is a deliberate choice rather than a missing button: erasing the row would take their name off every message they ever sent and leave years of conversation history anonymous. If your workspace has an obligation that deactivation does not satisfy, write to us.

After they are in

• Their account belongs to this workspace and no other. The same email address in another Replium workspace is a separate account with its own password and its own role; signing in to one is not signing in to the other.
• They sign in at your workspace's own address, your-workspace.replium.chat, not at replium.chat.
• The Team page shows who is online, updating as people open and close the console — which is also what the "nobody is online" alert is measuring when a visitor is left waiting.