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

# Reuse an experience across partner types and regions

> Duplicate an experience, keep shared content in one place with synced sections, and move a cohort of partners onto a new experience without rebuilding anything.

> For anyone who has one portal working and now needs a second, a third and a regional variant.

The first experience is the expensive one.
Every one after it should be a copy plus a difference, and the shared parts should stay shared rather than being pasted into each.
The trap is the opposite: four experiences that started identical, drifted for six months, and now nobody can say which one is right.
This guide covers the three tools that prevent it, and when each is the correct one.

## What you'll achieve

A second and third experience that cost a fraction of the first, with the content that must stay identical maintained in exactly one place, and a way to move a whole cohort onto a new experience without touching partners one at a time.

## Before you start

<Steps>
  <Step title="Have one experience you are happy with">
    Reuse works from a good original.
    If the first one is still in flux, settle it before you copy it, because a copy inherits the parts you have not fixed yet.
    See [Build and publish a portal experience](./build-and-publish-a-portal-experience).
  </Step>

  <Step title="Know how many portals your plan allows">
    Publishing a new experience to partners who have no portal yet consumes portals.
    Reusing content is free; giving more partners a portal is not.
    Check what your plan includes at [introw.io/pricing](https://introw.io/pricing).
  </Step>
</Steps>

## Steps

### Choose the right tool

<Steps>
  <Step title="Decide before you copy anything">
    Three different problems get solved three different ways, and picking the wrong one is what creates drift.

    | What you actually want                                            | Use                                     |
    | ----------------------------------------------------------------- | --------------------------------------- |
    | A second portal that starts from this one and then diverges       | **Duplicate the experience**            |
    | The same block of content in several experiences, maintained once | **A synced section**                    |
    | Two audiences on the same portal, seeing slightly different tabs  | **One experience with restricted tabs** |
    | A cohort moved from one experience to another                     | **A bulk experience update**            |

    The most common mistake is duplicating an experience when the difference is one tab.
    That buys you a second thing to maintain forever in exchange for a tab you could have restricted to a segment.
    Duplicate when most of the portal differs, not when a corner of it does.
  </Step>
</Steps>

### Duplicate an experience

<Steps>
  <Step title="Copy it from the list">
    Go to [Experience builder](https://app.introw.io/templates), find the experience in the list and use its copy action.
    You get a new experience named after the original with **(copy)** appended, carrying every tab in the same order with all of its content.
  </Step>

  <Step title="Know what the copy shares and what it does not">
    The copy is independent where it matters and still linked where you want it to be.

    * **CRM views and asset hub blocks are re-created for the copy**, so changing which fields a pipeline shows in one experience does not change the other. The two portals can genuinely diverge.
    * **Synced sections stay linked to the same saved section.** A duplicated synced section is still the same block, so editing it in either place updates both. That is deliberate and it is the mechanism that keeps two portals consistent.
    * **No partners come with the copy.** It starts unpublished with nobody on it, so nothing reaches a partner until you publish it.
  </Step>

  <Step title="Make the difference, then publish">
    Rename it for what it is, make the changes that justified the copy, then publish it to its partners.
    Publishing a copy to partners who already have a portal on the original moves them; publishing to partners with no portal creates one.
    See [Draft, published and preview](./draft-publish-and-preview).
  </Step>
</Steps>

### Keep the shared parts shared

<Steps>
  <Step title="Save anything that must stay identical as a synced section">
    Program rules, the legal notice, the support block, the "how deal registration works" explainer: these are the blocks where two versions is a compliance problem rather than an inconvenience.
    Save the section once and insert it into every experience that needs it.
    Editing it updates every experience it appears in, which is the whole point.
    See [Reuse content with synced sections](/features/content/synced-sections/guides/reuse-content-with-synced-sections).
  </Step>

  <Step title="Let dynamic variables absorb the per-partner differences">
    A large share of what looks like a reason to build another experience is really one line of copy that needs a different name in it.
    Type `{` while writing and insert a value that resolves to each partner's own data, so one paragraph greets every partner correctly and names their own manager.
    One experience with variables beats four experiences with hardcoded names.
  </Step>

  <Step title="Use restricted tabs for the differences that remain">
    Where two audiences need different content but the same portal, duplicate the tab inside one experience and restrict each copy to its segment.
    One experience, two audiences, one thing to maintain.
    See [Design the portal's tabs and navigation](./design-tabs-and-navigation).
  </Step>
</Steps>

### Move a cohort onto another experience

<Steps>
  <Step title="Do it in bulk from the partners list">
    Go to [Partners](https://app.introw.io/partners), select the cohort, and use the bulk actions bar.

    * **Apply experience** publishes the selected partners with an experience and creates their portals. This is the launch action for a new cohort.
    * **Update experience** swaps the experience partners already use and updates their existing portals. This is the migration action.

    See [Bulk update partners](/features/partners/partner-management/guides/bulk-update-partners).
  </Step>

  <Step title="Automate the move where your CRM already knows">
    When the thing that decides a partner's experience is a field your CRM owns, such as a tier or a program type, let a workflow do the move so the portal follows the CRM without a second data-entry step.
    **Update partner properties** with the partner's **Experience** publishes that experience to the partner, creating their portal if they have none and moving them if they are on another one.
    See [React to a CRM change on a partner](/features/automation/workflows/guides/react-to-a-crm-change-on-a-partner).
  </Step>
</Steps>

## Verify it worked

Open the copy and one original side by side and confirm the divergence is the divergence you intended: the parts you meant to share are synced sections, and a change to one CRM view has not moved the other.
Then check a moved partner's record shows the new experience and preview their portal to confirm the tabs changed.

The number to watch afterwards is how many experiences you have.
If it grows every quarter and none is ever retired, the differences between them are probably segment restrictions waiting to be collapsed back into one.

## Related

<CardGroup cols={2}>
  <Card title="Reuse content with synced sections" icon="link" href="/features/content/synced-sections/guides/reuse-content-with-synced-sections">
    Maintain a block once, use it everywhere.
  </Card>

  <Card title="Design tabs and navigation" icon="folder-tree" href="./design-tabs-and-navigation">
    Restricted tabs instead of a second portal.
  </Card>

  <Card title="Bulk update partners" icon="users-gear" href="/features/partners/partner-management/guides/bulk-update-partners">
    Move a cohort in one pass.
  </Card>

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