> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs.pivolio.com/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.pivolio.com/_mcp/server.

# Team and roles

Everyone you invite joins your **account**, not a single workspace. This is the
detail that surprises people most often, so it's worth stating plainly:

> **Note**
>
> A role grants access to **all** of the account's workspaces. The role varies the
> *level* of access, never *which* workspaces someone can see. If you need one
> team to be unable to see another team's data, that's a separate account — not a
> narrower role.

## The four roles

* **`owner`** — full access to everything: every workspace, billing, member
  management, and workspace deletion. The account creator is an owner.
* **`admin`** — manages workspaces and their configuration: destinations,
  integrations, settings, reporting. Cannot touch billing and cannot manage
  members.
* **`member`** — operates workspaces day to day: sends and inspects events,
  reads reporting, works in the debugger. Cannot delete a workspace, cannot see
  billing, cannot manage members.
* **`billing`** — the plan, invoices and payment method, and nothing else. No
  workspace access at all.

## At a glance

| Capability                              | Owner | Admin | Member | Billing |
| --------------------------------------- | ----- | ----- | ------ | ------- |
| View workspaces and reporting           | Yes   | Yes   | Yes    | No      |
| Configure destinations and integrations | Yes   | Yes   | Yes    | No      |
| Create workspaces                       | Yes   | Yes   | Yes    | Yes     |
| Delete workspaces                       | Yes   | Yes   | No     | No      |
| Manage billing                          | Yes   | No    | No     | Yes     |
| Invite and manage members               | Yes   | No    | No     | No      |

> **Warning**
>
> **`admin` can delete a workspace.** The role is everything an owner has except
> billing and member management — deletion is not held back. If you want someone
> who can configure destinations but never remove a workspace, give them
> `member`.

> **Note**
>
> Creating a workspace isn't gated by role at all — any signed-in account can
> create one, and becomes its owner. The role governs what you can do inside
> workspaces you've been granted access to.

## Why `billing` has no workspace access

The `billing` role exists for the person who owns the card and nothing else — a
finance contact, an accountant, an ops lead at a parent company. Giving them a
`member` seat "just so they can log in" hands them your customer PII and your
event stream. Give them `billing` instead; they'll see the plan and the invoices
and no data.

The reverse is equally deliberate: an `admin` who runs your entire measurement
setup still cannot change the plan or read an invoice.

## Member management is owner-only

The permission that governs invites, role changes and removals —
`members.manage` — is held **only** by owners. Not by admins.

This is a design decision rather than an oversight. If admins could manage
members, an admin could grant themselves owner, or invite a second account they
control and promote it. By keeping the permission owner-exclusive, privilege
escalation isn't merely blocked at a check — it has no representation in the
model at all. There is no sequence of actions an admin can take that ends with
them holding more than admin.

> **Warning**
>
> Because only owners can manage members, an account with exactly one owner has a
> single point of failure — if that person leaves, nobody can invite, remove, or
> re-role anyone. Keep at least two owners on any account that more than one
> person depends on.

## Choosing a role

* Someone who ships tracking code or configures destinations → **`member`**.
  It covers the whole daily workflow.
* Someone who owns the measurement setup across brands, and can be trusted with
  workspace deletion → **`admin`**.
* Someone who pays the bill and shouldn't see event data → **`billing`**.
* Someone who needs to add or remove people → **`owner`**. Member management is
  owner-only, which is what stops a role from escalating itself.

Start people at the lowest role that covers their work. Promoting later is one
click; un-leaking data isn't.

## Related

* [Workspaces](/documentation/core-concepts/workspaces-write-keys) — what a workspace isolates, and when
  to create another one.
* [Billing](/documentation/guides/billing-plans) — plans, trials, and what happens without a
  subscription.