The Challenge
A records manager at a large organization faced a common dilemma: how to apply retention controls to thousands of SharePoint Online sites when the organization's Records Control Schedule contained detailed retention classes, but no one knew exactly where records lived or how users had organized them.
The problem wasn't technical capability. Microsoft Purview offers both retention policies and retention labels. The issue was alignment. The organization's Records Control Schedule specified retention by business function and activity. But SharePoint content was scattered across Group-based sites linked to Teams, classic communication sites, the generic Documents library in every channel, and user-created folder hierarchies that followed no consistent logic.
Before configuring a single Records Control Schedule, this records manager needed to answer three questions: Where are the records? How have users aggregated them? And which retention classes map to which storage locations?
The Environment and Constraints
The organization used two types of SharePoint sites for retention purposes. Group-based sites linked to Microsoft 365 Groups included all the sites accessed via the Shared tab in Teams channels. Classic and communication sites operated independently, not linked to Groups. Each type required separate retention policies.
The Records Control Schedule followed a detailed model similar to State Records NSW's approach. Under the Financial Management function and Accounting activity alone, the schedule listed nine distinct retention classes. Class 7.1.1 covered financial transaction records with a requirement to retain for seven years after the end of the financial year, then destroy. Other classes under the same function specified different retention periods.
Users created content through multiple methods: browser, Teams, OneDrive, Outlook, and File Explorer. Teams had become the dominant method, resulting in records stored in largely uncontrolled folder structures within the Documents library. Users with Edit rights could apply or remove retention labels from folders and items through the Details panel at any time.
The technical constraint mattered: retention policies don't tag individual records. They target all content in assigned SharePoint sites. You can't apply them to specific libraries or folders. Retention labels, published via label policies, do tag individual items and can prevent permanent destruction before a minimum period expires. But labels applied to folders inherit down to everything under that folder.
The Approach Taken
The records manager started with discovery, not configuration. Step one: create and maintain a listing of all SharePoint sites with metadata fields including Status (Active/Inactive), Retention applied (policy or label), Expected destruction date, Date destroyed, and Destruction approved by.
Step two: identify how records relating to the same subject matter had been aggregated. Which sites? Which libraries? Which document sets? Which folders? This meant understanding not just where content lived, but how users had grouped it.
Step three: map retention classes to storage locations in a spreadsheet. For class 7.1.1 covering financial transactions, the mapping specified a retention label named "7.1.1 Financial transactions, 7 years, Do nothing" with a description matching the retention class, a trigger of date last modified, and an action of either do nothing or change the label to indicate records due for disposal.
The organization then implemented a two-layer approach:
Layer one: Apply a back-end Records Control Schedule to all or selected SharePoint sites via Purview, using static or adaptive scopes. For Group-based sites, the policy specified five years after date last modified, then do nothing. Separate policies covered non-Group-based sites. When multiple policies applied to the same location, the policy with the longest retention period won.
Layer two: Publish retention labels mapped to specific retention classes. These labels could be applied three ways: as the default retention option for an entire document library via library settings, to a folder and everything under it, or to individual items.
For a Group-based site accessed via Teams, most content sat in the generic Documents library with one top-level folder per channel and multiple user-created folders beneath. The site fell under the five-year Group Records Control Schedule. But some folders contained records requiring ten-year retention. The records manager published a retention label mapped to the appropriate retention class and applied it directly to those folders. The label inherited to all items beneath, protecting them from unauthorized destruction while other site content could be manually destroyed.
For a non-Group-based site accessed via browser, users had created separate libraries to aggregate records by calendar year (Meetings 2025, for example). All records in these libraries mapped to the same function-activity pair and retention class. The site fell under the seven-year policy for classic and communication sites. When a library became inactive, the appropriate retention label was applied via library settings.
Results and Lessons Learned
The approach worked because it started with the question "where and how are records stored?" before asking "which Purview features should we use?"
Retention policies created back-end system processes that identified whether individual records could be destroyed automatically, left in place to be deleted through another process, destroyed automatically at a certain age, or kept forever. Anything users deleted landed in the Preservation Hold library and was automatically deleted when the retention period expired based on date last modified.
Retention labels prevented premature destruction of individually tagged items. A site or Group couldn't be destroyed as long as one item on the site was subject to a retention hold.
The records manager identified one critical lesson: don't apply retention labels until libraries become inactive if users have Edit rights. Users who can apply labels can also remove or change them through the Details panel, undermining retention controls on active sites.
Takeaways for Your Team
Managing retention in SharePoint will be easier if records are already stored in logical aggregations (sites, libraries, document sets) that contain additional recordkeeping controls such as metadata. Folders aren't ideal because they lack those controls, but they're workable if you understand what sits beneath them.
Your SharePoint architecture design should address retention requirements from the start. If you're designing new sites or libraries, think about how retention classes will map to storage locations before users start creating content.
Create your site listing now if you don't have one. You can't apply retention controls strategically if you don't know what sites exist, which are active, and what retention already applies.
Map retention classes to storage locations in a spreadsheet before you configure anything in Purview. The spreadsheet should specify the retention label name, description, trigger, and action for each class. This mapping document becomes your implementation guide.
Remember that retention policies and retention labels serve different purposes. Policies apply broad controls to entire sites. Labels provide granular control over specific libraries, folders, or items. Most organizations need both, applied in layers.
If your Records Control Schedule contains many detailed classes (like the State Records NSW model with nine classes under Financial Management-Accounting alone), you'll rely heavily on retention labels applied at the library or folder level. If your schedule uses rolled-up classes (like the National Archives of Australia model with only two classes under Financial Management), you might handle more through site-level policies.
Don't assume users organize content logically. They don't. Your discovery process will reveal folder structures that follow no consistent pattern, records stored in unexpected locations, and aggregations that mix multiple retention classes. Design your approach to handle that reality.
