M365 PlaybooksPurview · Teams · SharePoint · OneDrive· Plan
Design your segments and barrier policies
Purpose
Keep apart the people a rule says must be kept apart, and nobody else. Information barriers stop two groups from finding, chatting with, calling, meeting or sharing files with each other in Teams, SharePoint and OneDrive. That is exactly what a conflict-of-interest rule needs, and exactly what breaks everyday collaboration when it's drawn too wide. Most of the hard decisions can't be changed cheaply later, so they belong here: which rules justify a barrier, which attribute defines the groups, and which mode the organization runs in.
Overview
The rules that justify each barrier, the attribute that defines segments, the organization's mode, and a signed matrix of who can't talk to whom.
- Effort
- About 8 to 15 person-days
- Duration
- 4 to 6 weeks
- Complexity
- High
- Who's in the room
- Compliance lead (owner), legal, HR or the owner of directory data, Purview admin, Teams admin, SharePoint admin
Risk of not doing it
Barriers drawn from an unclear rule or messy directory data cut off people who should be working together, and fixing the design after policies apply removes people from teams and chats a second time.
Key activities
The plan in order: what must be true first, what to decide, then how to configure the pilot and production.
Prerequisites
Tie every barrier to a rule and an owner
Information barriers exist to enforce a rule: a regulation, a conflict-of-interest policy, a commitment to a client. Write down each rule, who owns it, and which groups it separates. If nobody can name the rule, it probably isn't a barrier; sharing settings, sensitivity labels or team membership may be enough. Microsoft recommends using the minimum number of policies that meets your requirements, and every barrier you add is one more thing people work around.
Check the organization's mode
Your tenant runs in Legacy, SingleSegment or MultiSegment mode, depending on when information barriers were first enabled. Legacy mode allows 250 segments with one segment per person and relies on Exchange address book policies, which must be removed before you start. The newer modes allow up to 5,000 segments and manage address book policies for you. Check the mode first; several decisions below depend on it.
Choose one attribute and check its quality
Segments are defined from Microsoft Entra attributes; Department, MemberOf, Company and the extension attributes are the most common. Microsoft advises using the same attribute for every segment and keeping segments from overlapping. Whatever you pick, someone must keep it accurate as people join, move and leave, because a blank or wrong value silently puts a person on the wrong side of a barrier. Export the values for everyone in scope now and count what's missing or inconsistent.
Decisions
Decision: One segment per person, or several?
In MultiSegment mode a person can belong to up to 10 segments, which suits people who legitimately span groups, such as compliance staff or teachers across schools. You can only switch to MultiSegment while no segments or policies exist, and Microsoft says not to revert afterwards. So decide before the first segment is created, even if you don't need it yet.
Options
- Start in single-segment mode and switch later
- Choose the mode before the first segment exists
Recommended default: Choose the mode before the first segment exists
Decision: Block or allow policies?
A block policy stops one segment from communicating with named segments; an allow policy lets a segment communicate only with the ones it names. Each segment can have one policy, each policy works in one direction (so a barrier between two groups needs two), and a policy's type can't be changed after it's created. Microsoft recommends block policies for most scenarios because they give people a more consistent experience; in MultiSegment mode, define every policy as an allow list.
Options
- Allow policies everywhere
- Block policies for most barriers; allow only where a group may talk to a few named groups
Recommended default: Block policies for most barriers; allow only where a group may talk to a few named groups
Decision: What about email?
Information barriers don't restrict email in Exchange Online. If a rule requires that two groups don't email each other, Microsoft points to Exchange mail flow rules instead, covered in this topic's Go further playbook. Decide per rule, and make sure the rule's owner knows which channels the barrier covers and which it doesn't.
Options
- Rely on information barriers alone
- Add mail flow rules wherever the rule covers email
Recommended default: Add mail flow rules wherever the rule covers email
Decision: Who stays unsegmented, and can people see each other?
In the newer modes, people outside any segment stay visible to everyone, so functions like HR or IT can stay unsegmented and keep working across barriers. Decide that deliberately rather than by accident of missing data. By default, blocked people also disappear from the people picker; outside Legacy mode you can turn that restriction off, but keeping it on avoids people trying, and failing, to contact someone.
Options
- Leave unsegmented whoever has no attribute value
- Choose unsegmented functions deliberately and keep the people-picker restriction on
Recommended default: Choose unsegmented functions deliberately and keep the people-picker restriction on
Pilot configuration
Draw the barrier matrix
List segments down and across a grid and mark each pair allowed or blocked, then derive the policies from it. Check the matrix against each rule in the register, and against the people who will be licensed for it: users in a policy's assigned segment need a licence that includes information barriers, which Microsoft 365 E5 does.
Find what the barriers will break
When policies apply, people who can no longer communicate are removed from group chats and teams, and their one-to-one chats become read-only. Existing teams stay in Open mode, with no barrier, until you move them to Implicit, which then removes members who don't fit. Turning on scoped directory search, which barriers require, also hides the team search box and public team listing. List the teams, sites and recurring meetings that span a planned barrier, and who owns them.
Production configuration
Sign off the design
Ask the rule owners, legal and the owner of directory data to sign the register, the matrix, the mode, the attribute and the email decision together. A signed design is what Prepare tests against and what you'll defend when someone asks why they can't reach a colleague.
Make it enforceable
Nothing is enforced at this stage. The signed register and matrix become the source for every segment and policy, and any later change starts as a change to them.
Risk: nothing enforces this standard yet. Until something does, treat it as a risk, not as done.
Approval and readiness
Gather the rules
Each barrier has a rule, an owner and the groups it separates.
Move on when: The register is complete
Decide mode and attribute
Check the mode, choose the attribute and count data gaps.
Move on when: Mode and attribute are agreed
Draw the matrix
Derive policies and the list of teams and sites they affect.
Move on when: Every pair has a decision
Sign offChange: Inform
Rule owners, legal and directory owners sign the design.
Move on when: The design is signed
Common challenges
If youUse barriers where sharing settings would do
What tends to happenCollaboration breaks across the organization for a risk that a label or a private team would have handled.
A better approachRequire a named rule and owner for every barrier.
If youCreate the first segment before choosing the mode
What tends to happenMoving to multi-segment later means removing every segment and policy first.
A better approachDecide the mode before any segment exists.
If youMix attributes or allow overlaps
What tends to happenSome people land in two segments, others in none, and the barrier has holes.
A better approachUse one attribute for every segment and check for overlaps before Prepare.
If youAssume barriers cover email
What tends to happenThe rule's owner believes email is separated when it isn't.
A better approachDecide email per rule and add mail flow rules where needed.
If youForget that policies work in one direction
What tends to happenOne group is blocked; the other can still reach it.
A better approachCreate two policies for every barrier and check them against the matrix.
Checkpoints
Pilot
- Does every barrier trace to a named rule and owner?
- Is the mode decided before any segment exists?
- Is the email decision recorded for each rule?
Production
- Is the attribute owned and its gaps counted?
- Is the impact list shared with team and site owners?
- Is the design signed?
Success measures
Capture a baseline before you start, or you won't be able to show the change.
| Measure | Where you see it | Good direction |
|---|---|---|
| Barriers traced to a named rule and owner | Barrier register | Up |
| People in scope with a missing or unexpected attribute value | Microsoft Entra user export | Down |
| Teams and sites that span a planned barrier | Impact list | Down |
Ready-to-use text
Barrier register
Columns: Rule | Owner | Segments it separates | Policy type (block or allow) | Email covered (Y/N, how) | Teams and sites affected | Review date.
Barrier matrix
Segments down the side and across the top. Mark each cell Allowed or Blocked, then write one policy per segment: Assigned segment | Policy type | Segments named | Rule it enforces.
Additional reading
Changelog
Changelog (1 version)
| Version | Date | Author | Change |
|---|---|---|---|
| 1 | Sev Derghazarian | First version. Facts checked against Microsoft Learn on 2026-10-16. |