Team & roles

A workspace can have many team members, each with a role. The app lists them under Settings › Workspace › Team (/settings/team; Dutch: Team, one person is a teamlid); the words "member" and "operator" in older pages mean the same people. Roles determine what they can do — manage AI employees, see billing, remove other team members. This page covers the roles, the invitation flow, and what changes when a team member is added or removed.

Roles

Four roles, in order of authority:

Role	Can do
Owner	Everything an Admin can plus manage billing. Only role that can subscribe / change plans / cancel.
Admin	Manage members and invitations. Manage agents, knowledge, behavior rules, integrations. Read all conversations and leads. Cannot manage billing.
Editor	Manage agents, knowledge, behavior rules. Read all conversations and leads. Cannot manage members or billing.
Viewer	Read-only. View agents, conversations, leads, analytics. Cannot edit anything.

Roles live in the workspace_users pivot table; the WorkspaceRole enum exposes capability methods — canManageAgents() (Owner / Admin / Editor), canManageMembers() (Owner / Admin), canManageBilling() (Owner only), canViewAnalytics() (everyone) — used by the policy layer.

The menu follows the same rules: every page shares the current role's capabilities as workspaceCan, and a person only sees what their role can open. Settings is a menu item for everyone; its four groups are gated per entry (see Settings). Editors and viewers do not see Team, Integrations or API tokens; only the owner sees Plan and billing.

Buttons and links inside the pages follow the same rule, so nobody is shown a way to an error page:

• Viewers see an AI employee's Overview and Knowledge tabs, without Fixed answers (writing those needs edit rights), and under Advanced only Segments, Type of website and Nightly test questions. They get no Test it, Publish, Delete or New AI employee, no setup buttons, no lead-status or follow-up changes, no Resolve or Ignore on unanswered questions, and no adding, renaming or removing tags (Settings › Tags lists them read-only). Home still lists what needs attention, without the button to fix it. Old links to Customize or Settings of an AI employee open its Overview for them.
• Plan and billing links — the Upgrade card at the foot of the menu, and the buttons in the usage, trial and plan-limit banners — show only to the owner; everyone else reads Only the workspace owner can change the plan. When a trial has ended, pages under /app send the owner to Plan and billing and everyone else to Home, with a note to ask the owner.

Inviting

From Settings › Team, an Owner or Admin can invite by email. The invite gets emailed with a tokenized link to /invitations/{token}. Clicking it:

1. Shows the invite preview (workspace name, who invited, role).
2. Asks the visitor to log in or sign up if they aren't.
3. On accept, attaches them to the workspace with the assigned role and redirects to the dashboard.

Invites expire after 7 days. Owners and Admins can revoke a pending invitation from the Pending invitations section of the Team page — click Revoke, confirm, and the row is deleted. The revoke writes an invitation.revoked entry to the audit log. Already-accepted invitations cannot be revoked — remove the member from the Team members list instead.

Changing roles

Owners and Admins change a member's role with the role picker on their row: Admin, Editor or Viewer. The change takes effect on the member's next page load — no re-login needed — and writes a member.role_changed entry (before and after) to the audit log. Two rows have no picker, and the server refuses them too (PATCH /app/members/{member}): the owner's, and your own — an admin who made themselves an editor could not undo it.

Removing

Remove asks first, naming the person. Removing a member detaches them from the workspace; their personal account survives and they can be invited again. Replies they sent in taken-over chats stay attributed to them (each is stored with model human:<their user id>). The owner cannot be removed, and nobody removes themselves.

The owner

Every workspace has exactly one Owner, set when the workspace is created. The Team page cannot change or remove the owner, and there is no ownership transfer in the app.

Multi-workspace users

A user can be a member of any number of workspaces. The sidebar's workspace switcher (the workspace name card above the user avatar) lets them jump between memberships and, via the Create new workspace entry at the bottom of the dropdown, mint a new one. Each workspace has its own role for the user — an Owner of one might be a Viewer of another. The number of workspaces an Owner can mint is capped by plans.workspaces_limit; the cap is enforced server-side and the dialog surfaces the error inline.

The "current workspace" is resolved from the user's default_workspace_id field. Switching writes the new ID. All tenant-scoped queries thereafter run against that workspace. When a visitor accepts an invitation while their current default is a personal/auto-created workspace (one they own themselves), the accept handler switches their default to the invited workspace so they land in the right place. If their current default is itself an invited workspace they're actively using, the accept does NOT switch — to avoid yanking them out of context.

Audit log

Member changes — a member added directly, invitations sent and revoked, role changes, removals — write rows to the audit_logs table for forensic traceability. Accepting an invitation writes none. There is no audit page for customers; platform staff can browse a workspace's audit log at /admin/workspaces/{workspace}/audit.