Roles and permissions

The role model in Telmoni: organization roles, project roles, what each allows, and what a permission refusal tells you.

Permissions in Telmoni are governed by three roles: Owner, Admin, and Member. Roles operate at two levels: across the Organization and within individual Projects.

Organization roles

An organization role governs the organization's management: creating projects, managing organization settings, invite authority, and organization-wide audit logs.

Permission	Owner	Admin	Member
Open the organization's Settings and Projects pages	Yes	Yes	No
Create new projects	Yes	Yes	No
Delete projects	Yes	No	No
Manage organization settings and rename	Yes	Yes	No
Manage organization members and invites	Yes	Yes	No
Add a member of the organization to a project, without an invitation	Yes	Yes	No
View the organization's roster and invitations	Yes	Yes	No
View rolled-up organization audit log	Yes	Yes	No
Export the organization audit log	Yes	Yes	No
Transfer organization ownership	Yes	No	No
Delete organization	Yes	No	No

Owner: Full access to the organization and all its projects. Can create and delete projects, manage settings, invite and remove members, view rolled-up audit logs, transfer ownership to an Admin, or delete the organization.
Admin: Administrative access across the organization. Can create projects, manage settings, invite members, view rolled-up audit logs, and acts with admin authority in every project. Cannot delete projects, transfer ownership, or delete the organization.
Member: Default role for invited members. Has no organization-wide management authority. Access is limited strictly to the projects they have been seated in, governed by their project role. A Member is also the one an Owner or Admin can add to a project from the organization's roster, as an Admin or a Member there, since the Owner and Admins hold every project.

An organization role is a floor no project seat lowers: the Owner is Owner on every project, and an Admin is Admin on every project, whatever seat they also hold. An organization Member's standing on a project is their seat alone, and no seat grants anything on the organization, though a project invitation a project Admin sends does put the person it seats on the organization's roster as a Member.

Project roles

Inside each project, a project role decides what you can do with project resources: API keys, connectors, saved views of its traces and layouts of its sessions, and project audit events.

Permission	Owner	Admin	Member
View project overview and resources	Yes	Yes	Yes
Read the project's notices on its Overview, and mark them read for everyone on it	Yes	Yes	Yes
Open the project's saved views of its traces and saved layouts of its sessions	Yes	Yes	Yes
Save, rename, and delete saved views and layouts, and set the layout the project opens in	Yes	Yes	No
View API keys (names and dates, never the raw key)	Yes	Yes	Yes
Create, rotate, and revoke API keys	Yes	Yes	No
View connectors and delivery logs	Yes	Yes	Yes
Create, test, update, and disconnect connectors	Yes	Yes	No
Rotate webhook secrets, resend deliveries	Yes	Yes	No
View project members	Yes	Yes	Yes
Invite members to project, change project roles	Yes	Yes	No
Read project audit log	Yes	Yes	No
Rename the project	Yes	Yes	No
Change the project's content mode	Yes	No	No
Transfer project to another organization	Yes	No	No
Delete project	Yes	No	No

Owner: Full control over the project, including its content mode, project deletion, and transferring the project to another organization. The organization Owner holds Owner privileges across all projects in the organization.
Admin: Operates the project: creates, rotates, and revokes API keys; manages Slack and webhook connectors; manages project seats; saves the trace list's views and the sessions' layouts, and sets the layout the project opens in; and reads the project audit log. Cannot change the project's content mode, or delete or transfer the project.
Member: Read-only access to project resources. Can inspect active connectors, delivery logs, and API key metadata (name, creation date, last used date), and open the project's saved views and layouts. Cannot view the project audit log, and changes nothing but whether the project's notices are marked read, which is the same for everyone on the project, and their own seat, which they give up with Leave on the project's Members page.

What a refusal tells you

When you attempt an action your role does not allow, the API and console refuse the request with a 403 Forbidden problem document. A project's members and invitations, its rename and deletion, and its content mode, answer /errors/authz/insufficient-role, and detail names the least role that would do and the one you hold:

{
  "type": "/errors/authz/insufficient-role",
  "title": "insufficient role",
  "status": 403,
  "detail": "required admin, have member"
}

Every other refusal answers /errors/authz/forbidden, and detail says what is refused and to whom: API keys, connectors, saved views and layouts and the audit log (decided by the same role matrix), an organization's name and URL, the console agent, creating a project, the organization's roster and adding a member from it to a project, which a project Admin who is only a Member of the organization may not, its deletion and transfer, a project's transfer and, on the hosted service, billing. The server checks every request against the caller's roles; nothing is left to the browser.

On the hosted service an organization's plan can refuse too, whatever your role: a 402 /errors/plan/limit-reached, as a paused organization's invitations, and the members it would add to a project, are refused (One Hobby organization), and an invitation past Hobby's one member (One member on Hobby).

Roles and permissions

Organization rolesCopy Anchor Link

Project rolesCopy Anchor Link

What a refusal tells youCopy Anchor Link

On this page

Organization roles

Project roles

What a refusal tells you