Modern vs Classic IN PLACE Records Management in SharePoint

There are fundamentally two ways to manage document records in an enterprise. They’re either managed in a separate repository from where they were created OR they’re managed in place in the same location they’re created. This post talks about the latter (in place) method of Records Management (RM) in SharePoint and how it’s changed from the legacy to the new modern world of RM.

For the remainder of this post, I’ll refer to “in place” record declaration implemented thru the legacy site collection feature as Classic and the “in place” record declaration feature implemented thru Compliance retention labels as Modern.

IMPORTANT! Microsoft has clearly stated their recommendation to discontinue use of the classic in place records management feature and replace it with retention labels/policies. All new technology investments by Microsoft will be made toward the new, modern model. This means any new records management work in Microsoft 365 being done by customers today should use the modern capabilities.

Short on time? Skip down to where I talk about key differences and advantages of the Modern way.

In Place RM… the Classic way

In the legacy SharePoint world, a site collection feature called In Place Records Management is activated to allow you to declare a document a record. Once activated, it adds an additional option called Record Declaration Settings in several locations: under Site Collection Administration and each list and library within the site. At the site collection level, it allows control of these things:

• Record restrictions (None, Block Delete, Block Edit and Delete)
• Manual record declaration allowed or not
• Who can declare/undeclare a record (contributors, admins, both, automated)

At each list/library level, it allows control of these things:

• Use the above site collection settings by default OR
• Allow/disallow manual declaration of records OR
• Automatically declare every document/item added to the library/list as a record

Note: for the remainder of this post, I’ll discuss document record declaration, not item record declaration since the vast majority of records are documents.

Once a record has been declared in place, these things happen:

• yellow lock symbol appears on the file type icon
• you cannot edit/delete the properties or content of the document (according to site collection setting)
• Declared Record column is added to the library and populated with current time
• Note: Item is a Record column is NOT set to yes

For each document, you can select Compliance details from the context menu displayed when you click the 3 dots beside the document. When clicked, it shows information about the document’s in place record status and when it was declared:

In Place RM… the Modern way

Microsoft recommends the use of Retention Labels instead of the in place record declaration method above. How does this work?

When defining a Retention label, you can optionally specify whether or not you want the label to make the document a record or a regulatory record by a simple checkbox on the label definition. Once a record label is applied to a document, these things happen:

