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

# Workspaces

> Workspaces are dedicated spaces for IT, HR, finance, or other teams to manage their own channels, tickets, forms, and workflows independently.

A workspace is a dedicated space within your <Tooltip headline="Organization" tip="Your top-level Ravenna account that contains all workspaces and members." cta="Learn about organizations" href="/documentation/platform/organizations/overview">organization</Tooltip> for a specific team or department to manage their support requests. Each workspace has its own <Tooltip headline="Channels" tip="Channels connect Slack to your workspace for ticket routing." cta="Learn about channels" href="/documentation/tickets/channels">channels</Tooltip>, tickets, <Tooltip headline="Forms" tip="Collect structured information with custom fields when creating tickets." cta="Learn about forms" href="/documentation/tickets/forms/overview">forms</Tooltip>, <Tooltip headline="Workflows" tip="Automate ticket routing, tagging, and actions." cta="Learn about workflows" href="/documentation/automate/workflows/overview">workflows</Tooltip>, and settings.

## Mental model

A workspace is the primary organizational boundary in Ravenna. Everything operational is workspace-scoped: channels, tickets, forms, workflows, SLAs, categories, tags, statuses, knowledge folders, agents, and task templates.

One organization contains many workspaces. Each workspace operates independently with its own configuration.

Key relationships:

* One organization has many workspaces.
* One workspace has many channels, forms, workflows, agents, and knowledge folders.
* Tickets belong to exactly one workspace (but can be moved between workspaces).
* Parent-child ticket relationships can cross workspace boundaries.
* Applications are organization-scoped but visible in specific workspaces.

***

## When to create vs not create a workspace

**Create a new workspace when:**

* A team needs its own forms, categories, SLAs, or agent rules that differ from other teams.
* The team handles a distinct type of support request (IT vs HR vs Finance).
* Access control requires separation (e.g., HR tickets should not be visible to IT team members).

**Do NOT create a new workspace for:**

* Different Slack channels within the same team. Use Ravenna channels within a workspace instead.
* Different ticket categories or tags. Use categories/tags within a workspace.
* Different projects. Use channels or tags within the same workspace.

A workspace is for a team, not for a topic. Use channels and tags within a workspace to organize topics.

***

## Workspace visibility

Visibility scopes the **queue** (who browses the workspace and sees other people's tickets), before roles decide what they can do inside it.

* **Public**: organization admins and members get requester access automatically. Requester access lets them file and track their own tickets, but not work the queue. Organization guests get no access unless explicitly added as workspace members.
* **Private**: only workspace members browse the queue or see other people's tickets, regardless of organization role, including organization admins. If the workspace's **Portal** setting is on, it still appears in the Portal, where any org user can submit to it and track their own tickets. Privacy scopes the queue, not the workspace's existence. Turn the Portal setting off to hide it entirely.

Private workspaces are appropriate for teams handling sensitive requests (HR, Security, Legal). For the full access model, see [Roles and access](/documentation/platform/roles-access).

***

## Workspace description for agent routing

The workspace description (set in Workspace Settings > General) is used by the AI agent to determine where to route requests. A clear, specific description helps the agent send tickets to the correct workspace.

Good description: "IT Operations handles software access requests, equipment provisioning, account management, VPN issues, and technical support for internal tools."

Poor description: "IT workspace."

***

## Constraints and gotchas

* Tickets belong to exactly one workspace but can be moved between workspaces (with caveats: new ticket ID, possible follower loss, assignee reassignment).
* Parent-child ticket relationships work across workspaces.
* Knowledge folders are workspace-scoped. There is no cross-workspace knowledge sharing.
* Task templates are workspace-scoped.
* SLAs are workspace-scoped.
* Applications are organization-scoped and can be surfaced in specific workspaces via form configuration.
* Organization admins can restrict workspace creation to admins only.
* Workspace admins and members always have access to private tickets within their workspace.
* Only workspace admins can add, remove, or re-role workspace members. The workspace **Guest** role is deprecated and cannot be assigned.
* Adding a new email through the add-member dialog creates the organization membership and the workspace membership together. A user cannot be a workspace member without first being an organization member.
* Workspace membership changes take effect immediately. When adding members, the `sendInvitation` flag defaults to `true`; set it to `false` to skip invitation emails.