Skip to main content
Two things decide what someone can do in Ravenna:
  1. Their , which is their baseline across the whole company.
  2. Their access to each , which controls what they can do inside a specific team’s space.
Access to any given workspace is the combination of the two.

​
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.
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 Admin 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 : the queue, other people’s tickets, and everything you can edit.
  • In a public workspace you don’t work in, you see the : a self-service home to file and follow your own requests. That Portal experience is requester access.
Because the view follows the workspace, one person can be in the Admin for a team they work on and the Portal for a team they don’t, in the same session. Organization guests only ever see the 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.

Organization admins

Full control over organization-wide configuration.Capabilities:
  • Manage , branding, and notification policies
  • Manage integrations and
  • 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 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 to submit and track their own requests
  • Interact with tickets where they are the requester, assignee, or follower
Admins must enable Guest visibility in before guests can see or sign in to your organization or use the 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 setting (in Workspace Settings > General) turned on, it still appears in the Portal, 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 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.

Requester access (not a workspace member)

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 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
  • Open workspace settings
This is the 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
  • Edit ticket properties, assign tickets, and post
  • Use
  • 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 (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
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 Admin. Everyone else uses the Portal to submit and track their own requests. Organization guests only reach the 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 they hold (requester, assignee, follower, approver).
  • Workspace admins and members can edit every field on any ticket in their workspace, including private tickets.
The Edit rows in the 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.

​
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 connected to the workspace
  • A to the Ravenna app in Slack
  • An email address that belongs to the workspace
  • A that belongs to the workspace
  • The , 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 , 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, 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.
1

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

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

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

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.
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 and adding people to a workspace. See also the Admin and Portal.

​
Examples

Common situations and the access that results.

An employee files an IT request but is not on the IT team

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 Portal, 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 Portal. If HR’s 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 Portal setting off.
Keep them as an organization Guest and enable . They sign in to the Portal, 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.
Last modified on July 27, 2026