Do you want to do any of these things on content across your Office 365 environment?
If you do, you’re not alone. If you’re building new solutions for these things, you should be leveraging modern options for accomplishing them wherever and whenever you can. Policies are the name of the game in Office 365 and this post explains several different policy types and considerations for using one over the other for each requirement above:
Retention Policy (modern)
A retention policy is published to a container (SharePoint site collection or Exchange mailbox for regular email, Group email, Teams chat and channel conversations, or Skype messages). The retaining happens behind-the-scenes without an end-user’s knowledge. It does this thru either the Recoverable Items Partition or the Preservation Hold Library depending on which workload is being retained. Retention policies can retain, retain and delete, or outright delete content based on conditions you provide.
Important to know, if an end-user attempted to delete a site while a retention policy was in effect on the site, an error would be thrown:
Reference link: Overview of retention policies
Label Policy (modern)
A label policy is associated with a retention label and is published to either a SharePoint site (collection) or Exchange mailbox. It’s visible as a piece of metadata on a folder or document. They can be manually applied or automatically applied. Similar to a retention policy, labels can retain, retain and delete, or outright delete content based on conditions you provide.
Important to know, if an end-user attempted to delete a site while retention labels have been applied to content within, they would not be allowed to do so:
Reference link: Overview of retention labels
Group Expiration Policy (modern)
This policy detects activity in an Office 365 Group and will send a notification to the Group owner if it is no longer active for a period of time as configured by an administrator. The great thing about this is it includes all parts of an Office 365 Group (Mailbox, Planner, SharePoint, etc.) when the Group is expired (deleted). Group expiration also applies to Microsoft Teams.
The interplay of Group Expiration and Retention… Information Management teams for customers I work with are concerned about end-users (site owners) having the permission to approve group expiration in case there is important business information stored there… not to worry! Retention overrides Group Expiration! Here’s how it works together…
If a retention policy has been published to the Group expiring… the group’s conversations in the mail box and files in the group site are retained in the retention container (Recoverable items partition for Exchange and Preservation Hold library for SharePoint) for the specific number of days defined in the retention policy even if a Group owner approves its expiration. Users will not see the group, nor its content, after expiration however. The content remains discoverable for retention and eDiscovery.
If a label policy has been published and labels have been applied to content in the Group expiring… the group cannot be deleted for the specific number of days defined in the retention labels in use on the site, however it can be expired! If a Group owner approves its expiration, the site will be retained but will not be visible to users.The content remains discoverable for retention and eDiscovery.
Reference link: Office 365 Group Expiration Policy
What about a Site Policy? (classic)
This is the classic (legacy) method for making a SharePoint site read-only allowing for its eventual deletion once approved by a site owner.
Microsoft is recommending discontinuation of this feature in favor of the other modern options discussed in this post. (Link: Use a retention policy instead of these features)
Despite Microsoft’s recommendation, I mention this classic option only to highlight the capability it has and how the modern world of retention does not have a 1:1 replacement for it in case you’ve been looking for one. As with other features across Office 365, there’s not always an exact replacement. You should assess what you are using this policy for in the first place with an eye to modernizing the options to accomplish the same thing, but in a different way.
Considerations to stop using Site Policies:
- new investments by Microsoft are in the modern world of retention and not in the legacy world. This is a compelling reason to discontinue the use of net new site policies across your tenant and favor modern techniques instead
- the site policy option won’t appear for a site associated with an Office 365 Group. With so many group-backed sites being provisioned across organizations today (Microsoft Teams, group-backed Modern Team sites), you need to utilitize the modern alternative(s)
- although this policy will continue to work (and is supported) for classic SharePoint sites and those not associated to a Group, it’s important to understand the pros/cons of using this policy before doing so. A Site Policy is still a supported feature and is an appropriate choice for classic SharePoint sites when modern alternatives don’t meet your needs.
Reference link: Use policies for site closure and deletion
Which modern option do we use?
Let’s get back to the 4 requirements at the beginning of this post and how we could accomplish them using only modern policy options:
There is no one-size-fits-all modern approach for this requirement. The technique you use will largely depend on the type of site, how strict the requirement is, and what tools you have available to accomplish it.
- Remove all member/owner permissions effectively making the site read-only. Depending on your regulatory requirements, this technique may not be sufficient.
- Modern Team site without an Office 365 group – set the SharePoint site read-only via PowerShell (Set-SPOSite). This is a good option if you are controlling the site provisioning/archiving process thru automation. Once you do this, a message will appear above the site navigation:
Set-SPOSite -Identity “your site URL” -LockState ReadOnly
- Modern Team site with an Office 365 group – there are several workloads to consider for an Office 365 Group when making it read-only which is why I would caution against only making the “site” read-only. (SharePoint site, Exchange mailbox, Planner, Stream,…).
- Microsoft Teams (Archive or delete a team in Microsoft Teams) – archiving a Microsoft Teams will freeze all Teams activity, including the option to make the associated SharePoint site read-only. This can be done either thru the UI (image) or via PowerShell. Great option!
A Group Expiration policy would accomplish this, however if you need to ensure content with business value will not be inadvertently removed when the group is expired (something Information Management teams I work with are concerned about), ensure you have either a retention policy or retention labels (via label policy) applied to the content within.
The Group Expiration policy will detect when a site is no longer active by determining if any of these things below have happened during the expiration period, and if not, will start the group expiration approval process:
If you have used the “Archive” feature for a Microsoft Team, the Group Expiration policy will override it and, if up for expiration, will still expire the Team.
A Group Expiration policy or a label policy could be used to introduce an approval process.
- if you want the entire container (Group) to be approved, a Group Expiration policy will do the job
- if you want each individual document/email to be approved, a Retention label policy will do the job. A disposition review process can only be introduced into the process if retention labels are used, not retention policies. A disposition review process will require an approval of each item up for removal, something that many regulations require
- our friend, Microsoft Flow, could provide an approval mechanism for most business processes, including content deletion. The feasibility of this approach will depend on the scale you need the content-deletion approval process done (across an entire tenant would not be feasible)
A retention policy or label policy can be used to accomplish this. Which one you choose depends on your organizational file plan, retention requirements, and the license you have. Retention labels can be manually applied, automatically applied, or (available soon) applied thru machine learning with trainable classifiers. Retention policies are for broad, container-based retention where everything in the container adheres to the same retention rules.
The options can be confusing. This is particularly true if you’re using more than one policy on the same “container”. (Outlook mailbox, SharePoint site, Teams, etc.). This is why it’s crucial to understand the interplay between them, their effect on the resulting content, and the end-user impact.
Organizations in regulated industries need to understand this interplay as they work towards meeting their regulatory requirements.
Thanks for reading.
Credit: Photo by Prateek Katyal from Pexels
Very important insights here Joanne, as always. To note, I can see the lack of an alternative (other than automation or manual methods) to classic Site Policies for non-Groups-connected sites dictating that customers will continue to use those for some time for those sorts of sites. For Comms sites, I can see this being less of an issue, as there tend to be fewer of these and they’re typically longer-lived. For otherwise non-Groups connected sites, I guess the choice is then: manual, automated or Site Policies for now.
Thanks Todd I’ve updated the wording in the post to indicate a Site Policy is still an option in the right conditions.