> ## Documentation Index
> Fetch the complete documentation index at: https://docs.joinruna.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Roles and permissions

> Who can do what — at the organization level and at the folder level.

Runa has two independent role systems:

* **Organization roles** — Owner / Admin / Member — control who can manage your team and billing.
* **Folder roles** — Owner / Editor / Viewer — control who can see and edit the content in a particular folder.

The two don't overlap automatically. Being an Admin in your org doesn't make you the Owner of every folder, and being an Editor of a folder doesn't grant any org-level rights.

## Organization roles

Every org member has exactly one of these three roles. All permission checks are enforced server-side, so the table below is the ground truth.

| Capability                              | Owner | Admin | Member |
| --------------------------------------- | :---: | :---: | :----: |
| View the member roster                  |  Yes  |  Yes  |   Yes  |
| Invite new members                      |  Yes  |  Yes  |   No   |
| Choose role on invite (Member or Admin) |  Yes  |  Yes  |    —   |
| Change an existing member's role        |  Yes  |  Yes  |   No   |
| Promote / demote an Owner               |  Yes  |   No  |   No   |
| Remove a member                         |  Yes  |  Yes  |   No   |
| Rename the organization                 |  Yes  |  Yes  |   No   |
| Delete the organization                 |  Yes  |   No  |   No   |
| Leave the organization                  |  Yes¹ |  Yes  |   Yes  |
| View billing and usage                  |  Yes  |  Yes  |   No   |
| Manage subscription, upgrades, codes    |  Yes  |  Yes  |   No   |
| Allow org-wide speaker profiles         |  Yes  |  Yes  |   No   |
| Edit your own title                     |  Yes  |  Yes  |   Yes  |
| Override another member's title         |  Yes  |  Yes  |   No   |

¹ The system always blocks the **last remaining Owner** from leaving or being removed. Promote another member to Owner first.

### What "Owner" means

There can be one or more Owners on an org. Owners are the only role that can:

* Promote or demote another **Owner**.
* **Delete** the organization itself.

Otherwise, day-to-day, an Admin can do everything an Owner can.

### Free vs. paid plans

A handful of admin actions return a `402 Payment Required` error on the **Free** plan if attempted by a non-Owner/Admin. In practice this means: the Free plan still has Owners and Admins, but some workspace-management actions are gated behind upgrading.

## Folder roles

Folders are how Runa decides who can see which meetings. Each folder has its own roster of roles, separate from the org roster.

| Capability                     | Owner | Editor | Viewer |
| ------------------------------ | :---: | :----: | :----: |
| Read meetings in the folder    |  Yes  |   Yes  |   Yes  |
| Edit meeting notes / titles    |  Yes  |   Yes  |   No   |
| Add new meetings to the folder |  Yes  |   Yes  |   No   |
| Change folder visibility       |  Yes  |   No   |   No   |
| Share via link / contact       |  Yes  |   No   |   No   |
| Delete the folder              |  Yes  |   No   |   No   |

Folder visibility options:

* **Private** — only you (default for new folders).
* **Org** — every member of your organization.
* **Shared link** — anyone with the invite URL.
* **Shared contact** — specific contacts you've shared with.

When you share a folder via link or contact, you choose whether new members join as **Editor** or **Viewer**. You can't grant **Owner** through a share link; ownership is transferred only by an existing Owner.

<Note>
  The **Personal** folder is protected. It's auto-created for every user, can't be deleted, and is always private to you. Meetings outside any explicit folder land there by default.
</Note>

## How enforcement works

All role checks happen server-side at the gateway:

* Reads are scoped by `WHERE` clauses that include only resources you can access.
* Writes are checked via a `user_can_access_folder(folder_id, mode)` helper before any mutation.
* The desktop app surfaces denied actions as toast notifications (typically "You don't have permission to do that").

This means **changing the UI doesn't grant access** — even if a button is visible, the server will reject the action if your role doesn't permit it.

## Recommended setup for small teams

* **2 Owners minimum.** Single-Owner orgs work, but if that person leaves the company you'll need support help to recover. Two Owners give you safe redundancy.
* **Use Admins liberally.** Admin is the right default for anyone helping run the workspace — they can do everything Owners can except touch Owner status or delete the org.
* **Use folder visibility for project boundaries.** Create an **Org**-visibility folder per project so the right people see the right meetings without needing case-by-case sharing.
* **Keep sensitive 1:1s in Personal.** Performance reviews, hiring conversations, and similar should stay in your Personal folder, not in any shared folder.