# Roles, plans and seats

> Who can do what, how the trial and paid seats work, and how seat counts are enforced.

Source: https://triagic.com/docs/concepts/roles-and-access

## Roles [#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. Managed on the **Account** page, not in the member list (see [Architecture](/docs/concepts/architecture#identity)). |
| **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. The nav is a
convenience, not the access control, which is enforced by the service itself.

> **Warning:** 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 [#plans-and-seats]

There is one plan, sold per seat per month: no tiers, no feature-gated editions.
See [Pricing](/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](/docs/admin/account-billing).

> **Warning:** 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.

Add-ons are per seat. An org admin buys N seats of an add-on and assigns them to specific members; two members of the same org can hold different add-ons.

## How the seat cap bites [#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](/docs/admin/account-billing).

## What a member can and cannot see [#what-a-member-can-and-cannot-see]

This distinction causes the most confusion, so it's 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.

> **Warning:** "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](/docs/admin/security).