Chapter 07 · 3 min

Teams: inviting people, roles, and the audit trail

Who can approve, who can merge, and how every decision is recorded.

A Trevo organisation owns billing and membership; a workspace owns a repository and its data. People join the organisation by invite and see every workspace in it. Four built-in roles cover most teams.

• Owners hold every permission, plus the two that can never be delegated: billing and deleting the organisation. Only owners grant the admin role.
• Admins hold every permission — the experiment loop plus the org-level controls: SDK keys, the GitHub connection, integrations, billing, and members.
• Developers run the whole experiment loop: review proposals, create, start and pause experiments, ship or reject results, and manage funnels and workspaces — without touching keys, GitHub, billing, or membership.
• Members see everything, can read every proposal, PR and result, and cannot change state. Controls they cannot use are shown disabled with the reason, never hidden, so a member always knows what to ask for.

Custom roles

When the built-ins do not fit, anyone who can manage members composes a custom role on the Team page from the same permission catalogue the built-ins use — eleven permissions across experiments, workspaces, code & keys, and organisation. A “Release manager” who only ships or rejects results, an “Analyst” who manages funnels and nothing else, an “Ops” role for keys and the GitHub connection: each is a named set of checkboxes, assignable on any member row or straight from the invite. Editing a role re-applies to everyone holding it within moments, and a role cannot be deleted while anyone still holds it.

Who merges

Trevo roles govern Trevo. GitHub governs GitHub. The pull request the bot opens is merged by whoever your repository allows to merge, under your branch protection, your CI, your review rules. That separation is deliberate: the person who approves a hypothesis and the person who accepts code into main do not have to be the same person, and often should not be.

The audit trail

Every state change — proposed, approved, dismissed with a reason, PR opened, merged, paused by a guardrail, shipped, reverted — is an append-only record with who, when, and what the numbers were at that moment. Dismissals ask for a reason and feed the engine, so the next batch of proposals is calibrated by what your team actually rejects. The security reviewer who wants a document rather than a walkthrough should read How Trevo decides: the statistics, the safety brakes, and the permission model, written to be attached to a ticket.