Guests, shared channels, and a label that will not appear
Adatum has acquired Litware. Litware's 2,000 users will stay in their own tenant for nine months, during which 120 joint project teams are needed, each mixing Adatum and Litware members collaborating on files. Adatum's CISO requires that a specific set of 12 'deal teams' cannot have guests at all, and that their files be encrypted and reachable only from the corporate network. Adatum publishes seven sensitivity labels, but when the Teams admin tries to apply a label to a team only two are listed, and neither is the 'Deal Team' label. Guest access is enabled tenant-wide and external access currently allows all domains.
1. Guests or shared channels for the 120 joint project teams? Recommend one and state what has to be true in both tenants for it to work.
Read the worked answer
Recommend shared channels as the default for the 120 project teams, with guests retained only where shared channels cannot serve the need.
Reasoning:
- Shared channels use B2B direct connect, so Litware users work in their own tenant with their own identity, their own Conditional Access, and their own compliance posture, instead of being provisioned as 2,000 guest accounts in Adatum and then cleaned up in nine months.
- There is no guest account lifecycle to run, no access reviews to chase, and no risk that a departed Litware contractor lingers as a guest.
- Files live in the host tenant's SharePoint, so the collaboration surface is genuinely shared rather than duplicated.
What must be true in both tenants:
- External access (Teams admin center → Users → External access) must be configured to allow the other organisation - for shared channels this is the B2B direct connect configuration, not just the legacy federation toggle. 'Allow all external domains' at Adatum is not sufficient on its own if Litware blocks Adatum.
- Litware's admins must also allow Adatum; this is a bilateral configuration and is the usual reason a shared channel 'does not appear'.
- Users must be licensed for Teams in their home tenant.
Where guests are still correct: anything that requires the person to be a member of the team itself, to appear in the org directory, or to use features scoped to team membership rather than channel membership. Make that the exception list, not the default, and document why each exception exists.
2. Why do only two of seven labels appear when labeling a team, and what is the fix? Frame this as a diagnosis, not a list of clicks.
Read the worked answer
Diagnosis: the labels exist in Purview, but existence is not the same as being applicable to a team. A label appears in the Teams team-labeling experience only if all of the following are true:
- The label has the Groups & sites scope enabled. If it was created with only Files & emails, it can never be applied to a team.
- The label is included in a label policy that is published to the admin (and to the team owners who will apply it). A label that is published to nobody, or to a pilot group the admin is not in, will not show.
- The policy has propagated. Publishing changes takes time; a label added an hour ago may not appear yet.
So 'two of seven' is the classic signature of a label set where only two were created with the Groups & sites scope, or where the published policy contains only two. The 'Deal Team' label is almost certainly published to a pilot group or was created files-only.
Fix: in Microsoft Purview, edit the 'Deal Team' label and enable the Groups & sites scope (choosing the privacy and guest-access settings), then publish it in a label policy that includes the relevant admins and team owners, and wait for propagation. Verify by labeling a disposable team.
Do not work around this by rebuilding the label under a new name - that breaks the encryption template and any content already protected.
3. The CISO wants the 12 deal teams to have no guests and files reachable only from the corporate network. Which parts of that requirement can a sensitivity label actually deliver, and which cannot?
Read the worked answer
What the label can deliver:
- Guest access control. A label with the Groups & sites scope includes external-sharing and guest-access settings, so applying the 'Deal Team' label to a team blocks guests for that team's Microsoft 365 group even while guest access remains enabled tenant-wide. This is the correct mechanism - it is targeted, auditable, and survives team recreation.
- Encryption. A label with encryption protects the files in the team's SharePoint site, and the label is applied to the group so new sites inherit it.
What the label cannot deliver:
- 'Reachable only from the corporate network' is not a label setting. Labels control classification, encryption, sharing, and (via site settings) some external-sharing behaviour. Restricting access by network location is a Conditional Access problem: you need an Entra ID Conditional Access policy scoped to the SharePoint/Teams workload with a named location condition that blocks off-network access, plus the identity controls to make that meaningful.
Also plan for the gap between intent and state:
- Applying a label to an existing team does not retroactively remove guests who are already members. The 12 deal teams need an access review or scripted removal of existing guests after labeling.
- Label changes propagate to the group and site asynchronously; verify on each of the 12 teams' SharePoint site and group settings rather than assuming.
- The CISO should be told plainly that the network-restriction half of the requirement is a Conditional Access project with its own rollout and exclusion management, not a labelling task - otherwise the team will be marked compliant on paper while off-network access still works.