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, and a fifth for an agency's client:

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.
Client owner	Only in a workspace that is a client of an agency: the client itself. Works like an Admin in the parts the agency opened for it (see Client access); never plan and billing.

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.

Agency people

A workspace that is a client of an agency can also be opened by the agency's people, without them being members — they do not show on the Team page and use no seat. They act with a role of their own:

• Agency owner (partner_owner) acts as an Admin: AI employees, team, settings and integrations, but never plan and billing.
• Agency staff (partner_staff) acts as an Editor: AI employees, knowledge and the inbox; no team, workspace settings, branding or billing.

A person who is also a member keeps the role of that membership. The agency cannot make its own people members of the client, or raise their role: agency access ends when the agency does, so only the client's own owner or admins can give an agency person a membership. Every opening by an agency is in the workspace's audit log. See Multi-tenancy › Agencies.

Client access

In a client workspace of an agency, the agency decides what the client's own people see and change: the client owner and everyone the client invites. The agency sets it per client under Client access on the client's page in the partner area, with a preset and then a level per part:

Preset	The client sees
No access	Nothing: the client cannot sign in.
Client portal (the default)	Conversations (read), taking over conversations, leads, results (read).
Full	Everything a direct customer has, except plan and billing.

Each part is then Hidden, Read or Edit: Conversations, Taking over conversations, Leads, Results, Knowledge, AI employee settings (personality, behaviour, lead capture, appearance, website and advanced, and adding or removing an AI employee), Integrations, Team, and API and webhooks. A hidden part leaves the menu and its pages and requests answer 403; a read-only part opens but refuses every change. Plan and billing, the workspace's General page and the AI keys are never open to the client. The agency's own people and platform staff are never limited by it.

The same parts limit what reaches the client in other ways: live updates (new leads, conversations) arrive only for open parts, a webhook for new leads needs Leads, and an API token the client makes works only while API and webhooks and its parts are open for editing — a WordPress token needs Knowledge and Integrations, a sources token Knowledge. Close a part later, or let the person go from the workspace, and the client's tokens and webhooks stop with it.

The client owner is invited from the same page. The mail and the invitation page are in the agency's branding, and a client without an account sets a password on the invitation page itself — no separate sign-up and no workspace of its own. Only the agency changes the role of the client owner.

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.