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

# Requester portal

> The requester portal is a branded, self-service home where end users and guests open requests, chat with an AI agent, track tickets, and act on approvals and tasks.

The requester portal is the self-service home for people who need help but do not work tickets themselves. End users and <Tooltip headline="Organization guests" tip="Users with limited, workspace-scoped access" cta="Learn about guests" href="/documentation/platform/users/members">organization guests</Tooltip> use it to open requests, chat with an AI agent, track their tickets, and act on approvals and tasks, all from a branded page you control.

<Callout icon="link" color="#6B7280">
  Admins and workspace members who work tickets use the [agent portal](/documentation/platform/portal/agents) instead.
</Callout>

<View title="Human" icon="user">
  ***

  ## Who the requester portal is for

  The requester portal is built for people who are not workspace members:

  * **Organization guests** who submit and follow their own requests.
  * **Members of other teams** who belong to your organization but have not joined a given workspace. They land in the requester portal for that team instead of hitting a dead end.

  Organization admins and workspace members skip the requester portal and open the [agent portal](/documentation/platform/portal/agents) to manage tickets.

  ***

  ## Access and sign in

  Requesters sign in the same way as everyone else, through your organization's login and <Tooltip headline="SSO" tip="Single Sign-On through your corporate identity provider" cta="Learn about SSO" href="/integrations/sso/overview">SSO</Tooltip> provider. There is no separate guest login. After signing in, Ravenna sends requesters to the portal home rather than the agent workspace.

  <AccordionGroup>
    <Accordion title="Organization home" icon="house" defaultOpen>
      Requesters who can reach more than one team land on the organization home first. It lists the workspaces that have the portal turned on as cards, plus an organization-level AI chat when one is configured. Selecting a workspace opens that team's portal home.
    </Accordion>

    <Accordion title="Workspace home" icon="briefcase">
      Each team has its own portal home with that workspace's branding, forms, and AI agent. Requesters with access to a single team land here directly.
    </Accordion>
  </AccordionGroup>

  <Info>
    Organization guests can only reach the requester portal when an admin enables **Guest visibility**. See [Guest access](#guest-access).
  </Info>

  ***

  ## The portal home

  The portal home opens with a branded greeting, an AI chat box, and a set of tabs that gather everything a requester needs in one place.

  <AccordionGroup>
    <Accordion title="Start new request" icon="square-plus" defaultOpen>
      Shows the <Tooltip headline="Forms" tip="Structured intake forms with custom fields" cta="Learn about forms" href="/documentation/tickets/forms/overview">forms</Tooltip> featured for the portal, so requesters can jump straight into the most common requests. Requesters can also browse the full catalog of available forms.
    </Accordion>

    <Accordion title="Favorites" icon="star">
      Quick access to the forms a requester uses most, so repeat requests take one click.
    </Accordion>

    <Accordion title="My requests" icon="ticket">
      A list of the requester's recent tickets. Selecting a request opens its conversation so they can read replies and respond.
    </Accordion>

    <Accordion title="My approvals" icon="check">
      Pending <Tooltip headline="Approvals" tip="Rounds-based sign-off before work proceeds" cta="Learn about approvals" href="/documentation/tickets/approvals/overview">approvals</Tooltip> where the requester is an approver. They can approve or decline inline without leaving the portal.
    </Accordion>

    <Accordion title="Tasks" icon="list-checks">
      <Tooltip headline="Tasks" tip="Checklist items tracked on a ticket" cta="Learn about tasks" href="/documentation/tickets/tasks">Tasks</Tooltip> assigned to the requester. They can mark a task complete with an inline checkbox.
    </Accordion>
  </AccordionGroup>

  ***

  ## Chat with the AI agent

  When a workspace connects an <Tooltip headline="AI Agent" tip="Configurable AI responder that answers questions and triages requests" cta="Learn about agents" href="/documentation/automate/agents/overview">AI agent</Tooltip> to its portal, requesters can describe what they need in plain language from the chat box on the home page. The agent answers from your <Tooltip headline="Knowledge" tip="Connected sources that power AI responses" cta="Learn about knowledge" href="/documentation/automate/knowledge/overview">knowledge</Tooltip>, and when a request needs a ticket, it creates one and routes it to the right team.

  * **Suggested questions** give requesters a starting point. Admins configure these prompts as part of portal branding.
  * **Knowledge answers** resolve common questions without opening a ticket.
  * **Ticket creation** happens in the conversation when the agent determines a request needs human follow-up.

  <Info>
    Portal chat requires a connected agent. Without one, requesters submit requests through forms instead.
  </Info>

  <Callout icon="link" color="#6B7280">
    Learn how to configure the agent that powers portal chat in [Configure agents](/documentation/automate/agents/configure).
  </Callout>

  ***

  ## Submit a request with a form

  Forms turn a generic request into a structured ticket with the right fields and routing. Requesters reach forms two ways:

  <AccordionGroup>
    <Accordion title="Featured forms on the home page" icon="star" defaultOpen>
      The **Start new request** tab shows only the forms an admin has chosen to feature in the portal, keeping the most common requests front and center.
    </Accordion>

    <Accordion title="The full forms catalog" icon="folder-open">
      Requesters can browse every form available to them, organized into folders. Search narrows the list, and private folders stay hidden.
    </Accordion>
  </AccordionGroup>

  When a requester opens a form, they fill in its fields and submit. Ravenna creates the ticket, sets the requester as the person who submitted it, and shows a confirmation with a link to the new request.

  <Info>
    Forms can be shared as direct links that open straight to the form. Links can also prefill fields, so a request arrives with context already filled in.
  </Info>

  <Callout icon="link" color="#6B7280">
    Learn how to build and feature forms in [Forms](/documentation/tickets/forms/overview).
  </Callout>

  ***

  ## Track requests, approvals, and tasks

  The portal keeps requesters connected to their work after submission:

  * **Requests** open into the ticket conversation, where requesters read replies, add messages, and see attachments.
  * **Approvals** show inline approve and decline actions for any round where the requester is an approver.
  * **Tasks** assigned to the requester appear with a checkbox to mark them done.

  <Callout icon="link" color="#6B7280">
    Learn how ticket participation works in [Roles](/documentation/tickets/roles).
  </Callout>

  ***

  ## Notifications

  Requesters stay informed by email. Ravenna sends an update when a ticket is created, when a new message is posted, and when they are added as an approver. The portal itself does not have a separate notification inbox, so email is the primary channel for portal-only requesters.

  <Callout icon="link" color="#6B7280">
    Learn more about notification events in [Notifications](/documentation/platform/notifications).
  </Callout>

  ***

  ## Set up and customize the portal

  Setting up the requester portal takes two decisions: which workspaces appear in it, and how it looks.

  ### Turn on the portal for a workspace

  <Steps>
    <Step title="Open workspace settings">
      Go to **Settings > General** in the workspace you want to expose.
    </Step>

    <Step title="Enable the Customer Portal toggle">
      Turn on **Customer Portal** to let this workspace's agents respond to questions in the portal and to list the workspace on the organization home.
    </Step>
  </Steps>

  <Callout icon="link" color="#6B7280">
    Learn more about [workspace settings](/documentation/platform/workspaces/settings).
  </Callout>

  ### Brand the portal

  Organization admins style the portal in **Organization Settings > Portal**. Changes save automatically as you edit.

  <AccordionGroup>
    <Accordion title="Colors and banner" icon="palette" defaultOpen>
      Set a **primary color** that applies across the portal, and choose whether to show a **gradient banner** behind the greeting.
    </Accordion>

    <Accordion title="Welcome message" icon="message-square">
      Set a short **welcome message** (up to 120 characters) shown as the greeting headline.
    </Accordion>

    <Accordion title="Logo and cover image" icon="image">
      Choose whether to show your **organization logo**, and upload a **cover image** for the header (cropped to a wide banner ratio).
    </Accordion>

    <Accordion title="Suggested questions" icon="sparkles">
      Add up to six **suggested questions** that appear as starting points in the chat. Each has an icon, color, and label (up to 80 characters), plus an optional custom prompt (up to 500 characters) that steers the agent. Drag to reorder them.
    </Accordion>
  </AccordionGroup>

  ### Connect an agent

  For chat to work, connect a published <Tooltip headline="AI Agent" tip="Configurable AI responder that answers questions and triages requests" cta="Learn about agents" href="/documentation/automate/agents/overview">AI agent</Tooltip> to the portal. When no agent is connected, admins see a setup prompt to select one.

  ### Feature forms

  To surface a form on the **Start new request** tab, open the form and enable **Feature in customer portal**. Forms that are not featured still appear in the full catalog if the requester has access.

  <Callout icon="link" color="#6B7280">
    Learn how audience settings control who sees a form in [Forms](/documentation/tickets/forms/overview#audience-settings).
  </Callout>

  ### Preview as a guest

  Workspace admins can toggle **View as Guest** on the portal home and forms pages to see the portal exactly as a non-admin requester would, without changing their own role.

  ***

  ## Guest access

  By default, organization guests cannot see your organization at all. To let guests use the requester portal, an admin enables guest access.

  <Steps>
    <Step title="Open organization settings">
      Go to **Organization Settings > General**.
    </Step>

    <Step title="Enable Guest visibility">
      Turn on **Guest Member Access** so guests can view the organization, view their tickets, and submit new requests through the portal.
    </Step>
  </Steps>

  <Info>
    Guest visibility is off by default. Guests can create tickets and send public messages, but they cannot edit ticket properties or access workspace settings.
  </Info>

  <Callout icon="link" color="#6B7280">
    Learn more about guest permissions in [Members](/documentation/platform/users/members) and [Organization settings](/documentation/platform/organizations/settings).
  </Callout>
</View>

<View title="Agent" icon="bot">
  ## Mental model

  The requester portal is the self-service surface for users who are not workspace members. It shares one sign-in with the agent portal; a user's role decides which surface they land on.

  * **Organization admins and workspace members** open the agent portal.
  * **Organization guests and non-members** open the requester portal.

  The portal has two entry points:

  * **Organization home** (`/home`): lists portal-enabled workspaces plus an optional organization-level chat.
  * **Workspace home** (`/{workspace}/home`): the branded home for a single team, with chat and the Start new request, Favorites, My requests, My approvals, and Tasks tabs.

  Tickets created through the portal are recorded with a **Portal** source.

  ***

  ## What gates visibility

  Three independent settings control what a requester sees:

  | Setting                        | Level        | Controls                                                                                                    |
  | ------------------------------ | ------------ | ----------------------------------------------------------------------------------------------------------- |
  | **Guest visibility**           | Organization | Whether guests can access the organization and its portal at all. Off by default.                           |
  | **Customer Portal**            | Workspace    | Whether a workspace appears in the portal and its agent can answer portal chat.                             |
  | **Feature in customer portal** | Form         | Whether a form appears on the **Start new request** tab. Non-featured forms still show in the full catalog. |

  Form <Tooltip headline="Audience" tip="Everyone, Members only, or specific user groups" cta="Learn about audience" href="/documentation/tickets/forms/overview">audience</Tooltip> settings apply on top of this. Only published forms whose audience includes the requester appear, and private folders are hidden.

  ***

  ## Chat and ticket creation

  Portal chat is powered by a connected published agent. The agent answers from knowledge, and when a request needs a ticket, it creates one and routes it to the appropriate workspace. Without a connected agent, requesters rely on forms.

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

  <Callout icon="link" color="#6B7280">
    Learn how the **Working on it** owner behaves in [Roles](/documentation/tickets/roles#working-on-it-agent-owner).
  </Callout>

  ***

  ## Notifications

  Portal-only requesters are notified by email: on ticket creation, on new messages, and when added as an approver. There is no in-portal notification inbox.

  ***

  ## Constraints and gotchas

  * Guest visibility is off by default. Guests cannot reach the portal until an admin enables it.
  * A workspace only appears in the portal when its **Customer Portal** setting is on.
  * The **Start new request** tab shows only featured forms. Other accessible published forms appear in the full catalog.
  * Portal chat requires a connected published agent. Without one, only forms are available.
  * Requesters cannot edit ticket properties such as status, priority, or assignee. They create requests and add public messages.
  * The portal has no notification inbox. Updates reach requesters by email.
</View>