> ## 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. # Layer segments to progressively unlock capabilities > Start every partner in a restricted default segment, then let more specific segments grant more; when a contact is in several segments, the most permissive setting wins. > 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](/features/partners/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](https://app.introw.io/settings/notifications) 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 You need access to segment settings, and write access to the experiences you plan to gate. 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 Go to [Segments](https://app.introw.io/settings/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](./create-a-dynamic-segment) for the full walkthrough of the editor. 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. 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](/features/portal/portal-access/guides/restrict-a-tab-to-segments). 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](/features/partners/journeys/guides/build-a-journey-from-scratch) and [Assign a journey and track progress](/features/partners/journeys/guides/assign-a-journey-and-track-progress); for the full assembled pattern, tabs and sections included, see [Build a progressive onboarding path](/features/partners/onboarding/guides/build-a-progressive-onboarding-path). 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. ## Related Build the segments each stage keys off. The full assembled pattern: stages, gated tabs, and journeys. Give partners the checklist that moves them to the next layer. Full configuration options for segments.