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
1
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.
2
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.
Steps
Choose the right tool
1
Decide before you copy anything
Three different problems get solved three different ways, and picking the wrong one is what creates drift.
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.
Duplicate an experience
1
Copy it from the list
Go to Experience builder, 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.
2
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.
3
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.
Keep the shared parts shared
1
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.
2
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.3
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.
Move a cohort onto another experience
1
Do it in bulk from the partners list
Go to 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.
2
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.
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
Reuse content with synced sections
Maintain a block once, use it everywhere.
Design tabs and navigation
Restricted tabs instead of a second portal.
Bulk update partners
Move a cohort in one pass.
Implementation reference
Full configuration options.