Skip to main content
For partner ops designing a program where partners start with the essentials and earn more access as they grow.
Partner contacts rarely sit in exactly one segment: a certified reseller in the Benelux can match your catch-all segment, your reseller segment, and your certified segment at the same time. Introw resolves that overlap in one direction: the most permissive setting wins. A segment can grant a capability, but it can never take away what another segment already grants. That makes segments safe to layer: keep one restricted default segment that captures everyone, and let each more specific segment only ever add capabilities. This is the mechanic underneath progressive onboarding, where journeys move partners toward milestones and each milestone unlocks the next layer. This guide sets up the layers, spells out exactly how overlapping settings resolve, and pairs the layers with a journey so partners keep moving up.

​
What you’ll achieve

A layered segment setup where every partner starts in a restricted default segment and unlocks more permissions, notifications, and portal content as they qualify for more specific segments, with a journey giving them the concrete path to the next layer, and no risk that an overlap accidentally locks a partner out of something they earned.

​
How overlapping segments resolve

When a partner contact belongs to more than one segment, each setting resolves independently, and the most permissive value across their segments applies:
  • Permissions grant, never revoke. A contact may act when any of their segments allows it; a restriction only applies when every segment they belong to imposes it.
    • Invite team members - the contact can invite colleagues if any of their segments has it on. It is only off for them when every segment they belong to explicitly turns it off.
    • Collaboration restricted - the contact is only limited to collaborating records when every segment they belong to restricts collaboration. One segment without the restriction gives them full visibility across their partner’s records.
  • Notifications: enabled wins over disabled. If any of the contact’s segments turns a notification type on for a channel (for example deal updates by email), they receive it, even when another of their segments turns that same notification off. A segment-level off only holds when no other segment they belong to turns it on. When none of their segments override a type, the program default from Notification settings applies.
  • Notification scope: the wider audience wins. When one segment scopes a notification to all partners and another to only collaborating contacts, the contact is treated with the wider scope, all partners.
  • Segment-gated surfaces are a union. A tab, asset, form, course, or report restricted to segments is visible to a contact in any of those segments; membership in another, more restricted segment never hides it.
The practical rule: to actually restrict a partner contact, the restriction must hold in every segment they belong to. Design your most restricted settings on the default segment that captures everyone, and use every other segment purely to grant more.

​
Before you start

1

Confirm access

You need access to segment settings, and write access to the experiences you plan to gate.
2

Map the progression

Decide the stages a partner moves through (for example: everyone, onboarded, certified, co-sell) and what each stage should unlock: which tabs, which permissions, which notifications.

​
Steps

1

Create the restricted default segment

Go to Segments and create a dynamic segment with no conditions, so it captures every partner and contact, including everyone who joins later. This is the floor of your program: because more specific segments can only add to it, this is the one place your most restricted settings belong.
  • On the Permissions tab, set the tightest posture you want new partners to have: turn Invite team members off if new partners should not bring in colleagues yet, and turn Collaboration restricted on if they should only see records they actively collaborate on.
  • On the Notifications tab, keep only the essentials on (for example announcements), and turn off the types a brand-new partner should not receive yet, such as object updates.
See Create a dynamic segment for the full walkthrough of the editor.
2

Create the segments that grant more

Create one dynamic segment per stage of your progression, each with the condition that marks the stage’s milestone: an onboarding journey completed, a certificate earned, a tier reached, a lifecycle phase, or a CRM property value. On each, configure only what the stage earns:
  • Permissions - turn Invite team members on for stages trusted to grow their own team; leave Collaboration restricted off so the stage sees all of their partner’s records.
  • Notifications - turn on the richer types the stage should now receive, for example deal updates by email or chat, and widen the scope to all partners where appropriate.
Because the most permissive combination wins, stage filters do not need to exclude earlier stages: a partner who qualifies for a later stage usually still matches the earlier segments, and that overlap is exactly what you want. You never need to mirror the default segment’s restrictions here either; a partner who qualifies inherits the union of everything their segments grant, and a partner who does not stays on the floor.
3

Gate portal content to the granting segments

Point the surfaces each stage unlocks at its segment: restrict tabs and sections of an experience, target assets, courses, and forms. A partner in any of the chosen segments sees the surface, so gating to a stage segment shows it the moment a partner qualifies. See Restrict a tab to segments.
4

Give partners the path to the next layer

Layers only unlock if partners hit the milestones your segments key on, so pair the setup with a journey: the ordered checklist that walks a partner toward the next stage, for example complete the onboarding tasks, finish the certification course, register a first deal. As they complete it, the milestone lands in their partner data, the next stage’s dynamic segment picks them up, and the layer unlocks on its own. See Build a journey from scratch and Assign a journey and track progress; for the full assembled pattern, tabs and sections included, see Build a progressive onboarding path.
5

Verify the resolution with a test partner

Pick a partner contact who matches both the default segment and at least one granting segment, and confirm they get the granted behavior, not the restricted one: they see the unlocked tabs, they can invite if any of their segments allows it, and they receive the notification types any of their segments turns on. Then check a partner who only matches the default segment still gets the restricted floor.

​
Verify it worked

A partner who qualifies for a more specific segment gains its capabilities without losing anything, and a partner in only the default segment stays on the restricted floor. As partner data changes in your CRM, dynamic segment membership shifts and the portal opens up on its own, with no per-partner access management.

Create a dynamic segment

Build the segments each stage keys off.

Build a progressive onboarding path

The full assembled pattern: stages, gated tabs, and journeys.

Build a journey from scratch

Give partners the checklist that moves them to the next layer.

Implementation reference

Full configuration options for segments.