Team and permissions

A workspace is shared. Who can get in, and what they can do once they are, is decided by their seat.

Members, roles and capabilities

Access to a workspace comes from a membership, not from ownership. Each membership sits at one of four levels:

Level	What it’s for
operator	Someone who answers chats, and nothing else.
member	Day-to-day work: chats, docs, feedback, tools, errors, settings (read).
admin	Everything except owning the workspace.
owner	Full control. Every workspace has exactly one.

Under the hood a level is a bundle of named capabilities. These are the capabilities that exist:

Capability	What it allows
chats.read	See conversations and transcripts.
chats.reply	Reply as a human operator, hand back to the bot, close a chat.
feedback.read	See UI feedback tickets.
feedback.manage	Triage, resolve, and dismiss feedback.
visitors.read	See the visitor list and their details.
visitors.delete	Delete visitor records.
docs.read	See the knowledge base.
docs.write	Create, edit, publish, scrape, and delete knowledge-base docs.
tools.read	See the workspace’s custom bot tools.
tools.write	Create and edit custom bot tools, including ones that make server-side requests.
errors.read	See errors reported from your app and the widget.
rooms.read	See the workspace’s chat rooms and their messages.
rooms.write	Create rooms, join them, and post messages and attachments.
rooms.manage	Edit or delete any room and remove any member’s message.
settings.read	See branding and bot settings.
settings.write	Change branding, the bot’s system prompt, and the model it uses.
embed.read	See the embed snippet and public key.
embed.manage	Rotate API keys and change the origin allowlist.
api_tokens.read	See the workspace’s API tokens.
api_tokens.manage	Create and revoke API tokens.
members.read	See who is in the workspace.
members.manage	Invite people, change their level, and remove them.
workspace.manage	Reserved to the owner — the one capability an admin never holds.

And this is how the levels map onto them:

• operator — chats.read, chats.reply, feedback.read, visitors.read, members.read, rooms.read, rooms.write.
• member — everything an operator has, plus feedback.manage, docs.read, docs.write, tools.read, errors.read, settings.read, embed.read, api_tokens.read.
• admin — every capability except workspace.manage. That includes settings.write, embed.manage, api_tokens.manage, tools.write, members.manage, visitors.delete and rooms.manage.
• owner — every capability, including any added later.

Two rules follow from the way capabilities are defined, and they’re worth knowing:

• A write implies its read. Holding docs.write always also grants docs.read. You never end up able to edit something you can’t open.
• A level is a floor, not a ceiling. Individual capabilities can be granted to one person in one workspace on top of their level — that’s how “an operator who can also edit the knowledge base” works without inventing a new level.

Who can act on whom

Managing members asks two separate questions, and passing the first doesn’t mean passing the second:

1. May you manage members at all? (members.manage)
2. May you manage this member?

The second is a rank rule. You may only act on someone strictly below your own level, and you may never grant a level above your own. So an admin can promote a member to admin’s level but not to owner, and can’t demote or remove another admin. The owner is the exception: they run the place and can act on anyone.

The owner’s seat is immovable: it can’t be removed or demoted from the Members page by anyone, including the owner. A workspace always has exactly one.

Removing yourself is different: leaving needs no member-management capability, because nobody needs permission to walk out. Anyone except the owner can remove their own seat from the Members page, and you’re returned to whichever workspace you still have access to.

Presence

The “who’s around” signal is derived from real activity — your membership’s last-active timestamp is touched as you use the workspace, and anyone who can reply to chats and has been seen in the last five minutes counts as available. There’s no manual “I’m available” toggle, because nobody remembers to switch one off and a stale “online” promises your visitor a person who isn’t there.

Invitations

Invitations are addressed to an email address, not to an account — most invitees don’t have one yet. Invite from the Members page, pick the level (you can’t offer a level above your own), and they get a link.

A few things to know:

• A mismatched account is refused. Accepting an invitation checks that the signed-in account’s email matches the address that was invited. Otherwise forwarding the email would hand your workspace to whoever received it.
• Invitations expire after 14 days and a workspace can hold at most 50 pending at once.
• “Resend” issues a new link and retires the old one. Only a one-way digest of the token is stored, so the original link can’t be recovered or re-sent — a resend is a fresh invitation to the same address at the same level.
• Revoking is permanent. A revoked invitation can’t be restored; issue a new one. Revoking an invitation follows the same rank rule as issuing one.
• Re-inviting an existing member never demotes them. If someone is already in the workspace at a higher level than the invitation says, they keep the higher level.
• Losing your seat retires the invitations you issued. If you’re removed from a workspace, every invitation still pending in your name is revoked with you.

You can’t invite an address that’s already a member, and you can’t have two pending invitations to the same address in the same workspace.

Managing seats from a terminal

Seats and invitations are also reachable from the command line, which is useful when onboarding is part of a script rather than something done page by page:

vroxy members <ws> list               # seats, membership ids, pending invites
vroxy members <ws> invite [email protected] admin
vroxy members <ws> role 42 operator
vroxy members <ws> revoke <invitation>

Both rank rules above are enforced by the server, so they hold there exactly as they do here: no granting a level above your own, and no acting on someone at or above your own. The CLI is a different door into the same room, never a way around it.