Repository navigation
Clarity required for security and compliance capabilities for SPE #9638
Description
The statements about Purview security and compliance capabilities applying to File Storage Containers seem reassuring. Nevertheless, lurking in that black and white statement is a lot of grey. For example:
Retention: I assume that org-wide retention policies apply to File Storage Containers (FSC), but what about non-org-wide retention policies (those that apply to selected locations)? AFAIK, it’s not possible to select SPE sites from the Purview UI. Also, do FSCs support adaptive scopes (requires E5 or advanced compliance)? Because eDiscovery works, I assume that auto-labeling policies support content located in FSCs (requires E5), but does advanced retention features work such as disposition reviews?
Sensitivity labels: If a tenant only has E3 licenses, users can manually apply sensitivity labels to files – but apps must include UI to reveal the sensitivity labels published to the location (or all sensitivity labels that apply to Files). Finding files with sensitivity labels is straightforward but the public API for applying sensitivity labels to files is a metered API that requires Microsoft approval for an app to use, so how does an app apply sensitivity labels to content? Can a default sensitivity label be defined for a document library in an FSC?
And while auto-labeling policies should work (non-public API but requires E5 licenses), will the presence of sensitivity labels that assign usage rights over content impact how an app works?
For both retention labels and sensitivity labels, will the application of labels to SPE content show up in audit records and the Activity Explorer?
The point is that broad statements about Purview tend to become tangled in license-specific implementation questions. That’s why I have problems with the way that the documentation frames the issue and the lack of detail in the chosen words. It would be good to have much more clarity about what security and compliance capabilities are available for FSCs together with the licensing requirements.
Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.
- ID: 3cdc7a81-923a-fbb8-8a4c-a964d9ecd2cf
- Version Independent ID: 3cdc7a81-923a-fbb8-8a4c-a964d9ecd2cf
- Content: SharePoint Embedded Overview
- Content Source: docs/embedded/overview.md
- Service: sharepoint-online
- GitHub Login: Vesa Juvonen (@VesaJuvonen)
- Microsoft Alias: vesaj
Activity
Amey-MSFT commentedon Jun 30, 2025
Hello Tony Redmond (@12Knocksinna),
Thank you for bringing this issue to our attention. Could you please confirm if the issue still persists for you?
We will look into it and get back to you shortly.
12Knocksinna commentedon Jun 30, 2025
Thanks for getting back to me. It's been a while since the original message. I took a look at the current page and it doesn't cover how SharePoint embedded containers deal with Purview retention policies or sensitivity labels. A section in the document that clearly explains whether it's possible to apply data lifecycle management settings to the content stored in the containers would be helpful, if only to remove doubt. The same is true for sensitivity labels. Loop files stored in the containers support labels, but do the containers support labels in the same way as SPO sites support labels?
Amey-MSFT commentedon Jul 4, 2025
Thank you for the follow-up. We'll connect with the engineering team to get clarity on these points and update you as soon as we have more information.
VesaJuvonen commentedon Nov 3, 2026
This issue is more than 12 months old and has not had recent activity. We are cleaning up the backlog so we can manage incoming reports more efficiently. If the issue is still relevant, please submit a new issue with updated details and current reproduction steps. We apologize for any inconvenience caused by this updated process, and thank you for being part of the SharePoint developer ecosystem.
github-actions commentedon Nov 3, 2026
Thank you for taking the time to file an issue. We periodically archive older or inactive issues as part of our issue management process, which automatically closes them once they are archived.
If you’d like to understand more about why and how we handle archived (closed) issues, please see Our approach to closed issues.
We appreciate your contribution and if this is still an active issue with the latest SPFx versions, please do resubmit the details. We needed to perform a cleanup, so that we can start with a clean table with a new process. We apologize for the inconvenience this might cause.