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
1
Open an experience
Go to Experience builder and open one.
The state indicator sits in the header, to the left of the Preview and Publish buttons.
2
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.
Steps
Read the state in the header
1
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.
2
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.
Understand what publishing actually does
1
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.
2
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.
3
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.
4
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.
5
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.
Check it before partners do
1
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.
2
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.
3
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.
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
Build and publish a portal experience
The build itself, end to end.
Restore a previous experience version
Roll back a publish you regret.
Launch the portal and the first two weeks
Going from published to partners actually using it.
Implementation reference
Full configuration options.