Users, roles and the audit log
What each role can do, why an action might return a 403, and what's recorded on every change.
Roles
| Role | Can do |
|---|---|
| Owner | Everything, including billing, license management, and transferring ownership. There's exactly one per instance. |
| Admin | Everything except transferring ownership. |
| Developer | Read and write tickets, control runs (run, cancel, retry), read Insights. |
| Viewer | Read-only. Free and unlimited: a Viewer never counts against your seat limit. |
Approve & commit and Revert need Owner or Admin by default; this is configurable if you want a Developer to be able to approve their own runs.
Inviting, deactivating, and managing what counts against your seats is covered in Users, seats and projects.
Sessions, and why you might see a 403
Signing in creates a server-side session held in a cookie your browser's own scripts can't read and won't send cross-site. Every action that changes something, not just views something, carries a matching CSRF token alongside that session.
A few reasons you might see a 403 that aren't a bug:
- A stale tab. If a session ends and you act from a tab that's been open a while, refresh and try again.
- Your role. A Viewer gets a 403 on write actions immediately and on purpose. It isn't a glitch, it's the permission working as intended.
- A CI script or automation using an expired or under-scoped API token.
Automating against the API, from CI or a script, uses a scoped, expiring API token from Settings → API tokens instead of a browser session. Give it only the scopes the job actually needs.
The audit log
Every mutation (a run started, a ticket approved, a secret replaced, a role changed) writes an audit row: who did it, what it was, when, and on what. It's append-only; nothing in the dashboard edits or clears it.
Search it from the Audit log page with free text plus facets (user, action, project, date range), useful both for "who approved this" questions and for a periodic access review.