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

# Design the portal's tabs and navigation

> Decide how many tabs a partner portal needs, what belongs on each, and how to hide, restrict, reorder and deep-link them.

> For anyone deciding what the portal's navigation should be before filling it with content.

Tabs are the only navigation a partner portal has, so they are the whole information architecture.
Get them right and a partner finds what they came for without reading.
Get them wrong and you end up with a home tab that is a wall, or nine tabs a partner scans every visit because none of them is obviously the one.
This guide covers the structure decision and every control a tab carries.

## What you'll achieve

A navigation a partner can use on their first visit: a small set of tabs named for what a partner wants rather than how your program is organised, each with the right visibility, and a home tab that leads with the next action.

## Before you start

<Steps>
  <Step title="Open an experience">
    Go to [Experience builder](https://app.introw.io/templates) and open one.
    Tabs run across the top of the builder; each one has a **...** menu.
  </Step>

  <Step title="Know your sections">
    Structure is easier once you know what can go on a page.
    See [Every section you can add to a portal](./every-portal-section).
  </Step>

  <Step title="Have segments defined, if you plan to restrict tabs">
    Restricting a tab needs an audience to restrict it to.
    See [Create a dynamic segment](/features/partners/segments/guides/create-a-dynamic-segment).
  </Step>
</Steps>

## Steps

### Decide the structure

<Steps>
  <Step title="Start from four or five tabs, not nine">
    A partner visits with one of a handful of jobs: register something, find content, check what they have earned, learn something, see where a deal stands.
    Most programs land on **Home**, **Deals**, **Content**, **Training** and **Rewards** or their equivalents, and that is enough.
    Add the sixth tab only when a real job has nowhere to live.

    Tabs cost more than sections do.
    A crowded section is skimmed; a wrong tab is a dead end a partner has to back out of.
  </Step>

  <Step title="Name tabs for the partner's job">
    Name them for what a partner is trying to do, not for the Introw feature behind them or your internal team structure.
    **Register a deal** beats **Forms**. **Get paid** beats **Commissions**. **Sell with us** beats **Enablement**.
    A partner has never read your org chart and will not guess which internal word maps to their task.
  </Step>

  <Step title="Make the home tab answer 'what now'">
    The home tab is the only page you can be sure a partner sees.
    Lead with the single next action for the partner in front of you, then their status, then everything else.
    In practice that means a hero or a call to action at the top, their tasks and goals under it, and announcements below that.
    Everything else earns its way onto another tab.
  </Step>

  <Step title="Use one portal with restricted tabs before you build two portals">
    Two partner types rarely need two portals.
    They usually need the same portal with one or two tabs each cannot see, which is one experience to maintain rather than two that drift.
    Build a second experience only when the difference is most of the portal.
    See [Restrict a tab to segments](/features/portal/portal-access/guides/restrict-a-tab-to-segments).
  </Step>
</Steps>

### Work the controls on a tab

<Steps>
  <Step title="Reorder by dragging">
    Drag a tab along the bar to move it.
    Order is the strongest signal in the whole portal, because partners read left to right and stop early, so put the tab you want used second from the left rather than last.
  </Step>

  <Step title="Rename, duplicate and remove">
    The tab's **...** menu carries **Rename**, **Duplicate** and **Remove**.

    **Duplicate** is the fast way to build a variant: copy the tab, then restrict each copy to a different segment.
    **Remove** is greyed out on the last remaining tab, since an experience needs one.

    Treat **Remove** carefully.
    On the next publish, a removed tab disappears from every partner's portal along with the documents on it.
    See [Draft, published and preview](./draft-publish-and-preview).
  </Step>

  <Step title="Choose between hiding and restricting">
    Both take a tab away from partners, and they are for different things.

    * **Hide in shared view** hides it from every partner, while your team still sees it flagged in the builder. This is the one for a tab you are still building, or one you keep for internal reference.
    * **Manage access** sets the tab's access policy to **Anyone** or **Restricted**, and a restricted tab needs one or more **Required segments**. This is the one for a tab only some partners should see.

    A partner in any of the chosen segments sees the tab, and belonging to a narrower segment as well never takes it away: visibility resolves to the most permissive segment a partner is in.
    That is what makes layered segments work rather than fight each other.
  </Step>

  <Step title="Set the layout to match the content">
    **Layout** offers three widths, and the right one follows what is on the page.

    * **Centered** for reading. Text, announcements, an introduction.
    * **Expanded** for a mix of copy and data.
    * **Full width** for tables and dashboards, where a centred column wastes half the screen. A pipeline or an embedded dashboard almost always wants this.

    **Background color** sets a colour behind the tab, with a clear option to return to the default.
    Use it sparingly: one tinted tab reads as deliberate, five read as a theme nobody chose.
  </Step>

  <Step title="Link straight to a tab">
    A portal URL takes a tab in a `stage` query parameter, so `https://your-portal-domain/?stage={tabId}` opens the portal on that tab.
    Use it from a marketing email or an intranet page.
    Inside the portal, a call-to-action button does the same with **Go to tab**, and can also open a form or an asset directly, which is how the home tab hands a partner off without them hunting for the right tab.
  </Step>
</Steps>

## Verify it worked

Preview the experience as a real partner and check the navigation alone, before the content: are the tabs in the order you meant, does a restricted tab appear only for a partner in that segment, and is the tab you most want used within the first two positions.

If a tab shows a broken-restriction warning, the segment it pointed at was deleted.
Pick a live segment or set the tab back to **Anyone**, because a restriction pointing at nothing is not a safe default to leave in place.

## Related

<CardGroup cols={2}>
  <Card title="Every section you can add to a portal" icon="table-cells" href="./every-portal-section">
    What goes on each tab.
  </Card>

  <Card title="Restrict a tab to segments" icon="lock" href="/features/portal/portal-access/guides/restrict-a-tab-to-segments">
    Segment-gated navigation in detail.
  </Card>

  <Card title="Layer segments to progressively unlock" icon="layer-group" href="/features/partners/segments/guides/layer-segments-to-progressively-unlock">
    How overlapping segments resolve.
  </Card>

  <Card title="Implementation reference" icon="screwdriver-wrench" href="../technical">
    Full configuration options.
  </Card>
</CardGroup>