There are many things to consider when applying retention to your SharePoint Online content, and each decision you make will have follow-on effects to be aware of. I’m writing 4 posts to highlight 4 key questions to answer when configuring Office 365 retention and will identify some pros and cons of decisions surrounding each:
This post is the first in the series, Retention in SharePoint Online: The Where, What, How, and When, and answers the all-important “WHERE” question:
- Part I: Retention in SharePoint Online: The “WHERE” (THIS POST)
- Answers the question “Where should retained content live?”
- Part II: Retention in SharePoint Online: The “WHAT” answers the question “What type of retention should be applied?”
- Part III: Retention in SharePoint Online: The “HOW” answers the question “How should the retention be applied?”
- Part IV: Retention in SharePoint Online: The “WHEN” answers the question “When should the retention start?”
I think the image below sums up the retention scenario across Microsoft 365. Knowing you need it is only scratching the surface (which is partly what this blog post series is addressing)…
Let’s answer “The WHERE”…
Where should retained content live? The decision you make on where to retain the content has an impact on several things and can matter a great deal as you’ll soon see. I’ll cover 4 options I’ve seen used in the field. As an organization, you will likely use every one of these location options at times to cover off your complete retention requirements:
Disclaimer for “Custom Code/Solution”
Anywhere in the remainder of this post where I refer to custom code/solution setting retention, can be accomplished using any of/combination of these techniques:
- Power Automate
- PnP PowerShell
- Security & Compliance Center PowerShell
- CSOM
- Microsoft 365 REST API
I will talk about these in my upcoming post, “Part III: the HOW”, however in this post I’ll just refer to them collectively as custom code/solution.
Move documents into a separate archive site
You might want to consider this option if:
- you require different permissions for content once it’s under retention
- you want to move records to a different location for search (include or exclude)
- you anticipate a very high volume of content under retention and want to store it in a separate site for scale
- you want a central records repository across your tenant
Note: Although it will continue to work, Microsoft no longer recommends using the Classic Records Center site template going forward, but instead recommends Retention policies/labels. To be clear, there is no modern built-in site template equivalent to the Records Center. It can be replicated by a Communication site (or Modern Team site without a Group) and some retention configuration and permission.
Option 1: Apply retention via a retention policy for entire archive site
Create a retention policy and publish it to the SharePoint Archive site. All content in the archive site (libraries, lists) would be subject to the policy. You could move content to the site either manually or automatically. This does not preclude you from ALSO publishing retention labels to the site for more targeted retention needs. (next option)
PROs:
- For stricter control and governance, you could build custom code to move content to be retained to the Archive site based on some metadata, condition, or event
- Permission-trim the Archive site so only the Service Account running the Power Automate has permission to write to it. You could make the archive site read-only to everyone else
- Retained content is held in a ‘Preservation Hold library’ on the Archive site and is only visible to the Site Collection Administrator. If you have reduced permission on the archive site to read-only by everyone, then this library would effectively never be used
- Content on the archive site is searchable by eDiscovery and Content Search while it’s being retained
CONs:
- NO Disposition Review on content is available via a Retention Policy – meaning if the retention policy is configured to delete content, it will be deleted automatically once the retention period has been met
- If you didn’t automate the move to the Archive site, you would be relying on a human to do the move correctly all the time. Not always a wise choice.
- If you DID automate the move to the Archive site, the custom code/solution needs to be built and maintained (technical debt)
Option 2: Apply a Retention Label to the content on the Archive site
Create a retention label and publish it to the SharePoint Archive site. It could be set to start retention on the labeled date. Content would be moved to the site and retention label applied to the content OR the library which it is being moved to could have the retention label set as default.
PROs:
- Could automate this by building custom code to move content to be retained to the Archive site based on some metadata
- Can permission-trim the Archive site so only the Service Account running the custom code/solution has permission to write to it. You could make the archive site read-only to everyone else
- Content on the archive site is searchable by eDiscovery and Content Search while it’s being retained
- Disposition Review on content is available on content covered by a Retention label
CONs:
- If you didn’t automate the move to the Archive site, you would be relying on a human to manually move the content to the archive site
- If you DID automate the move to the Archive site, the custom code/solution needs to be built and maintained (technical debt)
- Retention label can be removed by anyone with at least contribute rights to the content (unless it is a record label and then that is restricted to a Site Collection Administrator). For this reason, you may want to restrict permission to the site.
Move documents into a separate archive document library on same site
You might want to consider this option if:
- you want to keep everything in the same site
- you want to treat the content differently for search (include/exclude)
- you want to have different permissions on content under retention
- you want the ability to restrict who can move a document to the archive library
- you want to keep records under retention out of the main library
- you have different metadata on the archive library from the main library
Setup: A retention label has been set as default on an Archive library. Any documents or folders moved to the library will inherit the retention label. Permissions could be set on the Archive library to restrict access to a select group.
Option 1: Manually move documents/folder from 1 library into an Archive library
This would have to be done by an administrator on the site if permissions were restricted on the Archive library to only have administrators with edit access. You can move either a document or an entire folder by using the Move to toolbar option.
PROs:
- If documents being moved happened to be open by an end-user at the same time, the administrator doing the move will receive an error in the UI notifying them of this conflict. They can then follow-up with whoever has the file(s) locked. I’m calling this a PRO because you can resolve the error “in the moment”
- Administrator can move either an entire folder or document using the ‘Move to’ option on the toolbar ribbon
- Once a document or folder is in the Archive library, it can’t be manually deleted or moved out of the library by regular site users if you’ve restricted permissions
- You can have a disposition review on content with a retention label
CONs:
- This option is not available for document sets since you cannot move a document set to anywhere outside of the library it’s in (as of March 2020)
- An Administrator would have to move the folder or document to the Archive library if you wanted the permissions restricted on the Archive library
- Retention label can be removed by anyone with at least contribute rights to the library (unless it is a record label and then that is restricted to a Site Collection Administrator). For this reason, you may want to restrict permissions on the archive library.
Option 2: Use custom code to automate move of documents from 1 library into an Archive library
PROs:
- Custom code/solution can move a folder, document set, or document to a new destination library based on a metadata value as defined by the business process
- Custom code/solution can retain all metadata from the source and it will inherit permissions of the destination Archive library
- You can have a disposition review on content with a retention label
CONs:
- If documents being moved happen to be open by an end-user at the same time, the content will be copied, however it won’t be deleted out of the source location. There would have to be some error handling built-in to clean up the source location
- Requires custom code/solution to be built and maintained (technical debt)
Move documents into an Archive folder in same document library
You might want to consider this option if:
- you want to keep everything in the same library
- you have a simple folder structure at the top level of the library where the Archive folder exists
- you want to retain metadata once something is moved into the Archive folder
- you want to have restricted permissions for items under retention
- you want to be able to search exclusively within a library including content in the Archive folder
Setup: A retention label has been set as default for an Archive folder. The folder could be permission-trimmed to only allow access to administrators however this would mean only they could add something to the Archive folder. Once a document or folder is in the Archive folder, actions allowed would be dependent on the type of retention label applied (regular or record)
Option 1: Manually move documents into an Archive folder in the same library
PROs:
- Can use the built-in Move to toolbar option to do the move
- Can move a folder, document set, or document using the toolbar ribbon to automatically inherit the retention label of the archive folder (unless it has another retention label already applied to it)
- You can have a disposition review on content with a retention label
CONs:
- If there were custom permissions for the folder, document set, or document being moved, these would not be overridden when they’re manually moved into the permission-trimmed Archive folder. You may or may not want this as whoever previously had access to the archived folder, document set, or document would retain their access unless it was manually removed
- You are relying on end-users/administrators to do the move
- Retention label can be removed by anyone with at least contribute rights to the folder (unless it is a record label and then that is restricted to a Site Collection Administrator). For this reason, you may want to restrict permission on the Archive folder.
Option 2: Automate the move of documents into an Archive folder in the same library
Additional Setup: Archive folder would be permission-trimmed to only allow a Service Account to do the move and read-only for everyone else. Custom code/solution written to do the move based on custom logic/metadata value.
PROs:
- End-user doesn’t have to perform the move; the custom code/solution would perform the move based on an outside trigger or an end-user updating a piece of metadata to trigger the custom code to do the move (or they could manually launch a Power Automate from the ribbon)
- Custom code can move a Folder, Document Set, or document to a new folder in the same library
- When the Folder, Document Set, or document is moved to the Archive folder, it inherits the permission from the Archive folder even if the Folder, Document Set, or document has unique permissions
- End users would not be allowed to move the Folder, Document Set, or document out of the Archive folder due to permission restriction
- You can have a disposition review on content with a retention label
CONs:
- If documents/folders being moved are open by any end-user, the content will be copied, however it won’t be deleted out of the source location. There would have to be some error handling built-in to the custom code/solution to clean up the source location
- Requires custom code to be built and maintained (technical debt)
Retain documents in-place without moving anywhere
You might want to consider this option if:
- you want to keep everything in the same library
- you want to minimize the impact to end-users
- you’re not concerned about the volume of data in the same library over time
- you want to still allow collaboration on some items marked as records (unlockability)
- you want end-users to search exclusively within the library and for it to include all retained records as well
Setup: Publish a retention label to the site to start retention based on when something is labeled, but DON’T make it default on the library.
The options below will be further detailed on the HOW post!
Option 1: Manually set the retention label on the document, folder, or document set
PROs:
- Retention will start based on when content is manually labeled by an end-user. If a document set or folder has a retention label applied, all documents within will inherit the label (unless it already has another label)
- You can have a disposition review on content with a retention label
CONs:
- It’s up to the end-user to remember to set the retention label at the right time
- Retention label can be removed by anyone with at least contribute rights to the library (unless it is a record label and then that is restricted to a Site Collection Administrator)
Option 2: Use custom code/solution to set the retention label on the document, folder, or document set based on custom logic/metadata value.
PROs:
- Custom code/solution can automatically set the retention label based on a piece of metadata on the library (E.g. status, closed date, etc.) or any other custom logic
- Retention will start based on when content is labeled. If a document set or folder has a retention label applied, all documents within will inherit the label (unless it already has another label)
- You can have a disposition review on content with a retention label
CONs:
- Relies on end-user to set the metadata correctly to trigger the custom code/solution
- Requires custom code/solution to be built and maintained (technical debt)
Option 3: Auto-apply the retention label
Setup: Publish a retention label to be auto-applied based on a Content Type, Metadata, Keyword, or Sensitive information type and publish it to the site(s) where the content is contained. E.g. a metadata value of Status:Complete could trigger retention.
PROs:
- End-user simply has to remember to apply the correct content type/metadata value and the auto-apply engine will apply the correct retention label (if the auto-apply condition was metadata-based)
- If library or site path was used in the auto-apply condition, the documents just need to be placed in the correct library and the auto-apply engine will apply the correct retention label
- If sensitive information type was used in the auto-apply condition, any documents with a match on the sensitive information types would have the correct retention label applied by the auto-apply engine
- You can have a disposition review on content with a retention label
CONs:
- Relies on end-user remembering to set the right content type, metadata if your retention is auto-applied based on this
- It can take up to 7 days for the retention label to auto-apply
Option 4: Auto-apply the retention label based on an event
Setup: please refer to another post of mine: SharePoint custom metadata and Event-based Retention for the detailed setup on how to do this.
Note: Although not required, it’s best to use Document Sets for event-based retention to group the documents together relating to the event. (E.g. Project, Contract, Case file, etc.) as metadata (including the unique identifier required for event-based retention) is built-in to a Document Set which can be propagated to all documents within. A folder cannot (easily) do this.
In both options below, the event-based retention label is set as default in the library, folder, or document set and all documents within have the label applied.
Manually trigger the event
End-user browses to Records management…Events at protection.office.com and stores the event.
PROs:
- Everything tagged with the unique identifier and the retention label will be covered by the retention and retention will begin
- You can have a disposition review on content with a retention label
CONs:
- Manual effort by end-user to record the event (not intuitive)
- Retention label can be removed by anyone with at least contribute rights to the library (unless it is a record label and then that is restricted to a Site Collection Administrator)
- Can take some time for label to be applied (up to 7 days?)
Automate the event trigger with custom code/solution:
Use custom code/solution to automatically store the event based on a condition or custom logic. Refer to a previous post of mine where I document the steps to do this using Power Automate: SharePoint custom metadata and Event-based Retention.
PROs:
- You can have any kind of custom logic to start retention
- You can have a disposition review on content with a retention label
CONs:
- the retention label can be removed by anyone with at least contribute rights to the library (unless it is a record label and then that is restricted to a Site Collection Administrator)
- requires custom code to be built and maintained (technical debt)
Thanks for sticking with me. I hope you found this helpful and I’d love to know if you have any other considerations, pros, and cons you’ve come across when making the decision for WHERE to store your retained content in Office 365.
-JCK