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

# Portal and privacy

> Private is not hidden. How workspace privacy, the Portal and Slack visibility toggles, guest access, and private tickets actually interact.

export const Checkbox = ({items = []}) => {
  const [checked, setChecked] = useState(Array(items.length).fill(false));
  const toggle = index => {
    setChecked(prev => {
      const copy = [...prev];
      copy[index] = !copy[index];
      return copy;
    });
  };
  return <div className="custom-checkbox-list">
      {items.map((text, index) => <div key={index} className="custom-checkbox-item flex items-center mb-2">
          <input type="checkbox" checked={checked[index]} onChange={() => toggle(index)} className="mr-2" />
          <span>{text}</span>
        </div>)}
    </div>;
};

The single most misread setting in Ravenna is workspace privacy. Teams make the HR workspace private, assume it is now invisible, and are surprised to find it listed in the Portal as a place anyone in the organization can file a request.

That behavior is correct and useful. It is just not what "private" sounds like.

## The two things people confuse

There are two independent axes, and neither one implies the other.

| Axis           | Setting                                                                        | What it controls                                                      |
| -------------- | ------------------------------------------------------------------------------ | --------------------------------------------------------------------- |
| **Privacy**    | **Private workspace**, in **Workspace Settings** > **General**                 | Who can browse the workspace and see **other people's** tickets in it |
| **Visibility** | **Available in Slack** and **Available in Portal**, in the **Visibility** card | Which surfaces people can **file** a request through                  |

Privacy scopes the shared ticket list. Visibility scopes the front doors. Turning one off does not turn the other off.

## Private is not hidden

A private workspace with **Available in Portal** on still appears in the Portal. Anyone in your organization can select it, submit a request, and track their own ticket. What they cannot do is see the workspace's ticket list or anyone else's tickets.

That is the intended design. It is how a sensitive team stays reachable without being readable.

<Warning>
  To actually hide a workspace from everyone who is not a member, you need both: **Private workspace** on **and Available in Portal** off. Setting only the first leaves the workspace listed as a filing destination.
</Warning>

Two consequences worth internalizing:

* **Filing is not joining.** A requester who submits to a private workspace becomes the ticket's requester and follows that one ticket. They do not gain access to anything else.
* **Organization admin is not workspace access.** Reaching a private workspace always requires being added as a member, org admins included.

<Callout icon="link" color="#6B7280">Learn more about [public vs private workspaces](/documentation/platform/roles-access#public-vs-private-workspaces)</Callout>

## Slack DM routing ignores both toggles

This is the other surprise.

<Warning>
  **Direct message routing follows agent presence, not visibility.** Any workspace with an agent connected to its Slack channel can receive DM conversations, whether or not **Available in Slack** and **Available in Portal** are on.
</Warning>

So if you turn both visibility toggles off expecting the workspace to stop receiving requests, and it has a connected agent, DMs keep arriving. Disconnect the agent, or accept the intake.

## The four gates on Portal visibility

Whether a given person sees a given workspace or form in the Portal is the AND of four settings at three different levels.

| Gate                     | Level        | Default | Controls                                                                                                 |
| ------------------------ | ------------ | ------- | -------------------------------------------------------------------------------------------------------- |
| **Guest Member Access**  | Organization | Off     | Whether guests can reach the organization and its Portal at all                                          |
| **Ravenna AI in Portal** | Organization | Off     | Whether Portal chat answers platform questions about the requester's own data instead of filing a ticket |
| **Available in Portal**  | Workspace    | Off     | Whether the workspace is a filing destination and its agent answers Portal chat                          |
| **Feature in Portal**    | Form         | Off     | Whether the form appears on the **Start new request** tab                                                |

Form audience settings apply on top of all of it. Only published forms whose audience includes the requester appear, and private folders stay hidden.

If a requester says "I cannot see the form", walk the list top down. It is almost always the form's audience or its published state, not the workspace.

<Callout icon="link" color="#6B7280">Learn more about [what gates visibility](/documentation/platform/portal#what-gates-visibility)</Callout>

## Use private tickets for one sensitive request

Workspace privacy is the wrong tool for a single sensitive item, because it is all or nothing. A **private ticket** restricts one ticket inside an otherwise busy workspace to its requester, assignee, followers, approvers, and the workspace's members and admins.

Note the last part carefully: **every workspace member can see every private ticket in their workspace.** Private tickets hide a ticket from the wider organization, not from your team. A grievance about a colleague who happens to be an IT workspace member is not protected by a private ticket in the IT workspace. It needs a private workspace with a restricted membership.

<Callout icon="link" color="#6B7280">Learn more about [private tickets](/documentation/tickets/private-tickets) and [private notes](/documentation/tickets/private-notes)</Callout>

## Decide it once, with this table

| You want                                                      | Private workspace | Available in Portal | Membership            |
| ------------------------------------------------------------- | ----------------- | ------------------- | --------------------- |
| An open IT desk anyone can browse                             | Off               | On                  | Whoever works tickets |
| A reachable but unreadable HR desk                            | On                | On                  | HR team only          |
| An internal security workspace nobody outside it knows exists | On                | Off                 | Security team only    |
| A team workspace that only takes Slack requests               | On                | Off, Slack on       | That team             |

The second row is the one most teams actually want and the one most teams get wrong by leaving it at the third.

## Before you turn the Portal on anywhere

<Checkbox
  items={[
"You know whether each workspace should be private, and you have set it deliberately rather than accepted the default",
"For every private workspace, you have decided consciously whether Available in Portal is on or off",
"You have used View as Guest on the Portal home to confirm what a non-member actually sees",
"You have checked which agents are connected to Slack channels, since those keep taking DMs regardless",
"Guest Member Access is on only if you genuinely have external requesters",
"Sensitive forms have an audience set, not just a private folder"
]}
/>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="Assuming private means hidden">
    It means unreadable. Turn off **Available in Portal** to hide.
  </Accordion>

  <Accordion title="Turning off visibility to stop intake">
    DM routing follows agent presence, so a connected agent keeps the door open.
  </Accordion>

  <Accordion title="Using a private ticket to hide something from teammates">
    Every workspace member sees it.
  </Accordion>

  <Accordion title="Never previewing as a guest">
    Admins see workspaces and forms that requesters do not, so the Portal you tested is not the Portal they get.
  </Accordion>

  <Accordion title="Enabling Guest Member Access with no external requesters">
    It grants organization visibility you did not need to grant.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Launch the Portal" icon="globe" href="/guides/playbooks/launch-the-portal" horizontal>
    The full Portal setup, once you have decided the privacy model.
  </Card>

  <Card title="HR and People desk" icon="users" href="/guides/playbooks/hr/people-desk" horizontal>
    The private-by-default workspace built end to end.
  </Card>
</CardGroup>


## Related topics

- [Launch the Portal](/guides/playbooks/launch-the-portal.md)
- [HR and People desk](/guides/playbooks/hr/people-desk.md)
- [HR and People](/guides/playbooks/hr/overview.md)
- [Guides](/guides/overview.md)
- [Legal](/guides/playbooks/legal/overview.md)