> ## 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.

<View title="Human" icon="user">
  ***

  ## How access is decided

  Access to a workspace depends on whether you were added to it, your organization role, and, for a workspace you were not added to, whether it is reachable through the portal. Follow the questions from the top.

  ```mermaid theme={"system"}
  graph TD
      Q1{Added to this<br/>workspace?}
      Q1 -->|Yes| Q2{Which workspace role?}
      Q1 -->|No| Q3{Organization role?}

      Q2 -->|Admin| Admin(Workspace Admin)
      Q2 -->|Member| Member(Workspace Member)

      Q3 -->|Admin or Member| Q4{Workspace public,<br/>or in the portal?}
      Q3 -->|Guest| None(No access)

      Q4 -->|Public, or private<br/>with portal on| Implicit(Requester access)
      Q4 -->|Private with<br/>portal off| None

      classDef question fill:#E2EAEF,stroke:#165d6e,stroke-width:1px,color:#0f172a
      classDef full fill:#165d6e,stroke:#165d6e,color:#ffffff
      classDef partial fill:#269cbd,stroke:#269cbd,color:#ffffff
      classDef blocked fill:#F1F5F9,stroke:#94a3b8,color:#475569

      class Q1,Q2,Q3,Q4 question
      class Admin,Member full
      class Implicit partial
      class None blocked
  ```

  | Outcome                       | What it means                                                                                                                                                                    | Portal           |
  | ----------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------- |
  | **Workspace Admin or Member** | See and work on every ticket in the workspace: view, edit, assign, and resolve.                                                                                                  | Agent portal     |
  | **Requester access**          | Submit requests and follow your own tickets. Cannot see or edit other people's tickets. Applies to any public workspace, and to a private workspace whose customer portal is on. | Requester portal |
  | **No access**                 | Cannot reach the workspace or see anything in it. Applies to a private workspace whose customer portal is off.                                                                   | Not shown        |

  <Info>
    **Requester access** is a level of access, not a role you assign. It describes what an organization admin or member can do in a public workspace they have not been added to. The only roles you assign are Admin and Member, at the organization level and inside each workspace.
  </Info>

  The easiest way to picture requester access is the surface it puts you in. The web app adapts to your access for the workspace you are looking at:

  * In a workspace you **work in** (as a workspace admin or member), you see the full <Tooltip headline="Agent portal" tip="The full workspace for teams that triage and manage tickets." cta="Learn about the agent portal" href="/documentation/platform/portal/agents">agent portal</Tooltip>: the queue, other people's tickets, and everything you can edit.
  * In a public workspace you **don't work in**, you see the <Tooltip headline="Requester portal" tip="The self-service home for submitting and tracking your own requests." cta="Learn about the requester portal" href="/documentation/platform/portal/requesters">requester portal</Tooltip>: a self-service home to file and follow your own requests. That requester-portal experience *is* requester access.

  Because the view follows the workspace, one person can be in the agent portal for a team they work on and the requester portal for a team they don't, in the same session. Organization guests only ever see the requester portal.

  The rest of this page explains each part: organization roles, workspace access, and how the two combine.

  ***

  ## Organization roles

  An organization role is a person's baseline across the entire company account. Everyone has exactly one.

  | Role       | What it means                                                                                                                      |
  | ---------- | ---------------------------------------------------------------------------------------------------------------------------------- |
  | **Admin**  | Full control of the organization. Manages settings, integrations, SSO, and members. Automatically reaches public workspaces.       |
  | **Member** | A standard internal user (for example, an employee). Automatically reaches public workspaces. Cannot manage organization settings. |
  | **Guest**  | An external or limited user (for example, a contractor). No workspace access at all unless explicitly added to a workspace.        |

  <AccordionGroup>
    <Accordion title="Organization admins" icon="shield-check" defaultOpen>
      Full control over organization-wide configuration.

      **Capabilities:**

      * Manage <Tooltip headline="Organization settings" tip="Organization-wide policies and integrations." cta="View organization settings" href="/documentation/platform/organizations/settings">organization settings</Tooltip>, branding, and notification policies
      * Manage integrations and <Tooltip headline="SSO" tip="Single Sign-On through your corporate identity provider." cta="Learn about SSO" href="/integrations/sso/overview">SSO</Tooltip>
      * Invite, edit, and remove organization members
      * Reach every public workspace automatically
      * Reach a private workspace only when added as a workspace member

      <Warning>Ravenna prevents removing the last organization admin so administrative access is never lost.</Warning>
    </Accordion>

    <Accordion title="Organization members" icon="user">
      The default role for your internal team.

      **Capabilities:**

      * Reach every public workspace automatically (see [workspace access](#workspace-access) for what that access includes)
      * Reach a private workspace only when added as a workspace member
      * Create new workspaces, unless your admin restricts creation to admins
    </Accordion>

    <Accordion title="Organization guests" icon="user-round">
      A limited role for people outside your company, such as contractors or vendors.

      **Capabilities:**

      * No automatic workspace access, even to public workspaces
      * Reach a workspace only when explicitly added as a workspace member
      * Use the <Tooltip headline="Requester portal" tip="The self-service home for submitting and tracking your own requests." cta="Learn about the requester portal" href="/documentation/platform/portal/requesters">requester portal</Tooltip> to submit and track their own requests
      * Interact with tickets where they are the requester, assignee, or follower

      <Info>
        Admins must enable **Guest visibility** in <Tooltip headline="Organization settings" tip="Organization-wide policies." cta="View organization settings" href="/documentation/platform/organizations/settings">organization settings</Tooltip> before guests can see or sign in to your organization or use the requester portal. Guest visibility is off by default.
      </Info>
    </Accordion>
  </AccordionGroup>

  <Info>
    New users whose email matches your company domain become organization **Members** automatically. Users synced from an integration with a different email domain become organization **Guests** for security. You can change either afterward.
  </Info>

  ***

  ## Workspace access

  Every workspace is either **public** or **private**. What that setting controls is the **queue**: who can browse the workspace and see other people's tickets in it.

  * **Public**: anyone in your company can open the workspace and submit a request to that team, with requester access. Good for teams that serve everyone, such as IT or People Ops.
  * **Private**: only workspace members can browse the queue or see other people's tickets. Good for sensitive teams such as HR, Legal, or Security.

  <Warning>
    Private controls the **queue**, not the workspace's existence or the ability to file. If a private workspace has its <Tooltip headline="Customer Portal" tip="A workspace setting that lists the workspace in the requester portal and lets its agent answer portal chat." cta="Learn about the requester portal" href="/documentation/platform/portal/requesters">Customer Portal</Tooltip> setting (in **Workspace Settings > General**) turned on, it still appears in the [requester portal](/documentation/platform/portal/requesters), where anyone in your organization can submit a request to it and track their own tickets. What stays hidden is everyone else's tickets and the queue itself. To hide a workspace entirely, turn its Customer Portal setting off.
  </Warning>

  Within a workspace, access falls into one of three tiers. You assign two of them, **Admin** and **Member**. The third, **requester access**, is automatic for organization admins and members in any workspace they can reach but have not joined, and needs no setup.

  <AccordionGroup>
    <Accordion title="Requester access (not a workspace member)" icon="user-round" defaultOpen>
      Automatic for organization admins and members in any workspace they can reach but have not been added to: every public workspace, plus any private workspace whose customer portal is on. It covers submitting and following your own requests, not working the team's tickets.

      **Can:**

      * Create tickets in the workspace
      * Add public comments to tickets
      * See and track their own tickets (as requester, assignee, follower, or approver)
      * Approve or decline tickets when they are an approver

      **Cannot:**

      * See other people's tickets
      * Edit ticket properties such as status, priority, or assignee (including assigning a ticket to themselves)
      * Post private notes
      * Move or delete tickets
      * Use <Tooltip headline="Copilot" tip="The in-app AI assistant that helps you draft replies and work tickets." cta="Learn about Copilot" href="/documentation/automate/copilot/overview">Copilot</Tooltip>
      * Open workspace settings

      This is the <Tooltip headline="Requester portal" tip="The self-service home for submitting and tracking your own requests." cta="Learn about the requester portal" href="/documentation/platform/portal/requesters">requester portal</Tooltip> experience: for this team, the person sees the self-service home, not the agent workspace.

      <Info>To let someone triage and edit tickets in the workspace, add them as a workspace member.</Info>
    </Accordion>

    <Accordion title="Workspace member" icon="user">
      A member of the team that works this workspace. Add people here when they actively work tickets.

      **Can:**

      * See and work every ticket in the workspace, including <Tooltip headline="Private tickets" tip="Tickets whose visibility is restricted to specific people. Workspace members always retain access." cta="Learn about private tickets" href="/documentation/tickets/private-tickets">private tickets</Tooltip>
      * Edit ticket properties, assign tickets, and post <Tooltip headline="Private notes" tip="Internal comments on a ticket that the requester cannot see." cta="Learn about private notes" href="/documentation/tickets/private-notes">private notes</Tooltip>
      * Use <Tooltip headline="Copilot" tip="The in-app AI assistant that helps you draft replies and work tickets." cta="Learn about Copilot" href="/documentation/automate/copilot/overview">Copilot</Tooltip>
      * View workspace settings

      **Cannot:**

      * Change workspace settings
      * Add, remove, or change the roles of other workspace members
      * Delete the workspace
    </Accordion>

    <Accordion title="Workspace admin" icon="shield-check">
      Full control of the workspace.

      **Can:**

      * Do everything a workspace member can
      * Change <Tooltip headline="Workspace settings" tip="Workspace-specific policies and tools." cta="View workspace settings" href="/documentation/platform/workspaces/settings">workspace settings</Tooltip> (SLAs, statuses, tags, and more)
      * Add, remove, and change the roles of workspace members
      * Delete the workspace

      <Warning>Ravenna prevents removing the last workspace admin.</Warning>
    </Accordion>
  </AccordionGroup>

  ***

  ## Master capability matrix

  The columns combine both layers. "Org Guest" is the organization role. "Requester access" is an organization admin or member in a public workspace they have not been added to. "Workspace Member" and "Workspace Admin" are the two roles you assign inside a workspace.

  <Icon icon="check" color="#16a34a" /> allowed    <Icon icon="x" color="#dc2626" /> not allowed

  | Capability                                        | <Icon icon="user-round" /> Org Guest | <Icon icon="user" /> Requester access | <Icon icon="user-check" /> Workspace Member | <Icon icon="shield-check" /> Workspace Admin |
  | ------------------------------------------------- | :----------------------------------: | :-----------------------------------: | :-----------------------------------------: | :------------------------------------------: |
  | <Icon icon="building" /> **Organization**         |                                      |                                       |                                             |                                              |
  | Manage organization settings                      |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |      <Icon icon="x" color="#dc2626" />      |       <Icon icon="x" color="#dc2626" />      |
  | Manage organization members                       |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |      <Icon icon="x" color="#dc2626" />      |       <Icon icon="x" color="#dc2626" />      |
  | <Icon icon="briefcase" /> **Workspace access**    |                                      |                                       |                                             |                                              |
  | Reach a public workspace                          |   <Icon icon="x" color="#dc2626" />  | <Icon icon="check" color="#16a34a" /> |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Reach a private workspace                         |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | See other people's tickets                        |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | <Icon icon="ticket" /> **Tickets**                |                                      |                                       |                                             |                                              |
  | Create tickets                                    |   <Icon icon="x" color="#dc2626" />  | <Icon icon="check" color="#16a34a" /> |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Public comments                                   |   <Icon icon="x" color="#dc2626" />  | <Icon icon="check" color="#16a34a" /> |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Edit status                                       |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Edit priority                                     |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Edit assignee (assign to anyone)                  |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Assign a ticket to yourself                       |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Edit tags, category, type                         |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Edit custom fields                                |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Private notes                                     |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Move or delete tickets                            |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Use Copilot                                       |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | <Icon icon="settings" /> **Workspace management** |                                      |                                       |                                             |                                              |
  | View workspace settings                           |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |    <Icon icon="check" color="#16a34a" />    |     <Icon icon="check" color="#16a34a" />    |
  | Change workspace settings                         |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |      <Icon icon="x" color="#dc2626" />      |     <Icon icon="check" color="#16a34a" />    |
  | Manage workspace members                          |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |      <Icon icon="x" color="#dc2626" />      |     <Icon icon="check" color="#16a34a" />    |
  | Delete workspace                                  |   <Icon icon="x" color="#dc2626" />  |   <Icon icon="x" color="#dc2626" />   |      <Icon icon="x" color="#dc2626" />      |     <Icon icon="check" color="#16a34a" />    |
  | <Icon icon="panels-top-left" /> **Portal**        |                                      |                                       |                                             |                                              |
  | Portal they land in                               |  Requester (if Guest visibility on)  |               Requester               |                    Agent                    |                     Agent                    |

  <Info>
    Organization admins are not shown as a separate column because their org role does not by itself grant ticket or workspace-management powers inside a workspace. In a public workspace they have requester access; in any workspace, working tickets requires an explicit workspace membership. Reaching a private workspace always requires being added.
  </Info>

  <Info>
    The **portal** row shows the surface each tier signs in to. Workspace admins and members work the queue in the [agent portal](/documentation/platform/portal/agents). Everyone else uses the [requester portal](/documentation/platform/portal/requesters) to submit and track their own requests. Organization guests only reach the requester portal when an admin enables Guest visibility.
  </Info>

  <Note>
    A small number of workspaces may still show a legacy **Guest** workspace role from before it was retired. Guest can no longer be assigned to new members. If you see it, edit the member and switch them to Member or Admin.
  </Note>

  ***

  ## Who can edit a ticket's fields

  There is one rule for editing a ticket, and it is worth stating plainly:

  <Callout icon="pen" color="#165d6e">
    To edit **any** field on a ticket, you must be an **admin or member of that ticket's workspace**. Nothing else grants it.
  </Callout>

  This is deliberately strict. Editing a field means changing status, priority, assignee, tags, category, type, or any custom field, and it also covers assigning the ticket to yourself.

  * **Organization role does not grant it.** An organization admin has no ability to edit fields in a workspace they have not joined, even a public one. Their org role controls organization settings and members, not ticket fields.
  * **Requester access does not grant it.** Organization admins and members with requester access can create a ticket and add public comments, but they cannot change its fields, not even to assign it to themselves.
  * **Organization guests cannot edit fields.** They can only participate through the [ticket roles](/documentation/tickets/roles) they hold (requester, assignee, follower, approver).
  * **Workspace admins and members can edit every field** on any ticket in their workspace, including [private tickets](/documentation/tickets/private-tickets).

  The **Edit** rows in the [capability matrix](#master-capability-matrix) above show this rule field by field.

  <Info>
    The **Assignee options** workspace setting controls who can be *picked* from the assignee list, not who is allowed to assign. Even if that setting is set to "Organization members," a person still needs workspace membership to change the assignee. See [workspace settings](/documentation/platform/workspaces/settings).
  </Info>

  ***

  ## How requests reach a workspace

  People rarely submit a request by opening a workspace and clicking **New ticket**. They use whichever surface is most convenient, and Ravenna routes the request to the right team for them. This works even for a private workspace they cannot open themselves:

  * A <Tooltip headline="Request channel" tip="A Slack channel connected to a workspace, where messages become tickets." cta="Learn about channels" href="/documentation/tickets/channels">Slack request channel</Tooltip> connected to the workspace
  * A <Tooltip headline="Direct message" tip="A direct message to the Ravenna app in Slack, routed to the best-fit team." cta="View organization settings" href="/documentation/platform/organizations/settings">direct message</Tooltip> to the Ravenna app in Slack
  * An email address that belongs to the workspace
  * A <Tooltip headline="Form" tip="A structured request form that collects the right details for a request type." cta="Learn about forms" href="/documentation/tickets/forms/overview">form</Tooltip> that belongs to the workspace
  * The <Tooltip headline="AI agent" tip="Reads an incoming request and routes it to the best-fit team." cta="Learn about agents" href="/documentation/automate/agents/overview">AI agent</Tooltip>, which reads the request and sends it to the best-fit team

  The person who submits becomes the ticket's requester and can follow their own ticket in the <Tooltip headline="Requester portal" tip="The self-service home where people submit and track their own requests." cta="Learn about the requester portal" href="/documentation/platform/portal/requesters">requester portal</Tooltip>, but they do not join the workspace or see the rest of its tickets.

  <Info>
    What keeps a team's tickets restricted is **workspace membership**: only members see other people's tickets in a workspace. To restrict a single sensitive ticket inside an otherwise busy workspace, use a [private ticket](/documentation/tickets/private-tickets), which limits that ticket to its requester, assignee, followers, approvers, and the workspace's members and admins.
  </Info>

  ***

  ## Choosing the right access

  Assign the least-privileged access that still lets people do their jobs.

  <Steps>
    <Step title="Keep internal employees as organization Members">
      Members automatically reach public workspaces and can file requests everywhere. You do not need to add everyone to every workspace just so they can open tickets.
    </Step>

    <Step title="Add only the team that works a queue as workspace Members or Admins">
      Add people to a workspace when they need to triage, edit, assign, or resolve tickets in it. Make the people who configure the workspace Admins, and the rest Members.
    </Step>

    <Step title="Use organization Guest for external people">
      For contractors or vendors on a different email domain, keep them as organization Guests and enable Guest visibility. They can file and track their own tickets without gaining access to your teams' queues.
    </Step>

    <Step title="Use a private workspace for sensitive teams">
      When only one team should work a queue, make the workspace private and add only that team. People outside the team can still submit requests to it through Slack, email, or a form.
    </Step>
  </Steps>

  <Info>
    You do not need to add people as workspace members just to let them file tickets. Requester access already covers filing and tracking their own requests in public workspaces. Reserve workspace membership for people who work the queue.
  </Info>

  <Callout icon="link" color="#6B7280">
    Manage people where they live: [organization members and delegates](/documentation/platform/organizations/overview#managing-organization-members) and [adding people to a workspace](/documentation/platform/workspaces/overview#add-someone-to-a-workspace). See also the [agent and requester portals](/documentation/platform/portal/overview).
  </Callout>

  ***

  ## Examples

  Common situations and the access that results.

  <AccordionGroup>
    <Accordion title="An employee files an IT request but is not on the IT team" icon="ticket" defaultOpen>
      Your IT workspace is **public**. An employee is an organization **Member** but was never added to the IT workspace.

      They have **requester access**: they can open a ticket in the IT workspace and follow their own request, but they cannot see anyone else's tickets, change a ticket's status, or assign it. When they sign in, they land in the [requester portal](/documentation/platform/portal/requesters), not the agent workspace.
    </Accordion>

    <Accordion title="You want only the HR team to work HR tickets" icon="lock">
      Make the HR workspace **private** and add only the HR team as workspace members. The queue is then limited to those members. Anyone else, including organization admins who have not been added, cannot browse or work its tickets.

      Employees can still submit HR requests through email, a Slack request channel, a form, or the agent. Their request lands in the workspace, and they can follow their own ticket, without seeing the rest of the team's tickets.

      <Warning>Making the workspace private does not hide it from the requester portal. If HR's **Customer Portal** setting (in **Workspace Settings > General**) is on, the HR workspace still shows up as a place people can submit requests, they just cannot see the queue. To hide HR entirely, turn its Customer Portal setting off.</Warning>
    </Accordion>

    <Accordion title="A contractor on a different email domain needs to file tickets" icon="user-round">
      Keep them as an organization **Guest** and enable <Tooltip headline="Guest visibility" tip="Lets organization guests see and sign in to your organization. Off by default." cta="View organization settings" href="/documentation/platform/organizations/settings">Guest visibility</Tooltip>. They sign in to the [requester portal](/documentation/platform/portal/requesters), where they file and track their own requests without gaining access to any team's queue.

      You do not need to add them to a workspace unless they will actively work tickets there.
    </Accordion>

    <Accordion title="A new hire should triage tickets in the IT workspace" icon="user-plus">
      Add them to the IT workspace as a **Member**. Members work the whole queue: they see every ticket, edit properties, assign, post private notes, and use Copilot. Make them an **Admin** instead only if they also need to change workspace settings or manage the workspace's members.
    </Accordion>
  </AccordionGroup>
</View>

<View title="Agent" icon="bot">
  ## 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 web app 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 the agent portal (the queue). In a public workspace you have only requester access to, you see the requester 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 requester portal. See [Portal](/documentation/platform/portal/overview).

  ***

  ## 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 the agent portal; in a public workspace you only have requester access to you see the requester 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 **Customer Portal** setting on still appears in the requester 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 Customer 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 **Customer Portal** setting on still appears in the requester 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.
</View>