Roles, plans and seats
Who can do what, how the trial and paid seats work, and how seat counts are enforced.
Roles
| Role | Where it comes from | Can do |
|---|---|---|
| Owner | The account that signed up and pays | Everything an org admin can, plus billing, seats and device activations on the Account page. Has no member row — see Architecture. |
| Org admin | Granted by the owner or another org admin | Members, teams, playbooks, shared integrations, AI providers, spend cap, audit log |
| Member | The default for an invited person | Works tickets and the Console in the desktop app. Reads the playbooks shared with them. Sees which shared integrations exist, never their credentials. |
The portal navigation reflects this: AI Providers and Audit only appear for
org admins, and Account only for the owner. A member who navigates directly to
/audit gets an "org admins only" page rather than an error, because the underlying
endpoint refuses them too — the nav is a convenience, not the access control.
Two guardrails you cannot click past
You cannot change your own role, and you cannot disable yourself. Both are blocked in the UI so an organization can't be left with nobody who can administer it.
There is also a super admin role, but it is global and lives on the desktop side of the product for break-glass access to a local install. It is not something you assign from the portal.
Plans and seats
There is one plan, sold per seat per month — no tiers, no feature-gated editions. See Pricing for the current per-seat price. An account is always in exactly one of three states:
| State | What it means |
|---|---|
| Trial | A 14-day free trial, no credit card, starting the day the account was created. One seat — the owner. |
| Licensed | A paid subscription. You have as many seats as you bought. |
| Expired | The trial ran out, or a license lapsed. |
The trial is one seat, so inviting anyone requires buying seats first. Member invites are refused while the account is on trial; start on the Account page — see Account and billing.
Expired is a paywall, not a downgrade
When an account expires, the desktop app locks to a full-screen license screen until the organization subscribes. Nothing is deleted — tickets, threads, playbooks, integrations and history are all exactly where you left them, and come back as soon as the subscription does.
Above 500 seats, self-serve checkout hands off to us for a negotiated license.
How the seat cap bites
The cap is enforced when you add a member, not in the background. Once the organization's active member count reaches the purchased seat count, creating another member fails and the dialog shows:
You're at your seat limit (n). Add seats to invite more. Upgrade
Two consequences worth planning around:
- Disabling frees a seat; the row stays. Removing a member soft-disables the account rather than deleting it, so synced desktop installs keep their history and attribution intact. Re-enabling them consumes a seat again.
- The owner counts. They appear in the member list because they are a real user of the product.
Buy or change seats from the Account page — see Account and billing.
What a member can and cannot see
This distinction causes the most confusion, so it is worth stating flatly.
A member can:
- see that a shared integration exists, what it is called, and select it when editing a playbook they have access to;
- run the agent against that integration, and therefore read whatever data the integration's credential can reach.
A member cannot:
- see the credential's value. The member-facing view has no credential, environment or header fields at all — not even masked ones — so there is nothing to inspect, in the UI or at the API level.
- edit a shared integration's configuration, which is what stops them repointing a stored credential at infrastructure they control.
"Use, not view" is about the secret, not the data
A member who can use a shared Postgres integration can read whatever that Postgres user can read. Scope the credential itself — read-only database users, narrowly scoped tokens — exactly as you would for any per-user integration. See Security model.