> ## Documentation Index
> Fetch the complete documentation index at: https://docs.introw.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Portal Access

> Control how partners sign in and what they see - login methods, SSO, invites, and segment-based visibility.

> Portal Access decides who gets into your partner portal and what they see once inside - flexible sign-in, invites, and segment-based visibility, all without engineering.

## What it does

Portal Access controls the front door to your partner program. You choose how partners log in,
whether that is an email magic link, social sign-in, or their own identity provider through
SSO, and you decide who can get in: invite specific people, or let anyone from a trusted
partner's email domain join automatically. Once partners are in, segment-based visibility lets
you show or hide portal tabs so each partner sees only what is relevant to them.

This keeps onboarding low-friction for partners while giving your team control. The right
people get access quickly, sensitive areas stay restricted, and large partner organizations can
self-serve access without you provisioning every user by hand.

## The problem it solves

Access that is either too open or too manual slows partner programs down:

* **Provisioning every partner by hand is slow** → Let anyone from a partner's email domain join automatically.
* **Partners want their own login** → Offer SSO so partners sign in with their identity provider.
* **Everyone sees everything** → Restrict portal tabs to specific segments.
* **Onboarding has too much friction** → Invite partners with a simple, low-friction sign-in.

## From problem to solution

Portal Access balances ease and control. Pick the login methods that suit partners, invite or
domain-allow the right people, and use segments to tailor what each partner sees. Partners get
in fast; your team keeps the program secure and relevant.

```mermaid theme={"theme":{"light":"github-light","dark":"github-dark"}}
flowchart LR
  login["Pick login methods"] --> invite["Invite or domain-allow"]
  invite --> scope["Segments tailor what each partner sees"]
```

## Use cases

<CardGroup cols={2}>
  <Card title="Flexible sign-in" icon="circle-check">
    Offer magic link, social login, or SSO.
  </Card>

  <Card title="Self-serve access" icon="circle-check">
    Let partners from a trusted domain join automatically.
  </Card>

  <Card title="Targeted visibility" icon="circle-check">
    Restrict tabs so partners see only what is relevant.
  </Card>

  <Card title="Controlled invites" icon="circle-check">
    Invite specific people to a partner portal.
  </Card>
</CardGroup>

## Impact

* **Low total cost of ownership** - Ops configures access and visibility with no engineering.
* **Work where you already are** - SSO lets partners sign in with the identity they already use.

## Who it's for

<CardGroup cols={2}>
  <Card title="Partner Operations" icon="user">
    Configures login, invites, and visibility.
  </Card>

  <Card title="VP Partnerships / CPO" icon="user">
    Wants secure, low-friction access for partners.
  </Card>
</CardGroup>

## Works with

{/* CONNECTS:START - generated content goes here */}

<CardGroup cols={2}>
  <Card title="Single Sign-On" icon="shield-halved" href="/features/access/sso">
    Single sign-on for partners.
  </Card>

  <Card title="Custom Domains" icon="browser" href="/features/portal/custom-domains">
    Access on your branded domain.
  </Card>
</CardGroup>

## Going deeper

<CardGroup cols={2}>
  <Card title="How to" icon="screwdriver-wrench" href="./technical">
    Setup, configuration, and all how-to guides.
  </Card>

  <Card title="API reference" icon="code" href="/general/introduction">
    Integration surface and code.
  </Card>
</CardGroup>