*** 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
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,
or in the portal?} Q3 -->|Guest| None(No access) Q4 -->|Public, or private
with portal on| Implicit(Requester access) Q4 -->|Private with
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 | **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. 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 agent portal: the queue, other people’s tickets, and everything you can edit. * In a public workspace you **don’t work in**, you see the requester portal: 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. | Full control over organization-wide configuration. **Capabilities:** * Manage organization settings, branding, and notification policies * Manage integrations and SSO * Invite, edit, and remove organization members * Reach every public workspace automatically * Reach a private workspace only when added as a workspace member Ravenna prevents removing the last organization admin so administrative access is never lost. 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 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 requester portal to submit and track their own requests * Interact with tickets where they are the requester, assignee, or follower Admins must enable **Guest visibility** in organization settings before guests can see or sign in to your organization or use the requester portal. Guest visibility is off by default. 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. *** 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. Private controls the **queue**, not the workspace’s existence or the ability to file. If a private workspace has its Customer Portal 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. 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. 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 Copilot * Open workspace settings This is the requester portal experience: for this team, the person sees the self-service home, not the agent workspace. To let someone triage and edit tickets in the workspace, add them as a workspace member. 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 private tickets * Edit ticket properties, assign tickets, and post private notes * Use Copilot * View workspace settings **Cannot:** * Change workspace settings * Add, remove, or change the roles of other workspace members * Delete the workspace Full control of the workspace. **Can:** * Do everything a workspace member can * Change workspace settings (SLAs, statuses, tags, and more) * Add, remove, and change the roles of workspace members * Delete the workspace Ravenna prevents removing the last workspace admin. *** 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. allowed not allowed | Capability | Org Guest | Requester access | Workspace Member | Workspace Admin | | ------------------------------------------------- | :----------------------------------: | :-----------------------------------: | :-----------------------------------------: | :------------------------------------------: | | **Organization** | | | | | | Manage organization settings | | | | | | Manage organization members | | | | | | **Workspace access** | | | | | | Reach a public workspace | | | | | | Reach a private workspace | | | | | | See other people’s tickets | | | | | | **Tickets** | | | | | | Create tickets | | | | | | Public comments | | | | | | Edit status | | | | | | Edit priority | | | | | | Edit assignee (assign to anyone) | | | | | | Assign a ticket to yourself | | | | | | Edit tags, category, type | | | | | | Edit custom fields | | | | | | Private notes | | | | | | Move or delete tickets | | | | | | Use Copilot | | | | | | **Workspace management** | | | | | | View workspace settings | | | | | | Change workspace settings | | | | | | Manage workspace members | | | | | | Delete workspace | | | | | | **Portal** | | | | | | Portal they land in | Requester (if Guest visibility on) | Requester | Agent | Agent | 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. 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. 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. *** Who can edit a ticket’s fields There is one rule for editing a ticket, and it is worth stating plainly: To edit **any** field on a ticket, you must be an **admin or member of that ticket’s workspace**. Nothing else grants it. 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. 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). *** 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 Slack request channel connected to the workspace * A direct message to the Ravenna app in Slack * An email address that belongs to the workspace * A form that belongs to the workspace * The AI agent, 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 requester portal, but they do not join the workspace or see the rest of its tickets. 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. *** Choosing the right access Assign the least-privileged access that still lets people do their jobs. 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. 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. 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. 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. 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. 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). *** Examples Common situations and the access that results. 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. 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. 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. Keep them as an organization **Guest** and enable Guest visibility. 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. 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.