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

# Roles and access

> Understand how organization roles, workspace roles, and workspace visibility combine to control what each person can see and do in Ravenna.

Two things decide what someone can do in Ravenna:

1. Their <Tooltip headline="Organization role" tip="A baseline role across the entire company account." cta="Learn about organizations" href="/documentation/platform/organizations/overview">organization role</Tooltip>, which is their baseline across the whole company.
2. Their access to each <Tooltip headline="Workspace" tip="A dedicated space for one team or department." cta="Learn about workspaces" href="/documentation/platform/workspaces/overview">workspace</Tooltip>, which controls what they can do inside a specific team's space.

Access to any given workspace is the combination of the two.

## Mental model

Access is the combination of two independent layers, both using the same three role names but with different meaning:

1. **Organization role** (`OrganizationMember.role`): the baseline across the whole account. Values: Admin, Member, Guest.
2. **Workspace access**: what you can do inside one workspace. Only Admin and Member are assignable. A third state, requester access, applies to organization admins and members in a public workspace they have no explicit membership in.

You must be an organization member before you can be a workspace member. Workspace membership always sits on top of organization membership.

The Admin at `app.ravenna.ai` adapts to your access **for the workspace you are viewing**. In a workspace where you are an admin or member, you see Admin (the queue). In a public workspace you have only requester access to, you see the Portal (self-service). The same user can move between the two surfaces in one session as they switch workspaces. Organization guests only ever see the Portal. See [Portal](/documentation/platform/portal).

***

## Organization roles

| Role       | Public workspace                      | Private workspace                 | Org settings | Member management |
| ---------- | ------------------------------------- | --------------------------------- | ------------ | ----------------- |
| **Admin**  | Requester access (automatic)          | Only if added as workspace member | Full         | Full              |
| **Member** | Requester access (automatic)          | Only if added as workspace member | None         | None              |
| **Guest**  | None unless added as workspace member | Only if added as workspace member | None         | None              |

New users on your company email domain default to Member. Users synced from an integration on a different domain default to Guest. Guests cannot see or sign in to the organization unless Guest visibility is enabled in organization settings.

***

## Workspace access tiers

There are three tiers, but only two are assignable.

| Tier                         | How you get it                                    | Portal    | See others' tickets | Create tickets | Edit properties / assign | Private notes | Copilot |  Settings |
| ---------------------------- | ------------------------------------------------- | --------- | :-----------------: | :------------: | :----------------------: | :-----------: | :-----: | :-------: |
| **Requester (not a member)** | Org Admin/Member in a public workspace, not added | Requester |    No (own only)    |       Yes      |            No            |       No      |    No   |     No    |
| **Member**                   | Explicitly added                                  | Agent     |         Yes         |       Yes      |            Yes           |      Yes      |   Yes   | View only |
| **Admin**                    | Explicitly added or promoted                      | Agent     |         Yes         |       Yes      |            Yes           |      Yes      |   Yes   |    Full   |

Key behaviors:

* **Requester access** is the default state for most of the organization in public workspaces. It permits filing and tracking your own tickets and public comments, nothing more. It does not permit editing ticket properties, self-assigning, private notes, moving/deleting, or Copilot.
* **Only workspace Admins** can add, remove, or change the roles of workspace members. Workspace Members cannot.
* The **Guest workspace role is deprecated** and can no longer be assigned. Only Admin and Member are selectable. Any remaining Guest rows are legacy data.
* New workspaces are **private by default** when created through the API without specifying visibility.
* **Editing any ticket field requires workspace admin or member** of that ticket's workspace. Org role alone, requester access, and guest never permit it, including self-assignment. This is the single rule behind the "Edit ..." rows in the matrix.
* **Portal view follows the tier per workspace**: in a workspace you are an admin or member of you see Admin; in a public workspace you only have requester access to you see the Portal (`/{workspace}/home`). The view is a rendering of your permissions, not the thing that grants them.

***

## Public vs private workspaces

Visibility controls the **queue** (who can browse the workspace and see other people's tickets), not the workspace's existence or the ability to file.

* **Public**: org Admins and Members get requester access automatically. Org Guests get nothing unless explicitly added.
* **Private**: only workspace members browse the queue or see other people's tickets, org admins included.

Requests still reach a private workspace through its intake surfaces (request channel, DM routing, email, forms, agent). The requester becomes the ticket requester and follows their own ticket, but does not join the workspace or see the rest of the queue.

**Private is not the same as hidden.** A private workspace with its **Portal** setting on still appears in the Portal, where any org user can submit a request to it and track their own tickets. Privacy hides the queue and other people's tickets, not the workspace itself. To hide a workspace from the portal entirely, turn its Portal setting off.

The boundary that restricts a queue is **workspace membership**: only members see other people's tickets in a workspace. For a single sensitive ticket inside a busy workspace, use a private ticket.

***

## Three layers of access, top to bottom

Ravenna has a third, ticket-scoped layer on top of the two above:

1. **Organization role**: baseline across the account.
2. **Workspace access**: what you can do inside a workspace.
3. **Ticket roles** (requester, assignee, follower, approver): control access to individual tickets, especially private ones.

For private tickets, workspace admins and members always retain access regardless of ticket roles. Everyone else needs a qualifying ticket role.

<Callout icon="link" color="#6B7280">
  Learn more about [ticket roles](/documentation/tickets/roles) and [private tickets](/documentation/tickets/private-tickets).
</Callout>

***

## Constraints and gotchas

* Organization membership is required before workspace membership. You cannot add someone to a workspace without first making them an organization member.
* The last organization admin and the last workspace admin cannot be removed.
* **Editing any ticket field (status, priority, assignee, tags, category, type, custom fields) requires being an admin or member of that ticket's workspace.** Org role alone, requester access, and guest do not permit it, including self-assignment. Even an organization admin cannot edit fields in a workspace they have not joined. To grant editing, add the person as a workspace member.
* Requester access (org admin or member, no workspace membership) permits creating tickets and public comments only.
* Only workspace Admins can manage workspace members. Members cannot add, remove, or re-role others.
* The workspace Guest role is deprecated and cannot be assigned. Existing Guest rows are legacy.
* A private workspace limits its queue to workspace members, but requests can still be routed in through its intake surfaces (channel, DM, email, form, agent). Filing a request is not the same as joining the workspace.
* **Private is not hidden.** Privacy scopes the queue, not the workspace's existence. A private workspace with its **Portal** setting on still appears in the Portal (see [Public vs private workspaces](#public-vs-private-workspaces) above). Turn that setting off to hide it entirely.
* Private tickets are visible to all workspace members. Use a private ticket to restrict a single ticket inside a workspace; use workspace membership to restrict a whole queue.
* Guest visibility must be enabled in organization settings before organization guests can see or sign in to the organization.