Folders provide a simple way to group content on network file shares. But, while they may look the same in SharePoint (or in a synced library in Windows File Explorer), and are the default way to group content in Teams-linked SharePoint sites, they are not always the best way to aggregate let alone manage digital records, especially high value records or records that require unique access controls and permanent retention.
This post explains why.
What is an aggregation?
According to the international standard ISO 16175:2020, Part 1, ‘Functional requirements and associated guidance for any applications that manage digital records’, aggregations:
- Are accumulations of related digital records.
- May reflect relationships such as shared characteristics or attributes, or the existence of sequential relationships between records.
- Can collectively constitute a narrative of events in which the records may have a sequential relationship with each other, determined through the metadata associated with the records.
- May be formal, structured relationships or may exist as less formalised (but) tightly bound metadata relationships that establish links between related records.
- (Section 7.5.3, paraphrased)
On the face of it, the definition doesn’t seem to prevent the use of folders to aggregate records. But the standard becomes more specific. It must be possible to:
- Enable the capture and maintenance of metadata for both records and the aggregation. (R1.2.1)
- Associate records at individual object and/or aggregation level to their business context. (R1.3.1)
- Allocate an appropriate retention and disposition period for every record and record aggregation. (2.1.1)
- Support the migration or export of aggregations. (R2.2.1)
- Ensure that the content of records, and their metadata, can be fixed or protected from unauthorised access, alteration or destruction. (R3.1.1, R3.2.1, R4.2.1 – 2)
There are several other highly desirable requirements, but the mandatory requirements above should be sufficient to make the point that folders aren’t the greatest way to manage records.
Metadata
All metadata in a SharePoint document library is set at the library level – either by adding a content type that includes site columns, a site column, or a ‘local’ library column.
You cannot set unique metadata on folders, although you can set (via Library Settings – Column Default Value Settings) a default value for individual folders that gets inherited by the items in the folder.
All items in a library, regardless of how they are grouped by folder, have the same metadata elements.
This may not be an issue for smaller organisations, but in larger organisations there may be a need to apply unique metadata to records. This requirement is harder to achieve using folders.
Context
Folders in a SharePoint site exist in document libraries. The site/library URL path shows where they are situated:
- tenantname.sharepoint.com/sites/sitename/libraryname/foldername/subfoldername etc
The ability to identify the business context for the records will depend to some degree on the sitename/libraryname combination and how much content is stored on the site. Smaller organisations may find it useful to have a single Team for, say, Corporate Services, and create channels that map to separate business functions with no requirement for different metadata, access controls or retention – e.g., Financial Management, Property, Legal etc.
Larger organisations may find this model becomes very complicated once other factors and requirements for different metadata (set at the library level), access controls and retention are taken into account.
Retention
Two types of retention can be applied (from the Compliance admin center) to content stored in SharePoint:
- Back-end retention policies that create a Preservation Hold library on SharePoint sites. These policies work in the background and do not include any form of disposition review.
- Retention labels published as label policies to SharePoint sites or auto-applied. Some labels may include disposition reviews, the ability to declare records, and lock records entirely with the regulatory option (E5 licence only).
Once they are published to a SharePoint site, retention labels may be applied at the library, folder or individual item level. The image below shows how to apply them to a folder.
When applied at the folder level, all the items in the folder will inherit the label. However, if the records are not locked when the label is applied, end-users with edit rights can remove the label.
If records are grouped in folders in a document library, someone (the records manager, the site owner, the end-users?) will need to ensure the correct label has been published to each folder. Applying labels – and the rights ones – to folders becomes more complex when the library contains a mix of retention periods, and even more so if there are permanent and temporary records.
If labels include the option for a disposition review, someone will need to manage that process. Permanent records may need to be transferred to archives; this is a much harder process compared with storing all related records with permanent retention in the same document library.
Again, this may not be such a problem for small organisations, but in larger organisations, the application of specific retention labels to multiple folders in a library will start to become very complex process that will be difficult to manage over time.
Migration
Moving records within the same library in SharePoint or even to a different site is generally straightforward, although the ‘Move’ option should only be used to move a small number of items at a time. Third-party tools should be used to move larger volumes of records.
As noted above, every item in a SharePoint library shares the same metadata columns. Migrating or exporting the content of a folder will generally also require the migration of the metadata as well. Records with permanent value that have to be transferred to an archive will typically have more metadata compared with temporary records. How will this metadata be extracted?
Access controls
It is not unusual, especially in Teams-based SharePoint sites, to see separate access controls being applied to (channel-linked) folders or even sub-folders in a document library. This involves breaking the existing permission inheritance and adding unique users.
While this may seem like a good idea in the short-term, the creation of unique access controls via folders is a poor way to restrict access to records.
Records that have unique access control permissions would be much better stored in a separate document library, or even a separate SharePoint site.
Disappearing folders
Every SharePoint library has a default ‘All Documents’ list view and the ability to create multiple alternative views. The content in the library can be grouped, sorted or filtered as required.
And, unlike folders in File Explorer, folders in these views can be made to ‘disappear’ in the browser view (and also via Teams) through the ‘Folders’ setting shown above. The documents still retain their original URL folder path (which can be seen when you click on ‘Copy Link’ – in the example below, the document is stored in the ‘July’ folder).
- tenantname.sharepoint.com/:b:/r/sites/CorporateRecords/Meetings2021/July/ExamplePDFC.pdf
If the organisation has created a folder-based structure to group and manage records, what will happen if someone disables the ability to see folders? All they (and everyone else) will see will be the documents (that they have permission to access).
The ability to make folders disappear highlights why folders are a poor way to aggregate content. When the folders vanish, how do you group or manage records?
A better approach – keep it simple
Aggregating records in folders may seem like a straightforward thing to do, especially via Teams-linked channels, but if the records stored in the same library have competing metadata, retention, and access control requirements, it will become a nightmare to manage them over time.
A much better model is to use document libraries not folders as the logical ‘containers’ for records, or separate sites with multiple document libraries, with metadata as required, specific retention and inherited access controls.
Teams-based SharePoint sites may be suitable for storing some records, but only if all the records (a) relate to the same business context, (b) share the same metadata, (c) have the same access controls and (d) the same retention requirements.
The bottom line – Try to avoid over-complicating the management of records early on. It will only make it harder to manage records longer-term.
Records about the world 
One thought on “Avoid using folders to aggregate records in SharePoint”