I have previously written about how to automate M365 Information Governance and Records Management, and I will in this post explain your Microsoft Records Management options for active collaborative spaces. In most scenarios, only the user will know when a collaborative document is final and should be declared as a record.
Option 1: Get users to manually select and apply a Record Label to the file.
Record labels are published for users to manually select and apply the correct label
Pros:
-
The file immediately get a record label that locks the file from further changes and deletion
Cons:
-
Users needs to understand the value of labels in M365. This is not only for applying a label, but for using labels as search results filters. They need to understand that labelled files are the final and most important files when looking for information.
-
Users need to select the correct label for records. If too many options, you get label overload, and this can be mitigated by only publishing relevant labels during site provisioning, e.g. only HR labels published to HR sites
-
Not connected to document status for tagging or search, e.g. draft, final
Option 2: Get users to manually select Document Type and Document Status, which auto-apply the correct Record Label
Auto-apply record labels based on two metadata fields: Document Type (e.g. document hierarchy) and Document Status (e.g. draft, final, expired, with draft as default). These metadata fields can then also be used as search results refiners.
Pros:
-
Improves findability by enabling users to search for Document Type and Document Status
Cons:
-
Require users to select Document Type metadata per file
-
Require users to set Document Status to final when files are final
-
It may take up to 7 days before the system auto-apply a record label based on metadata
-
Require Document Type and Document Status metadata to be stable over time since replacing or updating values will negatively impact the user experience and make administration very complex and time consuming
Option 3: Set Record Type metadata as default on storage container, and get users to change Document Status to Final for auto-applying a Record Label
When you have big-bucket retention categories, you can then use the categories as Record Type metadata that is set as default on the storage container. Once a user changes the Document Status to Final (draft can be default), the correct Record Label is auto-applied by M365. If each Record Type has unique metadata requirements, then this can be managed with Content Types.
Pros:
-
Improves findability by enabling users to search for Document Status to find the final files (records).
-
Document Type can be another metadata field if it brings value, and it can be updated when required without impacting the Records Management settings as long as any new Document Types fits within existing Record Type / Big Bucket retention categories.
Cons:
-
Require users to set Document Status metadata to final for final files
-
It may take up to 7 days before the system auto-apply a record label based on metadata
Option 4: Set a Record Label as default on a document library or folder, and get users to store final files in this library or folder
Pros:
-
The file immediately get a record label that locks the file from further changes and deletion
-
You ensure the final files are the approved files
Cons:
-
Users need to store only final files in the appropriate library and folder. If storing a draft file there, it will be locked immediately.
-
Users need to understand the value of labels in M365 when searching for files. They need to understand that labelled files are the final and most important files when looking for information.
-
The framework will fail when site owners and users change the folder structure without considering the record label.
Option 5: Use PowerAutomate approval workflow to set a Record Label for approved files
Pros:
-
The file immediately get a record label that locks the file from further changes and deletion
Cons:
-
The workflow needs to be set up per site
-
Users need to use or trigger workflow to get record declared, which will often not cover all scenarios
-
Users need to understand the value of labels in M365 when searching for files. They need to understand that labelled files are the final and most important files when looking for information.
Option 6: Use PowerAutomate approval workflow to set Document Type, Document Status metadata
Pros:
-
You ensure the final files are the approved files
-
Improves findability by enabling users to search for Document Type and Document Status
Cons:
-
The workflow needs to be set up per site
-
Users need to use or trigger workflow to get records declared, which will often not cover all scenarios
-
It may take up to 7 days before the system auto-apply a record label based on metadata
Option 7: Use keywords, KQL and/or RegEx to auto-apply Record Labels
You can use Sensitive Information Types and auto-apply policies to automatically apply Record Labels when it finds keywords, keyword query language, and/or regular expressions. This searches for specific word, phrases, or patterns in files and auto-apply a Record Label, e.g., find case numbers, agreement numbers.
Pros:
-
Automates record identification and declaration
Cons:
-
May result in many false positives
-
Require ongoing monitoring to modify configuration when content changes
-
Will not separate draft vs final files, therefore not good for active collaborative spaces
-
Will take some time before M365 find and declare the record
Option 8: Use SharePoint Syntex and/or Trainable Classifiers to automatically set a Record Label
SharePoint Syntex (image below) and/or Trainable Classifiers can be used to automatically identify records and auto-apply a Record Label. This is a good option for static or archived sites, but not active collaborative spaces since the software won´t know if a user is still working on the file.
Pros:
-
Automates record identification and declaration
Cons:
-
Time and effort are required to train the software
-
Will not separate draft vs final files, therefore not good for active collaborative spaces
-
Will take some time before M365 finds and declare the record
The key to success is users. We need them to take action when a file is final in collaborative spaces. To get them to do it, they needs to see the value of doing it, and it needs to be easy to do. Compliance will be about providing value, not just telling users that they have to do it.
Option 1 with manual record labelling is easy to implement for IT and IM teams, but success will depend of users understanding the value of labels for tagging and search. We therefore recommend the other options that rely on Document Status metadata since it is more intuitive for users to think about draft vs final files when tagging and searching for information.
Option 2 with auto-applying record labelling based on Documment Type and Document Status metadata improves findability and governance, but more complex for IT and IM teams to set up and maintain. If the document type metadata is not stable over time, this creates complexity for admins managing the retention schedules.
Option 3 with a default Record Type metadata simplifies things for users since they only have to consider Document Status, but this option is also the most difficult for IT and IM teams to implement since it require big-bucket records retention categories. This is where we at Infotechtion can help. We can establish big-bucket retention categories for you before creating and implementing a design blueprint for Microsoft Records Management.
Option 4, 5, and 6 are good options for specific scenarios, but not as a generic approach for all users. Use these options when it makes sense, e.g. approval process for final engineering drawings, storing contracts in a contract library.
Option 7 and 8 are good automation options for migrated content or non-active sites, not (currently) for active collaborative spaces.
Please feel free to contact us if you need help determining and the test the best approach for your organization.
Below are some blog posts that may be of interest.
