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

<View title="Human" icon="user">
  ## When to create a workspace

  Create a new workspace when a team or department needs its own support workflow. Common examples:

  | Team                       | Purpose                                                |
  | -------------------------- | ------------------------------------------------------ |
  | **IT Operations**          | Software access, equipment, account management         |
  | **People Operations / HR** | Benefits, onboarding, leave requests, policy questions |
  | **Finance**                | Expense reports, procurement, budget approvals         |
  | **Legal**                  | Contract reviews, compliance questions                 |
  | **Security**               | Incident reports, access reviews, policy exceptions    |
  | **RevOps / Sales Ops**     | CRM support, deal desk, tooling requests               |

  Each workspace operates independently, so teams can configure their own <Tooltip headline="Categories" tip="Organize tickets into meaningful groups for routing and reporting." cta="Learn about categories" href="/documentation/tickets/organize/categories">categories</Tooltip>, forms, <Tooltip headline="SLAs" tip="Service level agreements define response and resolution time targets." cta="Learn about SLAs" href="/documentation/automate/slas">SLAs</Tooltip>, and <Tooltip headline="Agent rules" tip="Configure AI agent behavior with natural language rules." cta="Learn about agents" href="/documentation/automate/agents/configure">agent rules</Tooltip> without affecting other teams.

  <Info>
    You do not need a separate workspace for every Slack channel or project. Workspaces are best suited for distinct teams with their own support processes. Use <Tooltip headline="Channels" tip="Channels connect Slack to your workspace for ticket routing." cta="Learn about channels" href="/documentation/tickets/channels">channels</Tooltip> within a workspace to organize tickets by topic or workflow.
  </Info>

  ## Create a workspace

  <Steps>
    <Step title="Open workspace switcher">
      Click the workspace name in the top-left corner of the Ravenna web portal.
    </Step>

    <Step title="Select create workspace">
      Click **Create workspace** at the bottom of the workspace list.
    </Step>

    <Step title="Name the workspace">
      Enter a clear, descriptive name that reflects the team or function (e.g., "IT Operations" or "People Ops").
    </Step>

    <Step title="Configure the workspace">
      Set up channels, forms, categories, and other settings to match your team's support process.
    </Step>
  </Steps>

  <Tip>
    Write a clear workspace description in **Workspace Settings > General**. The <Tooltip headline="AI Agent" tip="AI assistants that answer questions and automate actions." cta="Learn about agents" href="/documentation/automate/agents/overview">AI agent</Tooltip> uses this description to route requests to the correct workspace.
  </Tip>

  <Info>
    Organization admins can restrict workspace creation to admins only. If you do not see the option to create a workspace, contact your organization admin.
  </Info>

  ## Visibility

  Workspaces can be **public** or **private**. Toggle visibility in **Workspace Settings > General**.

  Visibility controls the **queue**: who can browse the workspace and see other people's tickets in it.

  * **Public**: organization admins and members reach the workspace automatically with requester access, which lets them file and track their own tickets. Working the queue (editing, assigning, private notes) requires being added as a workspace member.
  * **Private**: only workspace members can browse the queue or see other people's tickets. Private workspaces are useful for teams handling sensitive requests like HR or Security.

  <Warning>
    Private is not the same as hidden. If a private workspace has its **Customer Portal** setting (in **Workspace Settings > General**) on, it still appears in the [requester portal](/documentation/platform/portal/requesters), 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.
  </Warning>

  <Callout icon="link" color="#6B7280">
    Learn more about [roles and access](/documentation/platform/roles-access), including the three workspace access tiers.
  </Callout>

  ## Add someone to a workspace

  Add people to a workspace when they need to work its tickets. This is done by a workspace admin, and it is also the way to bring a brand-new person into your organization.

  <Steps>
    <Step title="Open workspace members">
      In the workspace, click the **Members** tab to see everyone in it.
    </Step>

    <Step title="Add a member">
      Click **+ Member**. Choose an existing organization member, or type an email address to add someone new. Adding a new email creates their organization membership at the same time.
    </Step>

    <Step title="Set the workspace role">
      Assign **Admin** or **Member**. The **Send invitation email** toggle is on by default. Turn it off to add someone without emailing them.
    </Step>

    <Step title="Edit a member">
      Click a member's row to open their details, then click **Edit** to change their role or remove them from the workspace.
    </Step>
  </Steps>

  <Info>
    You do not need to add people to a workspace just so they can submit requests. Anyone in your company can already file requests to a public workspace. Add someone as a member only when they need to work its tickets. See [roles and access](/documentation/platform/roles-access).
  </Info>

  <Note>
    The workspace **Guest** role is deprecated and can no longer be assigned. Only Admin and Member are selectable. If a workspace still shows a legacy Guest, edit that member and switch them to Member or Admin.
  </Note>

  ### Manage invitations

  When you add members, Ravenna sends invitation emails by default.

  * **Skip invitation emails**: turn off the **Send invitation email** toggle in the add member dialog. Useful when setting up a workspace before it is ready, or when onboarding in bulk.
  * **Resend in bulk**: select members in the table, then click **Resend invite** in the bulk action bar. Ravenna reports how many were sent and flags any failures.

  <Info>
    Bulk resend requires the admin role: workspace admins for workspace invitations, organization admins for organization invitations. Adding or removing a workspace member takes effect immediately.
  </Info>

  ## Switching workspaces

  Use the workspace switcher in the top-left corner to move between the workspaces you have access to. Ravenna remembers the last workspace you visited in each organization, so when you switch between organizations you return to where you left off instead of a default landing workspace.

  <Tip>
    If you belong to multiple organizations, opening Ravenna takes you back to the organization and workspace you used most recently. Switching organizations from the workspace switcher restores that organization's last workspace as well.
  </Tip>

  <Callout icon="link" color="#6B7280">
    Learn more about [workspace settings](/documentation/platform/workspaces/settings) for channels, SLAs, statuses, tags, and other configuration.
  </Callout>
</View>

<View title="Agent" icon="bot">
  ## 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 **Customer Portal** setting is on, it still appears in the requester 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 Customer 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.
</View>