Experiences

​

Where it lives

Experiences sit under Portal, at Experience builder. Each one is a set of tabs you compose from sections, then publish to the partners it is for.

​

Before you start

​

How it works

An experience is built from stages and sections. Stages are the tabs partners see across the top of the portal, and sections are the content blocks within a stage. You add sections from a picker that includes rich text, documents, CRM views, forms, and other blocks, and arrange them visually. The experience is the master layout; when you assign it to a partner, they get a partner portal based on it. You can save a section as a synced section to reuse it across experiences, keeping shared content in one place. When you change an experience, you publish it to push the update to the partner portals linked to it, and you can preview the experience to see exactly what partners will see first.

​

Designing experiences partners actually use

A published portal only drives the program if partners return and act. A few principles help:

• Lead with the next action. Put the most important action, like registering a deal or finishing onboarding, at the top of the home tab with a clear call to action.
• Keep each tab focused. Show only what a partner needs and tailor tabs by segment rather than crowding one page.
• Make it personal. Add a partner profile section and tier status so the portal reflects the individual partner.
• Keep it fresh. Use announcements so there is a reason to come back.

​

Settings & configuration

Experiences are built in the experience builder at Experiences; reusable sections live under synced sections.

​

Stages (tabs)

Stages are the portal’s tabs, and they are the portal’s whole navigation. Drag a tab along the bar to reorder it; its … menu carries the rest. Hiding and restricting are different tools: hiding takes a tab from everyone, restricting takes it from everyone outside the chosen segments. See Design the portal’s tabs and navigation.

​

Sections and blocks

Sections hold the content within a stage. Add them from the section picker and drag to reorder. The picker opens on Overview, which shows a few suggested blocks and then the group grid; search from there reaches every block in every group. Which CRM blocks appear depends on your CRM: ticket pipelines, lead lists and custom-object lists are not offered on Pipedrive, and order pipelines are HubSpot only. Reach for smart sections first, because a portal built from them stays current with no editing. See Every section you can add to a portal for what each block shows a partner.

​

Dynamic variables

Type { anywhere you write content and Introw inserts a dynamic variable: a placeholder that resolves to that partner’s own data when the page renders. One experience therefore reads as if it were written for each partner, with no per-partner copy. The { menu offers: CRM-sourced entries carry your CRM’s logo in the menu and Introw-sourced entries carry Introw’s, so you can see where a value comes from before you insert it. Values resolve per partner at render time and follow the CRM record, so updating the field in HubSpot or Salesforce updates every page it appears on. Variables work in the same way in the experience builder, in announcements, in form content and the post-submission screen, and in course content - one syntax across every surface where you write. Two related surfaces do the same job without a variable: the Partner profile section renders a chosen set of partner-record properties as a block (with per-property label overrides and optional inline editing by the partner), and the Tiers block renders the partner’s tier and the ladder above it.

​

Layout blocks

Beyond plain sections, the builder ships layout primitives:

• Columns - two, three, or up to five columns per row, with draggable dividers to set the widths. A column takes any block, so a goals tile and a tasks tile sit side by side, or an image sits next to text.
• Collapsible content - a group of collapsible items. Items drag to reorder inside the group, and each item holds any block, an embedded form included.
• Tables, headings, lists, dividers, images, and call-to-action buttons.

​

Linking to a tab

A portal URL carries the open tab in a stage query parameter, so a link of the form https://your-portal-domain/?stage={tabId} opens the portal on that tab. Use it when an external tool - a marketing email, an intranet page - has to land partners on a specific tab. Inside an experience, a call-to-action button does the same with Go to tab, and can also open a form or an asset directly.

​

Images inside sections

Person photos and the partner logo run through the same square avatar treatment as the company logo, so anything wide loses its sides. Inline images keep their ratio, which is why the two sizes above match the slots the editor and AI generation produce.

​

Synced sections

A synced section is a saved, reusable section. Maintain it once and insert it into any experience; updates to the synced section flow to where it is used. Synced sections are documented in full under Synced sections.

​

Assigning and publishing

Assign an experience to a partner so they get a partner portal based on it. Publish pushes changes from the experience to the linked partner portals. Edits save themselves; publishing is separate. The header carries a state pill: green Published when everything is pushed, orange Draft when there are edits newer than the last publish, with Last saved under it. Draft does not mean “never live” - a portal a hundred partners use reads Draft the moment you change a heading. Publishing re-syncs every partner already on the experience. The publish dialog preselects them and does not let you deselect them, so the selection only decides who is added. For each tab it overwrites the content, name, layout, background colour, segment restrictions, hidden flag and position in every linked partner’s portal. Two consequences: a tab removed from the experience is removed from every partner’s portal along with its documents, and anything edited directly on one partner’s portal is overwritten on the next publish. Publishing also creates portals for selected partners who have none, applies the journeys and goals attached to its tabs, and generates affiliate links for any campaign block. Two ways out of the dialog. Publish without email applies everything silently, which is what an edit to a live portal wants. Writing a Personal message and choosing Publish and notify emails the selected partners, which is a launch rather than a save. The portal-limit check counts only the partners being added, so an edit to a live experience is never blocked. Preview is per partner and shows the published state. The Preview button lists the partners on this experience that already have a portal and opens the one you pick, rendered with their own data. A brand-new experience with nobody on it shows No Partners Found. Because it renders their portal, it reflects your last publish rather than the draft on screen. See Draft, published and preview.

​

Automate it with a workflow

A workflow can move a partner between experiences. Update partner properties with the partner’s Experience does not patch a field: it publishes that experience to the partner, creating their portal if they have none and applying its content, journeys, and goals. A partner already in another experience is moved to this one, so it is a genuine move rather than an addition. Because it can create a portal, that row is subject to your plan’s portal limit, and it has no write mode for the same reason: partners who already have a portal still move, and partners without one are skipped until you free up or add portals. The usual trigger is a classification change your CRM owns, so the portal follows the CRM without a second data-entry step. See React to a CRM change on a partner.

​

How-to guides

​

Troubleshooting