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

# Draft, published and preview: what partners see right now

> Understand the three states of a portal experience, what publishing actually changes in every partner's portal, and how to check before partners see it.

> For anyone editing a live portal who needs to know what partners can see at this moment.

An experience has a state, and almost every surprise in the builder comes from not knowing which one you are in.
Edits save themselves as you type, so there is no moment where you decide to commit.
Partners are looking at the last thing you published, which may be days behind what is on your screen.
And publishing does more than push text: it rewrites tabs in portals partners already have.
This guide is the state model, so nothing you do in the builder reaches a partner before you meant it to.

## What you'll achieve

Confidence about three questions at any point: is what I am looking at live, what exactly will publishing change for the partners who already have this portal, and how do I see it the way a partner will before I commit.

## Before you start

<Steps>
  <Step title="Open an experience">
    Go to [Experience builder](https://app.introw.io/templates) and open one.
    The state indicator sits in the header, to the left of the **Preview** and **Publish** buttons.
  </Step>

  <Step title="Know that the portal has to be unlocked">
    Partners cannot reach any of this until the portal has a subdomain or a verified custom domain, whatever you publish.
    See [Connect a custom domain](/features/portal/custom-domains/guides/connect-a-custom-domain).
  </Step>
</Steps>

## Steps

### Read the state in the header

<Steps>
  <Step title="Check the dot and the label">
    The header carries a coloured dot with one of two words under it, plus when the experience was last saved.

    * **Published**, green. Everything you have edited has been pushed to partner portals. What you see is what they see.
    * **Draft**, orange. There are edits newer than your last publish. Partners are still on the previous version.

    The word to be careful with is **Draft**.
    It does not mean the experience has never gone live.
    A portal that a hundred partners use every day reads **Draft** the moment you change one heading, and it keeps reading **Draft** until you publish again.
  </Step>

  <Step title="Stop looking for a save button">
    There is not one.
    **Last saved** under the state label is the editor telling you your work is safe, not that partners have it.
    Saving and publishing are separate ideas in this builder: saving is automatic and continuous, publishing is deliberate and explicit.
  </Step>
</Steps>

### Understand what publishing actually does

<Steps>
  <Step title="Open Publish and read the selection">
    **Publish** opens **Apply your experience to your partners** with a partner picker.
    Every partner already on this experience is preselected and cannot be deselected, so the selection is not a choice about who gets the update.
    It is a choice about who gets **added**.

    That is the single most important thing to know about publishing.
    Every partner already using this experience is re-synced every time, so there is no way to publish for one partner and hold the rest back.
    Use a separate experience when two audiences genuinely need to move at different times.
  </Step>

  <Step title="Know what gets overwritten">
    Publishing copies the experience's tabs into every linked partner's portal, replacing what was there. For each tab it writes the content, the name, the layout, the background colour, the segment restrictions, whether it is hidden, and its position.

    Two consequences worth planning around:

    * **A tab you removed from the experience is removed from every partner's portal**, along with the documents on it. Removing a tab is not a layout tidy-up, it is a deletion with a delay.
    * **Anything edited directly on a single partner's portal is overwritten.** If you have been tuning one partner's portal by hand, the next publish of its experience puts it back to the shared version. Use a partner-specific asset or a segment-restricted tab for genuinely per-partner content instead. See [Restrict a tab to segments](/features/portal/portal-access/guides/restrict-a-tab-to-segments).
  </Step>

  <Step title="Know what else it sets running">
    Publishing is not only content.
    It creates a portal for any selected partner who does not have one yet, applies the journeys and goals attached to the experience's tabs, and generates affiliate links for any campaign block on it.
    That is why publishing to a new cohort is a real launch action rather than a save.
  </Step>

  <Step title="Choose whether partners are told">
    There are two ways out of the dialog, and they are not the same.

    * **Publish without email** applies everything silently. This is what you want for an edit to a live portal: partners get the new content next time they visit, with no message.
    * **Next**, then a **Personal message** you write and preview, then **Publish and notify**. This is a launch: the selected partners get an email pointing them at their portal.

    Publishing an edit with a notification is the mistake that gets noticed.
    Reserve the email for the partners who are new to the experience.
  </Step>

  <Step title="Expect the portal limit to bite here">
    The check counts only the partners you are adding, against the portals left on your plan.
    Over it, publishing is blocked with **Select fewer new partners or upgrade your plan to add more portals**.
    Existing partners never count, so an edit to a live experience is never blocked.
    See what your plan includes at [introw.io/pricing](https://introw.io/pricing).
  </Step>
</Steps>

### Check it before partners do

<Steps>
  <Step title="Preview as a specific partner">
    **Preview** lists the partners on this experience and opens the one you pick in a new tab.
    That is deliberately not a generic preview: it renders their portal with their pipeline, their tasks, their tier and their assets, which is the only way to catch a smart section that is empty for a real partner.

    Two things to know.
    Only partners who already have a portal appear, so a brand-new experience with nobody on it shows **No Partners Found** and there is nothing to preview yet.
    And preview shows their portal as it stands, which is your last publish, not the draft on your screen.
  </Step>

  <Step title="Publish to one partner first, then widen">
    Because preview reflects the published state, the honest way to check a change end to end is to make one partner your test: put a single internal or friendly partner on a copy of the experience, publish there, look at it, then publish the real one.
    See [Reuse an experience across partner types](./reuse-an-experience).
  </Step>

  <Step title="Roll back rather than repair">
    Every publish stores a snapshot of the whole experience, and **Version History** in the header's **...** menu lists them with who published each one.
    Restoring is a single click and does not need the partner list rebuilt.
    Reach for it before hand-editing your way back out of a bad publish.
    See [Restore a previous experience version](./restore-a-previous-experience-version).
  </Step>
</Steps>

## Verify it worked

The header reads **Published** in green, and previewing a real partner shows the change you made.
If the header says **Published** but a partner reports the old content, they are almost certainly on a different experience: check which one is assigned on their partner record rather than republishing.

One lag is expected and harmless.
The AI agent and portal search re-index a published tab in the background, so an answer sourced from brand-new tab content can trail the publish by a few minutes.

## Related

<CardGroup cols={2}>
  <Card title="Build and publish a portal experience" icon="pen-ruler" href="./build-and-publish-a-portal-experience">
    The build itself, end to end.
  </Card>

  <Card title="Restore a previous experience version" icon="clock-rotate-left" href="./restore-a-previous-experience-version">
    Roll back a publish you regret.
  </Card>

  <Card title="Launch the portal and the first two weeks" icon="rocket" href="/features/portal/portal-access/guides/launch-and-the-first-weeks">
    Going from published to partners actually using it.
  </Card>

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