• lock symbol is displayed beside the file name
• Retention label column is updated with the label applied
• Retention label Applied column is populated with current time
• Item is a record column is set to Yes
• for regular records:
  • the label can’t be changed (except by a site collection administrator)
  • the label can’t be removed (except by a site collection administrator)
  • the label can’t be changed by anyone
  • the label can’t be removed by anyone

  

  Although viewing the Compliance details dialog box is still available for content with a modern Retention label applied, you should not rely on the information shown (use for classic retention only). There is currently no place to see the deletion/expiration date for an item with a retention label applied.

  Differences between Classic and Modern In Place Record Declaration

  Can you update document metadata when it’s a record?

  • Classic: Depends. If you have the site collection setting to Block Edit and Delete , no one can edit the document’s properties. The document needs to be undeclared a record first. If the site collection setting is Block Delete , you will be able to edit the document’s properties.
  • Modern: Depends if it’s a regular record or a regulatory record. A regulatory record’s metadata cannot be changed once the label is applied. (even by a site collection administrator, records administrator, or global administrator). For a regular record label, there is a new tenant setting in Records Management to control the edit behavior at the tenant level (image):

  

  • • If the above feature is enabled, any user with permission to update metadata on a document (contribute and above), can continue to update metadata even when a document has been declared a record. All updates are audited.
    • If the above feature is disabled, editing document metadata will be prevented

    Can you modify a document’s content if it’s a record?

    • Classic: Depends. If you have the site collection setting to Block Edit and Delete , no one can edit the document. The document needs to be undeclared a record first. If the site collection setting is Block Delete , you will be able to edit the document.
    • Modern: Depends if it’s a regular record or a regulatory record. A regulatory record cannot be changed once the label is applied. (even by a site collection administrator, records administrator, or global administrator). For a record label, there is a new tenant setting in Records Management to control this at the tenant level (image):

    

    • • If the above feature is enabled, an end-user would have to unlock the record (a toggle provided on the document’s detail pane) which would create a new record version and allowed an end-user to edit the contents.
      • If the above feature is disabled, no edits will be allowed to the contents of the document. The document will open in read-only mode and can’t be changed regardless of your permission level. The label must be removed or changed to a non-record label in order to modify the document (by a site collection admin/group owner).

      Can you automatically declare each document in a library a record?

      • Classic: Yes. A library setting called Record declaration settings will allow you to automatically make all documents added to the library a record.

      

      However, once set, this will also change the setting to require check-out on each document as is described in the pop-up below:

      

      • Modern: Yes. A library setting will allow you to default all documents within the library with the retention label. Only a site collection administrator can remove/change a regular record label from a document. Other users cannot.

      

      Out-of-the-box, can you make a document a record based on one of its properties?

      • Classic: No. A Custom Information Management policy would need to be written to do this and then applied to all content locations across your environment.
      • Modern: Depends on the type of record label… you cannot auto-apply a regulatory record to content. For a regular record label, the auto-apply feature can leverage metadata and content types to apply it to a document.

      Can you filter all records in a library?

      • Classic: Yes. Filter based on the Declared Record column not equal blank
      • Modern: Yes. Filter based on the Item is a Record column equals Yes

      Can you apply these solutions at-scale across a tenant?

      • Classic: Yes. Create a Site Collection information management policy on the root site of a site collection with the retention settings set to declare a record when applied, and then import that into all site collections requiring it across the tenant. Associate the policy to content types and libraries across the site as required. Note that the application of the record information management policy to documents is dependent on several Timer jobs and therefore is not immediate.
      • Modern: Yes. This is a significant improvement over classic as it works with all modern workloads (all types of modern SharePoint sites including group and non-group backed sites). Publish the retention label to all sites in your tenant or use the new adaptive scope feature to selectively include/exclude sites/groups/teams on the policy. Note that the application of the retention label is dependent on a timed process and is therefore not immediate.

      Can you undeclare a record?

      • Classic: Depends on the site collection setting. Options are: all list contributors and administrators, only administrators, or only thru a policy action (automated).
      • Modern: Only a site collection administrator can remove/change a regular record label from a document. Other users cannot. If it is a regulatory record label, no one can remove/change the retention label once applied to a document.

      Advantages of the Modern Model over Classic

      • Scalability. You define the record retention label once in the Compliance Center and, if published tenant-wide, can use it on any document library across the tenant. I think this is an easier setup from an administration perspective than the legacy Information Management Policy approach. A retention label can also be published to multiple workloads. This post demonstrates publishing to SharePoint, however they can also be published to OneDrive and Outlook. The new adaptive scope feature also makes the publishing of retention policies and labels very scalable as the locations it’s published to is based on conditions you provide.
      • User interface. Applying a record label manually is as easy as applying a piece of metadata on a document because it shows on the property pane alongside regular metadata. This is easier/quicker than opening up the Compliance details dialog and clicking the link to declare the document a record which is what is required in the Classic world.
      • Bulk manual declaration. The Modern model will allow many documents to be selected at once and a label applied to it. You cannot do this with the legacy in place model.
      • Analytics. There is better visibility into content across your organization with a Record label with the Activity Explorer and Content Explorer inside the Data Classification feature of the Compliance Center. Also, the label activity dashboard provides a quick visual glance of label usage. Many record activities are audited allowing you to build custom reports to suit using the Office365 Management Activity API.
      • Immutable record labels. With a regulatory record label, you’ll be able to tag documents with the label making it irreversibly unchangeable and undeletable. I see this as a needed regulatory requirement for some organizations, particularly in the Finance industry.
      • Technology investments. Microsoft has clearly stated their recommendation to discontinue use of the in place records management feature and replace it with retention labels/policies. All new technology investments by Microsoft will be made toward the new model. This means any new records management work in Microsoft 365 being done by customers today should use the modern capabilities.

      Thanks for reading.

      Share this:

      Like this:

      Like Loading.

      19 comments

      Kent says:

      If the future is labels, what about those still using on-premise SharePoint for records management who for security reasons can’t use O365?

      Joanne Klein says:

      Hi Kent, since Retention labels are a cloud-only records management solution, I would *think* you should stick with the traditional records management capabilities in SP On-Prem. (e.g. deletion policies, information management policies, records center, site closure policies, etc.)
      -JCK

      Damien says:

      Hi!
      Now that I am conscious of how great this site is, I read all! Brilliant overview! One comment and one question:
      – for quality document management, once a document is a record you cannot change anything; so I cannot imagine one of my customers agree to use labels…
      – once again, why is Microsoft creating a new way of achieving things, instead of improving existing ones? Modern vs classic, workflows vs Flow, records vs labels…

      Joanne Klein says:

      Hi Damien, a label doesn’t have to declare the document a record, that’s an option when you’re defining the label. Declaring a document a record is a typical Records Management regulatory requirement in an organization… whether you do it in-place (like a retention label does) or move it to a records center is a business process decision for what makes sense in your scenario.
      -JCK

      Gil Roitto says: This full coverage article is gold. Thank you! Ingeborg Hawighorst (MVP) says:

      Hi, how can I migrate in-place records from SP Server 2013 to SP Online? The SharePoint Migration Tool just leaves them behind. Any tips?

      Joanne Klein says:

      Hi Ingeborg,
      I’ve never tried this so have no experience to lean on. Do you need to have a similar setup configured on the SPO side? I would submit a question on the MVP forums to assist.
      -JCK

      Raj SB says:

      Excellent article, and few questions answered! Just one question I encountered on the best practices. Is it something recommended in any scenario to completely lock Records Center for even READ access and the access need to be requested with approval (may be via a workflow)? I see this as a nightmare of approval emails flooding the approver. Naturally, the permissions should be based on the security classification or User Access Policy right? in both Document Library or in Records Center. What you all suggest?

      Joanne Klein says:

      Hi Raj, this is a big question and one I’m not going to be able to answer without asking many more questions. Nothing like this is “best practise” unless there’s a good business reason for doing so. In my career travels, I’ve never seen an approval mechanism built in front of a records center. This sounds like a lot of noise. Typically access it controlled by permissions alone.
      -JCK

      Zapp says:

      Joanne – question, does a Record Manager need permissions on the SharePoint Online site collection in order to manage records on that site, or is Records Manager all they need?

      Joanne Klein says:

      Hi! Permissions are separate between the Compliance Center and SharePoint sites. E.g. Records Managers need to be granted the Disposition Management role in the Compliance Center to view Record dispositions. They *also* need access to the site collection if they want to view any of the documents/records being disposed of on the site.
      -JCK

      Dawn F says:

      Hi. I migrated SP2013 site collections to SharePoint online in the last two years. Now one of the groups (tax) would like me to delete a large volume of Classic Declared as a record files/their respective libraries. Is there a way to mass undeclare a record inside a library without powershell?

      Joanne Klein says:

      Hi Dawn, I’m sorry I don’t know. I suspect some custom code or PowerShell will be required to remove the record property in bulk by design.
      -Joanne

      Franck says:

      Hi, I am trying to find “the technology” behind records / regulatory records. How is the immutability guaranteed and how can i prove it to a regulator? is a hash created when the record label is applied? Or is it pure access restriction?
      Thanks, Franck

      Joanne Klein says:

      Hi Franck,
      Not sure I’m going to answer your question to the level you’re looking for, but I’ll give it a shot. I’ll use the SEC 17a-4 regulatory requirements as an example. It is much more than access restriction. The software control that Microsoft has implemented for the write-once-read-many (WORM) requirement is a combination of configurations in Microsoft Purview. Either a retention policy configured with a preservation lock on it OR a regulatory record label published in a label policy with a preservation lock. When either of those conditions are met, no one can turn off the policy or remove content from being under control of the policy. (not even a global administrator). This is what guarantees the content cannot change. There are numerous other aspects that must be considered from the regulator’s perspective as well including the encryption of the content, etc. which is well documented from the Microsoft perspective. Their is a report written by an independent body, Cohasset Associates, that explains how Microsoft can meet the regulations of SEC 17a-4 if the controls are configured correctly. Here is a link from the Trust Center which may help: https://servicetrust.microsoft.com/ViewPage/TrustDocumentsV3?command=Download&downloadType=Document&downloadId=2dc92867-5f83-49d8-ad04-9e7295c9e40e&tab=7f51cb60-3d6c-11e9-b2af-7bb9f5d2d913&docTab=7f51cb60-3d6c-11e9-b2af-7bb9f5d2d913_FAQ_and_White_Papers Note: There are some proposed changes that may be coming to the SEC regulation that may change the configuration required in Microsoft 365 to meet the regulation.
      -Joanne

      Jenna says:

      I am working to migrate SharePoint Server 2016 to SharePoint Server 2019 and the vendor I hired gave me a report listing about 10,000 ‘checked out’ files that won’t be migrated unless checked back in. The existing site was created by my predecessor and was built over a 12 year period and I believe started out life as SP 2010. Due to my only taking over at the beginning of 2020 and having to learn/teach myself what all the site was built to do and how the staff in the office use it, I am continually finding myself blindsided by strange things setup by the guy who was not a trained IT person but began working in the office as an intern and worked his way up. Anyhow, long story long…. I have been going through the spreadsheet provided by the ‘assessment vendor’ of the checked out files and some yes are just checked out by staff who don’t understand how to use Sharepoint. However, I also discovered that a MASSIVE amount of the 10k are not actually ‘checked out’ they are instead archived data in the Record Center and have all been Declared Records as they were generated. As I understand it they will not migrate in that status so I began Undeclaring them as Records – one by one in the Advanced – Compliance submenu, no less 🙁 If these are Declared Records in order to protect the content and keep them from being edited or modified, then I imagine it is important that I lock them back down again but I do not really understand if I am ‘messing up’ or ‘breaking’ anything by undeclaring hundreds and hundreds of documents no longer records.