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

# Launch the Portal

> Turn on the Ravenna Portal for staff who do not live in Slack: enable it per workspace, brand it, connect an agent, feature forms, and open guest access.

The Portal is Ravenna's web front door. It exists for the people your Slack channel does not reach: contractors, frontline and shift workers, staff in other teams, and anyone who does not have a Slack account.

<Info icon="list-check">
  **Prerequisites:** a workspace with at least one published form and a published agent. Read [Portal and privacy](/guides/best-practices/portal-and-privacy) before you enable anything, because turning the Portal on changes who can see a workspace.
</Info>

## Who actually lands in the Portal

The Portal is for people who are not workspace members:

* **Organization guests**, who submit and follow their own requests
* **Members of other teams** in your organization who have not joined this workspace, so they get a front door instead of a dead end

Organization admins and workspace members skip it entirely and go to the main app. There is no separate guest login. Everyone signs in through your normal organization login and SSO.

<Steps>
  <Step title="Turn it on for one workspace">
    Go to **Workspace Settings** > **General**, find the **Visibility** card, and turn on **Available in Portal**. It is off by default. That does two things: it lists the workspace as an option when requesters file from the Portal, and it lets that workspace's agent answer Portal chat.

    <Warning>
      This is the step to think about. Enabling the Portal makes the workspace visible to every member of your organization, whether or not the workspace itself is private. Ticket visibility does not change, but presence does. See [Portal and privacy](/guides/best-practices/portal-and-privacy).
    </Warning>
  </Step>

  <Step title="Brand it so people trust it">
    Organization admins style the Portal in **Organization Settings** > **Portal**. Changes save as you edit.

    * **Primary color** and an optional gradient banner
    * A **welcome message**, up to 120 characters, used as the greeting
    * Your **organization logo** and a **cover image**
    * Up to six **suggested questions**, each with an icon, color, a label up to 80 characters, and an optional prompt up to 500 characters that steers the agent. Drag to reorder.

    Suggested questions are worth real effort. They are the only instruction most people will read, and they set expectations for what the Portal can do. Use the five questions your team is actually asked, phrased the way employees phrase them.
  </Step>

  <Step title="Connect an agent">
    Portal chat needs a published agent connected to it. Without one, requesters are limited to forms, which works but wastes the best part of the Portal.

    When a Portal conversation is routed to an agent, that agent shows as the **Working on it** owner on the resulting ticket until it is published to a human channel.

    <Callout icon="link" color="#6B7280">Learn more about [Portal chat](/documentation/platform/portal#chat-with-the-ai-agent)</Callout>
  </Step>

  <Step title="Decide on Ravenna AI in Portal">
    **Ravenna AI in Portal**, in **Organization Settings** > **Portal**, lets Portal chat answer platform questions about a requester's own tickets and approvals without creating a ticket. Questions like "what is the status of my laptop request" get answered directly instead of generating another ticket for your team to close.

    It is off by default and applies to every workspace with the Portal on. Turn it on. It removes a category of ticket that has no value to anyone.

    Real support requests still route to the workspace's agent.
  </Step>

  <Step title="Feature the right forms">
    Open a form and enable **Feature in Portal** to put it on the **Start new request** tab. Non-featured forms still appear in the full catalog if the requester has access.

    Feature four to six, no more. The Portal home is a menu, and a menu with thirty items is a search box with extra steps.

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

    <Callout icon="link" color="#6B7280">Learn more about [form audience settings](/documentation/tickets/forms/overview#audience-settings)</Callout>
  </Step>

  <Step title="Preview as a guest before you tell anyone">
    Workspace admins can toggle **View as Guest** on the Portal home and forms pages to see exactly what a non-admin requester sees, without changing their own role.

    Do this before launch. Admins see forms and workspaces that guests do not, so the Portal you have been admiring is not the Portal your users get.
  </Step>

  <Step title="Open guest access, if you need it">
    Organization guests cannot see your organization at all by default. To change that, go to **Organization Settings** > **General** and turn on **Guest Member Access**.

    Guests can then view the organization, see their own tickets, submit requests, and send public messages. They cannot edit ticket properties or reach workspace settings.

    Only do this if you actually have external requesters. Contractors and vendors are the usual reason.

    <Callout icon="link" color="#6B7280">Learn more about [guest access](/documentation/platform/portal#guest-access) and [roles and access](/documentation/platform/roles-access)</Callout>
  </Step>

  <Step title="Give people the link">
    The Portal only works if people can find it. Put the link where they already are:

    * Your intranet or company homepage
    * An Okta or identity provider dashboard tile
    * Email signatures and footers for the IT and People teams
    * Onboarding documentation for new joiners

    <Callout icon="link" color="#6B7280">Learn more about [deep linking](/guides/best-practices/driving-adoption/deep-linking) and adding an [Okta bookmark](/guides/best-practices/driving-adoption/okta/bookmark)</Callout>
  </Step>
</Steps>

## Where teams get this wrong

<AccordionGroup>
  <Accordion title="Enabling the Portal on a private workspace without reading the privacy semantics">
    Do that first.
  </Accordion>

  <Accordion title="Launching with no agent connected">
    Forms alone make the Portal feel like a 2015 ticketing system.
  </Accordion>

  <Accordion title="Featuring every form">
    Four to six, chosen by volume.
  </Accordion>

  <Accordion title="Never previewing as a guest">
    What you see as an admin is not what they see.
  </Accordion>

  <Accordion title="Leaving Ravenna AI in Portal off">
    Every "where is my request" ticket it prevents is pure saving.
  </Accordion>
</AccordionGroup>

## Next

<CardGroup cols={2}>
  <Card title="Portal and privacy" icon="shield" href="/guides/best-practices/portal-and-privacy" horizontal>
    What Portal exposure actually means for a private workspace.
  </Card>

  <Card title="Email support" icon="mail" href="/guides/playbooks/email-support" horizontal>
    The other front door for people outside Slack.
  </Card>
</CardGroup>


## Related topics

- [Portal and privacy](/guides/best-practices/portal-and-privacy.md)
- [HR and People desk](/guides/playbooks/hr/people-desk.md)
- [Email support](/guides/playbooks/email-support.md)
- [Set up your first channel](/guides/day-one/set-up-first-channel.md)
- [Playbooks](/guides/playbooks/overview.md)