DocsAdministration

Workspaces and members

Invite teammates, manage roles, and scope access per project.

Last updated 2026-08-26

A workspace is the isolation boundary in EvaliQA. Every project, credential, dataset, run, and API key belongs to exactly one workspace. Members of one workspace can never see another workspace's data.

Roles

Each member has one workspace-level role:

RoleWhat it can do
ViewerReads. Projects, datasets, runs, reports, traces, the plan and the credit balance. Changes nothing.
MemberThe work: creates and edits projects, datasets, test plans and metrics, starts runs, manages project API keys. Spends the workspace's credits and allowances by running things.
AdminThe workspace: invites and removes people, sets project access, manages LLM credentials and connectors, picks the Platform AI agent source, buys credit packs, deletes projects.
OwnerThe money and the workspace itself: subscription and billing portal, handing the workspace over, deleting it. One per workspace.

Each role includes everything the one above it can do. Two rules are worth spelling out:

  • A workspace has exactly one owner. Handing it over is its own action on the members list, and it moves the previous owner to admin, so there is never a moment with two.
  • Deleting a project is an admin action, because it takes the datasets, runs, reports and traces inside it with it, and those belong to whoever made them.

Scoping somebody to a few projects

An invite can name the projects the person should see instead of the whole workspace. Useful for an external collaborator, or a team that keeps one client per project.

Two things worth knowing about how that narrowing behaves:

  • It covers everything, not just the project list. The test plans, datasets, evaluation runs, reports, traces and voice runs of a project they were not given are invisible to them, and a request that names such a project is refused rather than answered with an empty list.
  • It keeps up with new work. A project created after they joined is outside their scope too, so an invite to two projects stays an invite to two projects as the team keeps building. An owner or admin can widen it on the project's sharing sheet.

Owners and admins are never scoped: the workspace is theirs to administer, and a narrowed administrator could not do the job.

Invite a member

Open /settings?section=members. Click Invite and enter:

  • Email address.
  • Role.
  • Optional project scope (leave empty for "all projects").

The invite email lands within a few seconds; the invitee follows the flow described in Sign up.

Change a member's role or remove them

On the members list, use the row's actions menu. Removing a member immediately revokes their access; runs and objects they created stay attributed to them.

Hand the workspace to someone else

Owners see Make owner next to every other member. The member becomes an owner and you stay on as an admin, so handing over administration and leaving are separate decisions.

Leave a workspace

Settings, Workspace, Leave workspace. Projects, runs and reports stay with the workspace, they belong to it rather than to you, and an owner can invite you back later.

Two cases are refused: the last owner has to hand the workspace over first, and a member whose only workspace this is stays put, because leaving would drop them into an app with nothing in it. If you want out entirely, delete your account instead (Settings, Profile).

Delete a workspace

Owners only, in Settings, Workspace, after removing the other members and typing the workspace name. Projects, datasets, runs, reports and traces are deleted across every service and the subscription is cancelled. There is no undo.

What EvaliQA staff can see

Platform administrators run the service, not your workspace. They see metadata: the workspaces that exist, how many members and projects each has, which plan it is on, and aggregate usage. That is the whole of the ordinary view, and your projects, datasets, runs and traces are not part of it.

Looking inside a workspace is a separate, deliberate act. It is refused by the ordinary workspace switcher, has to be started from the admin surface, requires a written reason, and records that reason together with who asked and which workspace, in the audit log. The Stripe billing portal, where your saved cards and invoices live, is not reachable this way at all: it opens only for the workspace owner.

Create additional workspaces

Multiple workspaces are a Custom-plan feature. On Free and Team the workspace switcher's Create workspace button is disabled, and the server refuses the request as well.

Switching between workspaces fully remounts the app so no stale data leaks between them.