> ## 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. # Segment defaults and overrides > Partner permissions and notifications now start from one organisation-wide default, and a segment changes them only when you turn on an override. What changed, what we migrated for you, and what to check. > Partner **permissions** and **notifications** now start from one organisation-wide **default**, and a segment changes that default only when you deliberately turn on an override. > This page explains what changed, why, what we migrated for you, and the handful of things worth checking in your own setup. *Shipped in the August 2026 release.* In June, [roles became segments](/release-notes/roles-are-now-segments), and segments became the one audience model across the product. This release doubles down on that: it gives segments a real baseline to sit on top of, makes every override explicit and visible, and explains each setting where you set it. The result is a program you can reason about at a glance, which is the [enterprise-grade](/why/enterprise-grade) bet applied to governance: as your segment count grows, the number of things you have to hold in your head does not. ## What changed, in one table | | Before | Now | | -------------------------- | -------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | The baseline | Permissions had no real home. You created a segment with no conditions to stand in for "everyone". | **All partners · Default** is a first-class layer with its own editor. No fake segment needed. | | A new segment | Silently carried permission and notification opinions, and won the merge. | Carries nothing. It changes the default only when you switch on **Override the default for this segment**. | | Reading your setup | You opened every segment to find out what it did. | The segments table shows **Permissions** and **Notifications** per segment: **Default**, or exactly what differs. | | Notification config | Per event, an **email** checkbox and a **chat** checkbox. | Per event, one **Recipients** choice: **All partners**, **Collaborating only**, or **Disabled**. | | Partner chat notifications | Rode along on the same checkbox, per event. | Configured on the chat integration itself, per platform. | | Permission settings | Two bare switches with short labels. | Feature cards that explain the rule and preview what the partner will see, both renamed and phrased as grants: **Invite colleagues** and **See all shared records**. | | Contact level | A list of toggles, with no way to tell what decided them. | The full cascade, with a badge on every event naming the layer that decided it. | ## The one rule Every partner permission and every partner email notification now resolves the same way, in three steps: ``` 1 All partners · Default applies to everyone, always 2 Segment overrides only segments that opted in, and only for their members 3 The contact themselves their own opt-outs, and only ever to switch something off ``` Read it as a cascade: the default is the baseline, a segment override changes it for that segment's members, and a contact can silence what is left on for them. Three things follow from that, and they are the parts worth remembering. **A segment override can turn something off, not only on.** This is the real capability change. Previously a segment could only ever grant more than the baseline, so "hold this group back" was impossible to express. Now, where an override segment has an opinion, that opinion changes the default for its members in both directions. Both permissions behave this way, including **See all shared records**: a segment can restrict a group the default leaves open, and can open up a group the default restricts. What keeps that from happening by accident is that a segment now states a setting only when you move it off the default value. A segment that only meant to grant invites says nothing about record visibility, so it cannot cancel an organisation-wide restriction the way it used to. **Within the segment layer, the most permissive setting still wins.** If a contact matches two override segments and they disagree on the same setting, the more permissive one applies, and that holds for every setting: an invite grant beats a deny, **See all shared records** on beats off, and a wider notification audience beats a narrower one. Qualifying for more groups never takes a capability away. If your default withholds full record visibility, a **Sales manager** segment grants it, and a **Gold partner** segment withholds it, a contact who matches both sees all shared records. Anything no override segment mentions falls through to the default. The flip side is worth stating: a segment cannot hold a group back from something another of their segments grants. To keep a capability away from a group, withhold it on the default and grant it only on the segments that should have it. **A contact can only ever opt out.** When your policy leaves an event on, the contact can switch off their own copy. When your policy has it off, the row is locked for them and they cannot switch it on. That is enforced when the change is saved, not just hidden in the interface, so no screen can record an opinion on an event the default or a segment owns. The old rule was "to restrict a contact, the restriction has to hold in **every** segment they are in". That rule is gone. You set restrictions once, on the default, and only opted-in override segments change them. ## See the whole cascade in one pass This is the release end to end: a restricted baseline set on **All partners · Default**, a stage segment that overrides it to grant more, a portal tab gated to that stage, and finally the same partner contact resolving to the granted behavior with each layer named.