Posted in Microsoft Teams, Products and applications, Records management, Retention and disposal

Managing inactive Teams in Microsoft Teams

The rapid and often uncontrolled rollout of Microsoft (MS) Teams as part of Microsoft 365 (M365) deployments from early 2020 has become a headache for many records and information managers. In many organisations, inactive Teams – some with no owners and inaccessible to records managers – litter the M365 landscape.

The introduction of private channels in 2020 added a new layer of complexity for the management of inactive Teams.

This post examines three ways to manage inactive Teams, especially those that may contain records.

  • Auto-expiration (and deletion) of M365 Groups.
  • Archiving Teams.
  • Applying (separate) retention policies to the elements that make up each Team.

It assumes that records and information managers will or should:

  • Take a leading role or be involved in decisions with IT departments around the creation of new Teams and the management of inactive Teams and their associated SPO sites.
  • Have access to the details of all active and inactive M365 Groups, Teams (including private channels), and SharePoint sites, including through role assignment (e.g., Global Reader, Compliance admin).
  • Know how and where Teams stores content in different applications.
  • Be directly involved in decisions about the creation and application of retention policies to Teams content, and disposition actions when those policies expire.
  • Where appropriate, be made the owners of inactive Teams (and M365 Groups) to allow them to review the content of that Team.

Option 1 – Auto-expiry of M365 Groups

Every Team in MS Teams is directly connected with an M365 Group; a Team uses the M365 Group’s EXO mailbox and SPO site for the storage of content. Therefore, if the M365 Group is destroyed, so will the Team and all its content.

Microsoft 365 includes the ability to automatically ‘expire’ and then delete all or selected M365 Groups after a given period of inactivity.

The Group’s expiration option is set in the Azure Active Directory (AAD) admin portal under Groups > Settings > General. This option includes renewal notifications (which will appear in Teams) and the ability to select specific M365 Groups (the default is None).

Azure AD Group Expiration

Pros of auto-expiry

Automatically expiring and then deleting M365 Groups can be a simple way to clean up inactive Groups and the linked Teams, based on the last activity of the Group or in the Team (SPO site, EXO email-based ‘conversations’, or channel posts). This may be particularly effective for general Teams that have been hardly used and/or known not to contain records.

Auto-expiry may be a useful option in conjunction with retention policies; M365 Groups and linked Teams subject to both will be retained beyond the expiry date if they are subject to retention policies.

If the expiry notification is missed or overlooked and the Team is soft-deleted, M365 Groups (and their associated Team content) can be restored for up to 30 days. The SPO site will be recoverable for 93 days. But, beyond 30 days the deleted M365 Group and all the content associated with it (including Teams) is irrecoverable (93 days for the SPO site).

Cons of auto-expiry

Auto-expiry is effectively auto-deletion without review. This option may work best for organisations with a relatively low number of Groups and/or where there is low concern or risk of deleting records prematurely. Organisations that are concerned about the deletion of records without review should be cautious of this approach.

Note that even if auto-expiry is set, this will not destroy any M365 Group or Team that is still subject to a retention policy – see below.

For more information about auto expiry of M365 Groups, see the Microsoft docs page ‘Microsoft 365 group expiration policy‘ and also ‘Team expiration and renewal‘ that shows how the M365 Group expiration notification works in Teams.

Option 2 – Archiving Teams

Any Team in MS Teams can be archived either by the MS Teams admin (via the admin portal), or by a Team Owner via the gear icon at the bottom left of the MS Teams application, next to ‘Join or Create a Team’. Clicking the gear icon opens a list of Teams; at the far right, the three-dot menu includes the options (including ‘Archive Team’) listed below.

The list of options for each Team.

The process of archiving a Team includes the option to make the linked SharePoint site read only, and makes the Team’s channels read only.

If the SPO site is not also made read only, the members of the Team can continue to upload and edit content via the Team’s channels or via the SPO site directly (and also via File Explorer for synced libraries).

Teams that have been archived appear in a separate ‘Archived’ section, from where they can be ‘restored’ (un-archived, made editable again) provided they are not subject to an auto-expiry policy or retention policies.

Pros of archiving Teams

Archiving Teams (and making the linked SPO site read only) may be a useful way to prevent any further changes to those Teams, but it does not do more than that. Additional options, including either auto-expiry (for low-risk Teams) or retention policies (for Teams with records) should be considered to ensure that inactive archived Teams are destroyed when this is allowed.

Archiving Teams may also be a useful way to ‘tag’ Teams that cease to be active, making them more easily identifiable for retention or disposal.

Cons of archiving Teams

Archiving Teams is not an effective or safe way to ensure that any records contained in the Team remain unchanged for as long as the Team still exists. It simply makes the Team’s channels read-only, and may also make the SharePoint site read only, if that option is selected.

If an archived Team is subject to an auto-expiry policy, it will be destroyed (with prior notification after a specified period. A better option for Teams used to create or capture records would be to apply retention policies to the Team.

For more information about archiving Teams, see this Microsoft docs page ‘Archive or delete a team‘.

Option 3 – Apply retention policies

This is probably the most complex area of M365 for records and information managers to understand given the multiple elements that make up MS Teams. Careful planning is necessary before any retention policy is applied, based on a thorough understanding of the structure of Teams and where the content is stored.

As a starting point, it is important to understand that:

  • A single retention policy cannot be applied to all the content of a Team and its associated M365 Group (private channel chats, channel posts, SPO files, Outlook ‘conversations’). Multiple retention policies will be required.
  • It is NOT possible to apply retention labels to either Teams public or private channel posts. These can only be covered by retention policies. Retention labels could be applied to content stored in the SPO site.

The model for applying retention to Teams (not the 1:1 chats area) may include up to four separate retention policies (and also retention labels):

  • One or more retention policies for the Team (non private) channel posts. These policies will apply to the compliance copies of those posts stored in a hidden folder of the linked M365 Group’s EXO mailbox.
  • One or more retention policies for the Team’s private channel posts if they exist. These policies will apply to the compliance copies of those posts stored in a hidden folder in the EXO mailbox of all members of the private channel.
  • One or more retention policies for the Team’s files stored in the SPO site. Additional retention labels may also be applied (see below).
  • If the mailbox is used for Group conversations, one or more retention policies for the M365 Group, which includes coverage for both the emails and the files.

So, each Team could potentially be subject to up to four separate retention policies.

Retention policies that could apply to every Team, or groups of Teams

In addition to the above, retention labels may be applied either ‘manually’ or automatically (including via trainable classifiers or SharePoint syntex) to content stored in the SPO site (the channel files – each channel is a folder in the default Documents library). These labels will likely have retention periods that are longer than the retention policy and may include disposition review.

A even more complex model is to apply multiple retention labels to the channel-linked folders (and sub-folders) in the SPO site’s Documents library. This model is fraught with complexity in terms of future disposition review and would be the equivalent of applying retention policies to different folders and subfolders in a network file share.

Pros of applying retention policies (and labels)

Retention policies ensure that content is not destroyed for the period set in the retention policy.

Retention policies are better than auto-expiry because they capture any content that is ‘deleted’ by end-users for the life of the policy. They are better than ‘archiving’ Teams as they set a minimum retention period, protect the content from destruction during that time (‘in place holds’), then destroy the content.

Retention policies could also be used in conjunction with the other two options as necessary. For example, there may be some Teams that contain no records and could simply be deleted via the auto-expiry option. If they contain records, a retention policy will retain the content for as long as required.

Cons of applying retention policies

The main negative of applying retention policies is the complexity of the model, and knowing what has been applied and where. This is especially true if there are many Teams. Consultation and coordinated planning between RM/IM and IT, and documentation of the model, are all essential.

Unfortunately, the Microsoft 365 Compliance admin portal does not provide a single view of what policies have applied where. Unless a third-party application is used, the only way to achieve this is by recording the details of the policies in – say – a spreadsheet or a SharePoint list.

Retention policies do not include the option for disposition review, so records and information managers might need to consider the requirement to find a way to document the disposition (deletion) process and retain a record of what was destroyed.

By actively monitoring Teams, records and information managers should know when the content in Teams is due for destruction, allowing time to extract metadata (where possible) and other information.

For more information about applying retention to Teams and SPO, see these Microsoft docs pages: ‘Learn about retention for Teams‘, ‘Learn about retention for SharePoint and OneDrive‘ and also ‘Limits for retention policies and retention label policies‘.

Concluding comments

All of the above underlines why records and information managers need to know what Teams exist, where the records are stored, and be proactively involved in decisions about what happens to inactive Teams.

As long as retention policies have been correctly applied to the various parts of the Team, that content will be retained for minimum periods. End-users may think they are deleting content, but it remains stored and accessible via a Content Search.

Feature Image Credit: David Yu (image 2081166, via Pexels)

Posted in Artificial Intelligence, Classification, Electronic records, Information Management, Microsoft Viva, Products and applications, Records management

Are auto-generated topic cards the future for aggregations of records?

Humans have natural instinct for grouping, classification and categorisation of things. It helps us find what we are looking for and gives us a sense of satisfaction, whether it be household items, computer storage, or much broader social and population groupings.

Humans have created and kept records ever since we developed a way to record them, on stones, clay shards, papyrus, bamboo sheets, velum, paper and various other means. Multiple records were aggregated in ways that made sense to the people who created or kept them and wanted to find them again.

The introduction of computers at work from the late 1980s/early 1990s began the decline of traditional ways of aggregating records about a particular subject together in a physical ‘file’, although that practice has persisted to the present day because it was and still is easier to refer to. Lawyers (or more often the legal clerks) still attend digital courtrooms armed with printed copies of (usually digital) evidence and other materials for this reason.

Lawyers off to court – Image credit Sven Vik (NYC TV News Videographer)

The ‘problem’ of digital aggregations

While physical files provided the ability to store anything (printable) about a given subject in the one location, digital ‘files’ (or aggregations) suffered from the fact that emails and other content are created or stored in completely different locations.

The only way to keep emails together with other content about the same subject was for end-users to copy them to a network file share folder location or a digital recordkeeping system. In almost every case, the original email remained in the mailbox where it might still have an active life. Some email mailboxes became a primary (or alternative) storage location for both emails and attachments (as did some desktops!).

Keeping all digital records about a given subject in a single aggregation was never an easy task. It was never possible to be sure that everything was captured because it relied on end-users.

The email mailbox – SharePoint conundrum

In the same way that organisations decided to store copies of emails in network file shares or EDRM system, it was easy to see SharePoint as the replacement for both.

But Microsoft have never made it easy to ‘natively’ copy an email from Outlook to SharePoint. There isn’t even a download option for emails. Emails can be dragged and dropped to synced document libraries, and various third-party products exist, but the process usually relies on end-users (a) to copy the emails and (b) to copy them consistently. Neither of these can be guaranteed.

And, of course, the records created and captured in Microsoft 365 is not just in Outlook mailboxes and SharePoint. A number of other apps create content that could records (for example Yammer conversations, Teams chats, calendar entries, Planner tasks, even Whiteboard diagrams). Few of these records can be saved to SharePoint.

So, are digital aggregations impossible?

There is nothing stopping organisations doing whatever they can or want to group related records together. In Microsoft 365, the most logical way to do this is in SharePoint document libraries (the ‘Files’ tab in Teams channels). An entire SharePoint site (the ‘Files’ tab in MS Teams channels) provides a form of meta-grouping; that is, multiple document libraries grouped by the SharePoint site/Team.

But if we stand back for a moment, to look at the (Microsoft 365) forest, what we see is not just individual trees (SharePoint sites, Exchange mailboxes and so on). Just as in a forest the roots of all the trees connect via mycorrhiza networks, sometimes known as ‘wood wide webs’, something similar happens in Microsoft 365 (and many other online systems, including Facebook).

Trees networking

The equivalent of networks in these systems are the ‘graphs’.

Like other graphs, the Microsoft Graph draws on all the rich data created and stored by end-users, in this case across the Microsoft 365 ecosystem – our corporate relationships, who we connect with and how, what we are communicating or writing, what we like, the way we use our time and so on. The graph learns what is popular or trending and makes suggestions (while respecting permissions) as to what we might want to see or know about.

Project Alexandria and Viva

According to a post in the Microsoft Research blog published in April 2021 and titled ‘Alexandria in Microsoft Viva Topics: from big data to big knowledge‘, Project Alexandria is ‘a research project within Microsoft Research Cambridge dedicated to discovering entities, or topics of information, and their associated properties from unstructured documents’.

The blog post also noted that ‘Alexandria technology plays a central role in the recently announced Microsoft Viva Topics, an AI product that automatically organizes large amounts of content and expertise, making it easier for people to find information and act on it’.

The Alexandria pipeline – from unstructured text to structured knowledge (From the blog post above)

The outcomes sound similar to traditional ‘manually’ created aggregations, although they don’t replace them. In fact, the more that content is manually curated, the more likely that Viva Topics can accurately connect them and other related content that might otherwise be missed.

While Viva Topics might appear to primarily focussed on supporting knowledge management outcomes and is currently limited to content stored in SharePoint, the technology has potential implications for records management. In particular, the age-old issue of how to find all information about a given subject (or know that a pre-defined aggregation contains all relevant information).

Viva Topic cards

As noted already, there is nothing stopping organisations from creating aggregations in ways that make sense to them and their end-users. SharePoint document libraries are the most logical form of aggregation that also happen to allow complex metadata, versioning and other features typically associated with EDRM systems. SharePoint document libraries are just one of several ways that content may be aggregated; Exchange mailboxes are another.

But, in most organisations, potentially relevant information AND records is frequently hidden from view in personal mailboxes and OneDrive accounts, in Teams chats, and in other applications (e.g., Planner). Viva Topics has the potential to leverage this information.

Once set up (as described in Set up Microsoft Viva Topics) , Microsoft Viva begins to work its magic, discovering topics. An example of a discovered topic (from ‘Manage topics at scale in Microsoft Viva Topics‘ is shown below.

While Topics are still limited to SharePoint content and people, there is potential to extend this model even further by including details about emails, chat messages or other content across the Microsoft 365 ecosystem – even if that information cannot be seen. For example:

  • Topic Name
  • Suggested people (perhaps grouped by AD manager or business area)
  • Suggested files and pages (you can see)
  • Authors of (n number of) emails that are related to the topic with an indication of volume over given periods (e.g., ‘251 emails in the past 6 months’) or a graphic representing this activity
  • Names of Teams that contain (n number of) chat messages related to the topic.
  • Participants in Teams 1:1 chats that contain (n number of) messages related to the topic.
  • Volume and date range of other related content (e.g., Tasks, Whiteboards, Forms, Yammer conversations).

Could Topic cards be the new aggregations?

Topic cards have the potential to resolve the age-old dilemma of digital aggregations, but they are unlikely to replace pre-defined ways to aggregate records including by copying emails to SharePoint document libraries. Those older methods will continue to exist for a long time.

But more importantly, they have the potential to draw out or highlight content that would otherwise be hidden from view – even if that content remains inaccessible.

When configured, Viva Topics already appear in search results, enhancing search outcomes.

It is only a matter of time before the probabilistic programming techniques of Project Alexandria, with expert human curation, begins to provide the type of high precision knowledge base construction for all relevant content about a given subject, first described by Microsoft researchers in May 2019.

Perhaps they may even support or link with retention and disposal processes, highlighting records due for disposal within a given period or even preventing their premature disposal.

Posted in Electronic records, Information Management, Planner, Records management, Retention and disposal, Tasks

Managing tasks as records in Microsoft 365 Planner/Tasks

There are several ways to create, record and assign tasks in organisations. These may include:

  • Personal tasks (or calendar entries) in email applications such as Outlook, or set via the Microsoft ‘To Do’ application.
  • Team and Group-based tasks created and managed in various ways, including on physical white boards, via Microsoft 365 Planner/Tasks or ‘Tasks by Planner for Teams’.
  • Project-based tasks, including in Microsoft Project or other similar applications. Depending on the type of project (e.g., agile or waterfall), this may also involve tasks pinned on Kanban boards.
  • Activity-based tasks, including in dedicated task-based software such as Jira, Trello, etc.

This post describes the three main elements of tasks in Planner/Tasks (including via Teams), where the records are stored, and recordkeeping considerations.

An important point to consider while reading this post is whether you regards tasks in Planner (or Tasks by Planner for Teams) as records? If your answer is yes, then you will need to think about how these records will be managed.

(Thanks to the team at Office365 for IT Pros for some of the detail in this post).

What is Planner?

The Planner option in office.com

To quote from the e-book ‘Office 365 for IT Pros’, Microsoft Planner (also known as ‘Tasks by Planner and To Do’ in Teams) is ‘a lightweight task-oriented planning application’ that is based on membership of Microsoft 365 Groups (click link if you are unfamiliar with Microsoft 365 Groups).

The Planner app in Teams

While there is some functional similarity between Microsoft Project and Planner, organisations soon (or will need to) learn which one is most appropriate for their business needs. Based on my own experience:

  • MS Project is best for tracking activities and tasks for major projects.
  • Planner is useful for general group task assignment and tracking of those tasks.

What are the three main elements of tasks in Planner?

Every task in Planner has three main elements:

  • Data. The details of the task itself including the ‘bucket’ it belongs to, progress, priority, dates, notes and a checklist.
  • Attachments. This may include either uploaded documents or links. Two tasks cannot have the same attachment, for reasons explained below.
  • Comments. These are effectively ‘conversations’.

When a new task is added via Planner or Teams (Tasks by Planner for Teams) via the ‘+ Add task’ option, an end-user simply needs to enter the task name, set a due date (if required), and assign if (if required).

Adding a task

After the new task has been created, the end-user may click on the three dot menu to add a label, assign the task, copy it, copy a link to it, move it, or delete it. Note that deleting a task does NOT delete any attachments or comments.

Task 3-dot menu options

The end-user may also click on the name of the tasks, which offers the options shown below to add attachments or make comments.

What is stored where?

Task data

According to Office 365 for IT Pros, ‘Planner stores the metadata for plans, including information describing the tasks and buckets that make up each plan, in an Azure data service’. Click this link to learn in which country your Planner data is stored)

The accessible metadata about each plan can be seen when the plan is exported to Excel.

  • Task ID (for example: QXkIWsgkqkO5rLu5pvfMhQgAEyXz)
  • Task Name
  • Bucket Name
  • Progress
  • Priority
  • Assigned To
  • Created By
  • Created Date
  • Start Date
  • Due Date
  • Late (true/false)
  • Completed Date
  • Completed By
  • Description (= Notes)
  • Completed Checklist Items
  • Checklist Items
  • Labels

As can be see, the Plan metadata does not include or show references to attachments or notes. There is no way of knowing from the exported data if the task had any attachments or comments

Task attachments

Any task can have attachments or links to other content. When uploaded ‘from computer’, these attachments are not stored in Planner but in the Documents library of the Team’s SharePoint site (the ‘Files’ tab), at the same level as (public) channel folders, as described in detail below. There is no option to choose where they will be saved.

This can be quite confusing, especially as all attachments uploaded from a computer, for all Tasks may be stored in the same location, without reference to the task. (This underlines the importance of saving the required attachments to the Teams channel Files tab first).

In the example below, the Teams channel ‘New Sites’ has a plan named ‘New sites tasks’. A task (‘Does this seem right’) has been added with an attachment ‘ExamplePDFA’. (Note, the visual of the document is a check-box option; only one visual can be displayed if there are multiple attachments).

Example task with an attachment.

As noted already, if uploaded from a computer, an attachment is actually stored in the Documents library at the same level as the channel folders, which means they are not visible from the Files tab for the channel as can be seen in the screenshot below.

The task attachments are NOT stored in the channel Files tab

To get to the task attachments from Teams you have two options:

  • Go to the ‘General’ channel, click on the ‘Files’ tab, then click on the ‘Documents’ option (to the left of ‘> General’). ALL attachments to ALL tasks for every channel in the entire Team are stored in this location. This needs to be kept in mind if anyone syncs the library to File Explorer as there is no indication that these attachments belong to a task in Planner.
  • By clicking on ‘Open in SharePoint’ and then navigating to the top of the Documents library as can be seen below.

In the same way that the task data exported to Excel does not show any reference to attachments, attachments uploaded from a computer (or, for that matter, attachments from Teams files) show no reference to the related task.

From a retention point of view:

  • If retention labels have been applied to the Team’s folders in SharePoint, these labels will not apply to uploaded documents linked with tasks.
  • If a retention policy has been applied to the entire site, then these attachments will be deleted in line with that policy.

The following could happen:

  • Anyone with delete rights, not knowing why these uploaded documents exist, to simply delete them.
  • A member of the Team or Group could add more content to the library at the same level as the uploaded attachments, especially if they are working via File Explorer. (Keep in mind that a new channel is NOT created when a new folder is created in the library at the same level as the channel linked folders.)

Also, if the person who created or is editing the tasks ‘removes’ the document from the three dot menu next to an existing attachment, that attachment is not deleted from the library, which is why there are two documents titled ExamplePDFA above, one with the extra ‘ 1’.

Removing an attachment doesn’t delete it, adding to the potential confusion.

Although it may be difficult to enforce in reality, asking end-users to attach or create a link to a document already stored in a Teams Files tab is better practice.

Task Comments

Task Comments are threaded conversations that are captured in the Microsoft 365 Group’s mailbox. If the Team was created first, the M365 Group mailbox will not be visible to the end users in their Outlook client. However, they will receive a copy of the conversation in their normal inbox.

In the example task below below, which was created in a Team with a visible Outlook mailbox, there is one initial comment to indicate the task was created, then two additional notes.

In the Outlook client, each of these added comments is visible as a thread ‘in reply’ to the original task.

Curiously, the copy that appears in the end-user’s Inbox also shows the retention period for all other Inbox emails. It is not clear if this retention policy will apply to the task conversations or not.

The header of the thread in the Inbox shows a retention policy, not visible in the one above.

Managing records in Planner/Tasks

Are tasks records?

If organisations decide that tasks are records, they will need to consider how they will be managed given:

  • The way that Planner stores task data, attachments, and comments separately. Planner task data is made visible via the Teams interface, it is not stored in Teams.
  • The ability for members of Teams to create multiple plans with multiple tasks with multiple uploaded attachments (all stored in the same location without reference to the task it relates to).
  • The fact that a Group/Team may create a range of different types of content, not just in Teams.
  • The inability to apply retention policies to tasks in Planner, while retention policies might affect uploaded attachments, Teams files or comments as conversations in Outlook.
  • The inability to close or archive a plan, or export all the content as a single entity.

At a minimum, all the task data could be exported to Excel and stored somewhere – perhaps even on the Team’s SharePoint site. The exported data will not include any attachments or comments (neither of which are not referenced in the Excel export). One problem with this approach may be deciding when and if the task data is to be exported, and if the original plan should then be deleted – who is responsible?

If organisations decide that tasks are not records, they should still consider how to manage the various elements of each task and plan from a retention point of view.

  • At what point can a plan be deleted? Does the deletion need to be recorded somewhere?
  • What if the Team decides to delete it anyway? There is currently no information governance/retention coverage for Planner but attachments and comments (if any) may remain.

Perhaps the easiest approach is to regard Planner tasks as low-level working content, not really records, in the same way that tasks in the former Outlook were generally overlooked as being records.

Posted in Artificial Intelligence, EDRMS, Electronic records, Exchange Online, Information Management, Microsoft 365, Microsoft Teams, Records management, SharePoint Online

Different approaches for managing records with Microsoft 365

The COVID pandemic from early 2020 led to the requirement for many employees to work from home (WFH). IT Departments scrambled to enable this capability, many making use of Microsoft (MS) Teams that was already bundled with their Microsoft 365 licences.

The rapid enabling and uptake (rather than an actual ‘implementation’) of MS Teams was more often than not achieved without much consideration for recordkeeping requirements or an overall plan for using Microsoft 365.

MS Teams became popular quickly, increasing from around 30 million active users daily in early 2020 to around 250 million by mid 2021 (Source: ZDNet quoting Microsoft latest results). End-users could chat with each other and with external people (and on their phones too!), have video meetings, create new teams with channels and private channels, share and collaborate on content via the ‘Files’ tab in Teams, create and manage tasks, and more. They also continued to use email.

Anecdotal evidence suggests that the capture of records to on-premise electronic document and records management system (EDRMS) declined from early 2020. One reason suggested for this was that it was too hard to save some cloud records such as Teams chats or content from the Files tab to an on-premise system. Alternative approaches for managing records with Microsoft 365 began to evolve.

This post discusses four approaches to managing records in Microsoft 365, summarised in the diagram below.

Which approach have you taken? Answer my (anonymous) short survey here (Microsoft Forms).

Approach 1 – EDRMS + key Microsoft 365 applications to create and capture

Approach 1 – EDRMS plus the main Microsoft 365 applications

This model has two elements:

  • Retaining an existing centralised recordkeeping system (the EDRMS) for the storage of records.
  • Using email, Teams, SharePoint or OneDrive to create or capture records to be copied to the EDRMS, and leaving other content (in theory non-records) ‘in place’.

The main positive aspect of this model is that records are (in theory) captured and managed in the EDRMS with all the traditional recordkeeping options. Some leading EDRMS vendors now offer solutions that integrate with Microsoft 365 and make it easier to capture records from Microsoft 365. But the model is still based on a centralised recordkeeping system and the requirement for end-users to copy content identified as records.

The main negative aspects of this model include the following points:

  • End-users still have to identify and copy records to the EDRMS.
  • Not all records created or captured in Microsoft 365 can be copied to the EDRMS.
  • Additional products or add-ons may be required to enable the copying.
  • The record is copied to the EDRMS, not moved, so remains in place with no controls.
  • Records that remain stored in Microsoft 365 applications may not be subject to the same degree of recordkeeping controls available in the EDRMS. Unless they acquire a third-party product (see next approach) to overcome this problem (which is unlikely for cost reasons), organisations must use the out of the box recordkeeping capability in Microsoft 365. This capability may not meet all requirements for keeping records if not properly configured.
  • There is a real risk that some records that remain in Microsoft 365 may be lost, especially if settings allow content to be deleted and there is no retention policy or backup.
  • EDRM system admins and records managers will need to learn a lot more about Microsoft 365.
  • The unified logs in Microsoft 365 only retain the details for 3 months (E3) or 12 months (E5) – although SharePoint’s versioning history can provide a lot of ‘modified’ event metadata for the life of the document (up to the the maximum number of versions allowed). (Update: Microsoft 365 customers can retain the audit log for up to 10 years with an add-on license. Many export audit data to a SEIM such as Azure Sentinel where they can retain the log for as long as they want.)

On a positive note, however, Microsoft 365 includes a wide range of search, audit, monitoring and reporting tools, as well as security and protection controls, that improve the ability for records managers to find, manage and protect records (or potential records) in Exchange mailboxes, MS Teams chats and posts, SharePoint sites and OneDrive accounts AND put that content on a legal hold. So, as long as those options are enabled, the risk of losing records is reduced.

Approach 2 – Third-party application + Microsoft 365 applications for creation, capture and storage

Approach 2 – Third-party product plus Microsoft 365

A number of Microsoft partners have developed applications to manage records in Microsoft 365. Several have been available for a decade or more, originally designed to manage records primarily in on-premise SharePoint environments.

Most of these third-party applications were developed to comply with the same recordkeeping standards used by EDRMS vendors. These applications are generally either:

  • Replacements for EDRM systems (often requiring migration from the EDRMS).
  • New implementations where there was no EDRMS beforehand.

It is not common to see both an EDRMS and one of these third-party products being used together, because of licensing cost reasons.

The main positive aspect of using a third-party dedicated application is that records created or captured in Microsoft 365 can be stay there and be managed according to recordkeeping requirements. Some of these applications are invisible to end-users, making them even more attractive.

The main potential negative aspect of using a third-party application, which is the same for any other vendor product, is that it creates a dependency on the vendor to maintain the product. Microsoft 365 continues to evolve and any third-party application must keep up with these changes. Two questions might be asked:

  • Will this dependency become a ‘tech debt’ liability in the future, if a ‘better’ option comes along?
  • How hard will it be to transfer to a different vendor in the future? Generally speaking this is less likely if the vendor is an established Microsoft partner, but the question should still be asked. For example, many organisations decided to use the Google suite of products but have now decided to use Microsoft 365.

Organisations seeking to implement third-party applications to manage records in Microsoft 365 should have a very detailed understanding of the underlying Microsoft 365 environment beforehand and the impact the third-party application might have on this environment. Some of the considerations might include:

  • The requirement to provide the third-party vendor with admin (including global admin) access to the Microsoft 365 tenant. Is this a security concern?
  • The location of records – in some cases, third-party vendors may use, move or back up content to one of their Microsoft 365 tenants. Is this a security concern? How can you monitor activity on your content if it’s not in your tenant?
  • The use of the central Term Store or Content Types to support the application. Will this create a dependency or make it harder for people to work, for example by requiring end-users to select Content Types or add metadata.
  • Changes to SharePoint settings and architecture, including the addition of hidden columns. Will these changes be consistent with your own architecture model?
  • How and where event metadata (audit logs) will be captured and managed.
  • How retention outcomes will be managed.

Approach 3 – One or more Microsoft 365 applications are the default ‘recordkeeping systems’ (no EDRMS or other application)

Approach 3 – Individual systems highlighted are the ‘recordkeeping’ systems

This approach focuses on the applications where most records are likely to be created or captured in Microsoft 365 – Exchange mailboxes, MS Teams, SharePoint, and OneDrive for Business – and therefore considers other content created and/or stored in other Microsoft 365 applications (e.g., Yammer, Forms, Planner/Tasks, etc) as being non-records.

There are several variations on this model including the following:

  • Outlook and Teams are the primary ‘recordkeeping systems’ as they are the two applications that are most used. Teams has been positioned as the primary interface for both SharePoint and OneDrive (via the ‘Files’ tab). The ability to also access both SharePoint and OneDrive from File Explorer via the sync option makes it even less likely that SharePoint or OneDrive will be accessed by end-users.
  • All four applications are the recordkeeping systems, using the various controls and settings available in the various admin portals, as well as the Compliance admin portal for retention policies.
  • SharePoint is the primary recordkeeping system, configured to mimic EDRMS capability. In this case, end-users would be expected to copy emails from Outlook or records from OneDrive, similar to the way they would have to do this for an EDRMS. Various controls and settings, such as ‘back end’ retention policies, might be applied to the other main applications to ensure that any records in those systems (such as Teams chats or emails) are not destroyed before a given period.

The main positive aspects of this approach are (a) simplicity and (b) cost savings, mostly by not having to purchase an EDRMS or third-party application.

However, these potential positives should not compromise the requirement for both IT and records management to have a very good understanding of, detailed approach to, and governance for, managing records in Microsoft 365. In other words, simply saying that one or more of these four applications is the recordkeeping system is not sufficient; additional work is required to ensure that records stored in them are managed appropriately.

There are several potential negative aspects of this model:

  • With the exception of SharePoint, none of the other three systems can be configured to manage records based on standards used for EDRM systems. Given that SharePoint has been positioned behind the Teams user interface, and SharePoint document libraries can be synced via Teams to File Explorer, any recordkeeping functionality configured in SharePoint should in theory be accessible or useable via Teams and possibly also File Explorer, but this is mostly not the case. So, SharePoint on its own, accessed via the browser only, is not really an option. Additionally, without effective controls, the Files (SharePoint) element of Teams has the potential to become the future equivalent of legacy network file shares full of redundant, outdated and trivial content.
  • If only one or two systems are considered to be the only recordkeeping systems, there is a risk that records may not be saved and/or could be lost, especially if end-users can delete records and there is no back up option.
  • Managing records in this way requires both access to and a very good understanding of the applications designated to be the recordkeeping systems by both IT and records managers.
  • Retention policies (either the base level information governance or more expensive records management) may not be adequate, in terms of both application and coverage, and retention outcome management.
  • Exporting the records to another system or transferring them to another organisation, could become a complex task.
  • Accessing audit logs over a long period (see first approach, last dot point, above).

Approach 4 – All of Microsoft 365 is the recordkeeping system

Approach 4 – All of Microsoft 365 is the recordkeeping system

This approach is similar to the previous one except that it takes a broader approach and requires a degree of ‘letting go’ of the standards used by EDRMS systems (and third-party products). It is also the Microsoft default.

The approach assumes that records may be created or captured anywhere in Microsoft 365, saved to Microsoft 365 via archive connectors, or accessed (subject to access controls) via search connectors. Records are managed ‘in place’, meaning wherever they are created or captured, using a range of tools already available in Microsoft 365. Additional ‘in place’ controls allow certain items to be declared as records.

The approach requires both a very good technical understanding of the Microsoft 365 environment and effective governance by IT and records managers. If internal skills are lacking, it may also require a third-party organisation to implement the system – but based on what recordkeeping model? A reliance on a third-party to implement the recordkeeping elements has several risks (see below).

The main positives of this approach include the following:

  • Records that are created or captured in the Microsoft 365 environment remain there. There is no requirement to copy them to a separate system.
  • Some records, such as emails, can be copied to SharePoint if required.
  • The combination of Teams and SharePoint sites allows for multiple models to manage records – for example, high value records could be managed in a dedicated SharePoint site with multiple dedicated libraries and additional controls (metadata, retention, permissions etc), whereas low level records could be managed in the single ‘Documents’ library presented as the Files tab in a Team, or via File Explorer.
  • All the content (records and non-records) stored across Exchange, Teams, SharePoint/One drive can be searched (subject to roles and permissions). This allows records managers (and others such as Legal) to identify if records may be hidden in personal mailboxes or Teams chat or OneDrive accounts.
  • Minimum retention periods can be applied to all the content (not just records), ensuring that records that may be hidden in Teams chats, OneDrive accounts, or personal mailboxes, will be retained for minimum periods. This option also helps to reduce the volume of redundant, outdated and trivial content that may build up over time otherwise.
  • Retention labels can be applied, including automatically (and using machine learning), to records in mailboxes, SharePoint sites and OneDrive accounts (but not Teams chats or posts, yet).

The main negatives of this model are the same as those listed for the previous model with more focus on the need for both IT and records managers to have a very detailed understanding of and establish effective governance for the entire environment where records may be created or captured, not just the main four applications. This requires some effort to achieve and should not be understated. It is not uncommon to see IT staff with Global Admin managing the entire Microsoft 365 environment using default settings and/or records managers will little technical knowledge or appropriate access struggling to understand how the environment works and drawing on experience with EDRM systems.

Some organisations may engage third-party implementation specialists to configure and set up the environment. Organisations that decide to go down this path should ensure they have the details of this configuration and can support it in the longer run, or the environment (or parts of it) could end up becoming difficult to manage or support over time.

Approach 5 – A potential future model

Microsoft 365 includes a wide range of settings, options and capabilities that have a significant impact on the way records can and will be managed across Microsoft 365 in the future.

Microsoft 365 will continue to evolve over time, including in ways that will support how records are managed. But it is important to keep in mind that Microsoft 365, or its component applications, is not and will never be an EDRMS based on standards such as DOD 5015.2. Microsoft 365 is too complex, and the volume and type of content stored in it too large, for any part of it to be considered the ‘records management’ system.

A new approach is required for the identification and management of records. This approach may draw on existing recordkeeping standards and concepts but is likely to rely more heavily on new and evolving ways to work with information, including records.

Some of these ways have been around for a decade or so in the form of graph-based machine learning (ML), process automation, artificial intelligence (AI). Examples include Google, Facebook, LinkedIn, Netflix, Amazon, eBay and so on. These examples have one thing in common – they all take advantage of the various ‘signals’ and ‘digital exhaust’ voluntarily offered by their users to identify and present things that match your interests – jobs, friends, things to purchase, movies. Post something on Facebook or (perhaps) talk about a particular subject near your phone, and related ads will appear.

So, what is different about Microsoft 365? End-users are related to each other thanks to Active Directory, they connect and communicate with others via email or Teams, they share content, they attend meetings. All of these (and a lot more) signals feed into the underlying Graph and allow connections to be made and suggestions.

There is nothing stopping organisations setting up dedicated SharePoint sites with multiple well-named libraries to manage certain records and leaving other content and records to the world of Teams Files. But all of this information can be related based on context, including who created it, what team that person was in, who they connect with, what access do they have and so on.

Perhaps by 2035, the primary approach to records management will be relying on all the digital connections and signals, machine learning, the Graph and AI to identify all related records in context, not just the ones neatly placed in a SharePoint document library. Records may be automatically identified as important and needing stronger controls based on this context – who created, sent or received it, whether it relates to a subject that is trending (or was in the past).

Instead of just a simple pre-defined aggregation of records (which will still be a valid way to aggregate records), future aggregations will include a wider range of content, created automatically, likely presented in the form of ‘cards’.

Viva Topics is an interesting pre-cursor to this possible future model.

Viva Topics presented in Teams

The following text is from the Microsoft page ‘Alexandria in Microsoft Viva Topics: from big data to big knowledge‘:

Looking further ahead, Alexandria’s ability to extract information automatically gives us the opportunity to customize the knowledge discovery process. By automatically retrieving the set of types and properties being talked about in an organization’s documents, Alexandria can create a knowledge base with a bespoke schema exactly tailored to the needs of each organization and using the familiar language and terminology that people in the organization are used to. Read more about the proposed schema-based design in our research paper.

We are only beginning to dream of the experiences that an automatically created and updated knowledge base can enable, but it is already clear that it could transform the future of how we work. The era of big knowledge is coming sooner than you might think.

Whatever the new approach is, managing records in Microsoft 365 will require new skills on the part of information and records managers.

Posted in Governance, Information Management, Information Security, Records management, SharePoint Online

Tips to reduce complexity when implementing SharePoint

Over a period of almost 10 years of providing support for SharePoint (2010, 2013, Online), one of my key learnings has been to avoid complexity in its implementation. The more complicated the implementation is, the harder it will be to support, fix and maintain.

This post contains several tips for implementing SharePoint to minimise complexity and therefore the need for support.

Before the tips, it is important to understand the original SharePoint architecture model as this model (a) likely continues to exist in many organisations and (b) can influence decisions – not necessarily in a positive way – about how to implement SharePoint Online.

Understand the (historic) dual nature of SharePoint

SharePoint was first released in 2001. There continues to be a lot of legacy SharePoint implementations and approaches to SharePoint Online that reflect these older implementation models.

SharePoint has always had two sides – the publishing functionality (usually in the form of an intranet) and the document management functionality (where documents are stored). Sometimes these two are conflated into the single term – ‘intranet’ when in fact they are two quite different things in terms of architecture and usage.

Older (pre Online) on-premise versions of SharePoint typically consisted of multiple web applications in several app pools, as the diagram below shows.

(Source: Microsoft ‘SPS 2010 Design Sample Corporate Portal with Classic Authentication architecture’ model)

Within each of these web applications, organisations would have one or more site collections, often with sub-sites. Almost none of this architecture model remains in SharePoint Online – there are now only sites, which are still technically site collections, but preferably without any subsites – see below. This is sometimes described as a ‘flat’ implementation as every site (formerly a site collection) is on the same ‘level’.

The publishing functionality, enabled through the publishing features, was typically used for intranets. Most information was presented on pages, typically across multiple subsites, with some use of the document libraries (e.g., to store common forms or policies).

But the publishing User Interface (UI) was poor; most organisations engaged a third-party to create more engaging (and usually heavily customised) intranets. The outcome has often been that organisations have had to maintain old legacy SharePoint servers to keep the ‘old’ intranet running. In most cases, these older SharePoint sites cannot be migrated ‘as is’ to SharePoint Online.

The former publishing functionality was replaced in SharePoint Online with communication sites.

The document management functionality was (and continues to remain) the default ‘out of the box’ (OOTB) option for all new team sites. Most older SharePoint sites had to be accessed via a browser and the older UI was often seen as not very interesting or engaging. Business areas would sometimes customise the site pages, sometimes to the point of making them appear to be ‘local’ (business area) intranets.

Although SharePoint Online has the same dual nature, it does not use web applications. Instead, all site templates (communication or team) must be created under one of two paths: /sites/ and /teams/. Organisations may default to just one of these two paths for all sites, or could decide to make use of them to differentiate between, e.g., enterprise sites (cross organisational, e.g., the intranet) and team sites (the name of the business area/team comes after /teams/).

Tip 1 – Try to avoid or minimise customisation

As noted above, customisation was common in on-premise versions of SharePoint. Microsoft have done a lot to improve the UI for both communication and team sites.

Microsoft have released a range of pre-canned templates for communication sites that can be downloaded from the ‘lookbook‘ site. (These templates will soon be available as a choice when new sites are created as well.) These templates and new web parts allow organisations to set up a nice-looking and engaging intranet, with no customisation, (other than via the web parts on each page), that is easy to support and manage.

Organisations that require more complex intranets can of course continue to customise their communication sites and/or use a wide range of third-party tools. These are likely to require a higher level of support to maintain and troubleshoot issues, including from third-party vendors.

The customisation of SharePoint team sites used primarily to store and manage document-type content (e.g., to replace network file share storage) is now a different matter. The rapid adoption of MS Teams as the primary UI to access this content over the past 18 months and the ability to sync document libraries to File Explorer and access the content on a mobile device, has in most cases made browser-based access redundant.

There is no longer much point in customising the browser (pages) view of SharePoint team sites used to store documents. Customisation in these sites is more likely to take the form of the site structure, content types and columns, permissions, or the types of information stored in them. Any customisation of team site pages should be restricted to the out of the box options.

Tip 2 – Don’t overcomplicate the structure

Older versions of SharePoint could have quite complicated structures – from the web application through to the site collection, sub-sites, libraries, content types and columns.

These structures would inevitably cause issues over time as organisations re-structured or were renamed, or wanted content moved to different parts of a site or a different site. The easiest sites to manage were always the simple stand-alone sites which is, fortunately, the preferred model in SharePoint Online.

To avoid complexity with all SharePoint Online sites, don’t create sub-sites unless absolutely necessary. Microsoft don’t recommend sub-sites any more – see ‘Planning Your SharePoint Hub sites‘. To quote from that page:

Subsites don’t give any room for flexibility and change. Since subsites are a physical construct reflected in the URL for content, if you reorganize your business relationships, you break all the intranet relationships in your content. Subsites can also create challenges when it comes to governance because many features (including policy features like retention and classification) in SharePoint apply to all sites within the site collection, whether you want them to or not. This means that you must frequently enable a feature for the entire site collection, even if it’s only applicable to one subsite.

Instead of using sub-sites in communication sites, create multiple pages linked via the out of the box mega menu or links.

Avoid using sub-sites at all for team sites unless there is a genuine requirement to restrict access to part of the site. The same outcome can usually be achieved by changing access controls on a document library.

Tip 3 – Use Content Types and columns selectively

SharePoint is built on content types, including the common ‘item’, ‘document’ and ‘folder’ types. Older SharePoint implementation models sometimes made extensive use of Content Types and site (or library) columns to define content added to document libraries. This meant that end-users would have to select a Content Type and/or add or choose metadata when content was saved, a process that was seen as off-putting for most.

To minimise complexity, deploy custom Content Types and additional site or library columns only where really necessary, not as a default approach. Don’t use Content Types to differentiate between (ironically) content or document types but consider using site or library choice columns with default values instead. For example, if a document library is used to store records about meetings or committees, a drop down choice value for ‘document type’ is more likely to be used (and useful) than Content Types.

Tip 4 – Avoid complex permissions

Possibly up to 70% of all support queries over a decade related to permissions or access restrictions relating to a team site and usually started with ‘Why can’t I access …?’ or ‘Why can (so and so) see (or not see) this content?’ They rarely related to permissions on a publishing or communication site, which tend to have simple permission structures.

Almost all of the queries about team site permissions could be tracked back to someone changing the default inherited permissions. In one case, on a site with very complex permissions, a site owner deleted the site owners permission group, locking them out not only of the site but on every single part of the site that had unique permissions. It took a couple of weeks to restore these permissions.

Try to avoid changing the way permission inheritance works. The permissions set at the site level (example shown below) flow down to all the content. It is all too easy to lose sight of (and then find) what permissions have been changed.

If there is a genuine requirement to restrict access, consider moving that specific content to a separate library or even a separate site, rather than restricting access on items within a library, especially one that has a complex folder-based structure.

Also, keep in mind that over the past decade, the access model for SharePoint content has changed from (a) restrict access everywhere and only grant access to those who can access it, to (b) open access everywhere and only restrict access to what needs to be restricted. This is a much easier model to support.

The easiest way to give ‘everyone’ internally access to all SharePoint content is to add ‘Everyone except external users’ to the Visitors group of every SharePoint site, including sites linked with MS Teams. This access does NOT give them access to the Team channel posts in MS Teams.

Whether or not external users should be allowed access via external sharing will depend on each organisation, but it is a good way to reduce the volume of duplication that happens when content is attached to emails. It can also be monitored.

Avoiding access control complexity should also help to improve information security, by ensuring that controls are more easily understood.

Tip 5 – Avoid storing too much and/or unrelated content together

SharePoint sites (including those linked with Teams) are a form of logical aggregation or container. And you can store a LOT of content on those sites. According to the Microsoft site ‘SharePoint Online limits‘:

A library can have up to 30 million files and folders. When a list, library, or folder contains more than 100,000 items, you can’t break permissions inheritance on the list, library, or folder.

But, as the saying goes, just because you can doesn’t mean you should.

It is all too easy to see the ‘Documents’ library of every SharePoint site (especially Teams-linked sites) as the equivalent of a top level folder in a network file share with multiple folder hierarchies. This might seen quite appealing and simple to use at first, but after several years, the ‘Documents’ library can end up a lot of content, not all of which is related to the site’s original intended purpose.

After 10 years, the content is likely to resemble an uncontrolled network file share, with redundant, trivial and outdated content all over the place. With potentially up to 30 million items, this will make managing the content so much harder.

As much as possible, try to ensure that SharePoint sites are based on logical business functions and the libraries in those sites mapped to business activities.

This is not always easy; for example, many smaller organisations have a ‘corporate services’ type function that includes a range of business activities, including managing property, general admin, legal, HR/personnel, fleet and corporate meetings etc. While all of this content could be stored in a single SharePoint site, there is likely to be a requirement to restrict access to content (see previous point) which will only result in increasingly complex permission controls and support issues over time. Mixing unrelated content could also become a nightmare for compliance and records management.

A better, more sustainable, option would be to create multiple SharePoint sites (or Teams) with multiple libraries, linked via a hub site as necessary. This approach will also make it easier to manage records in the longer-term.

Feature image – original source unknown

Posted in Compliance, Exchange Online, In Place Records, Information Management, Records management, SharePoint Online

In place vs in place management of records in Microsoft 365

The ability to manage records ‘in place’ in SharePoint has existed since around 2013. But this is not the same thing as leaving records where they were created or captured and managing them there – ‘in place’.

This post explains the difference between the two ‘in place’ options. In brief:

  • The Microsoft ‘in place’ model is based on making the distinction between non-records content and content declared as records (as per DOD 5015.2), that may be stored in the same SharePoint site, or using Exchange in-place options.
  • The other ‘in place’ model is simply based on leaving records and other content where they were created or captured, and managing it there – including (where necessary) by applying the ‘in place’ options in the previous point.

The Microsoft in-place model

SharePoint

The Microsoft in-place model for managing records in SharePoint is based on the requirement to comply with the US Department of Defense (DOD) standard titled ‘Design Criteria Standard for Electronic Records Management Software Applications’, usually known by its authority number – DOD Directive 5015.2, Department of Defense Records Management Program, originally published in 11 April 1997.

Section C2.2.3 ‘Declaring and Filing Records’ of the standard defines 26 specific requirements for declaring and filing records, including the following points:

  • The capability to associate the attributes of one or more record folder(s) to a record, or for categories to be managed at the record level, and to provide the capability to associate a record category to a record
  • Mandatory record metadata.
  • Restrictions on who can create, edit, and delete record metadata components, and their associated selection lists.
  • Unique computer-generated record identifiers for each record, regardless of where that record is stored.
  • The capability to create, view, save, and print the complete record metadata, or user-specified portions thereof, in user-selectable order.
  • The ability to prevent subsequent changes to electronic records stored in its supported repositories and preserving the content of the record, once filed
  • Not permitting modification of certain metadata fields.
  • The capability to support multiple renditions of a record.
  • The capability to increment versions of records when filing.
    Linking the record metadata to the record so that it can be accessed for display, export.
  • Enforcement of data integrity, referential integrity, and relational integrity.

Microsoft’s initial guidance on configuring in place records management describes how to activate and apply this functionality primarily in SharePoint on-premise. It is still possible to apply this in SharePoint Online (but see below). The SharePoint in place model refers to a mixed content approach where both records and non-records can be managed in the same location (an EDMS with RM capability):

Managing records ‘in place’ also enables these records to be part of a collaborative workspace, living alongside other documents you are working on.

The same link above, however, also refers to newer capability that was introduced with the Microsoft 365 Records Management solution in the Compliance admin portal. This new capability allows organisations to use retention labels instead to declare content as records when the label is applied, which ‘effectively replaces the need to use the Records Center or in-place records management features.’

The guidance also noted that, ‘… moving forward, for the purpose of records management, we recommend using the Compliance Center solution instead of the Records Center.’

Exchange

A form of in-place management has also been available for Exchange on-premise mailboxes, with in place archiving based on using archive mailboxes – see the Microsoft guidance ‘In-Place Archiving for in Exchange Server‘.

One draw-back of this model is that the (email) records in these mailboxes were not covered by the same DOD 5015.2 rigor as those in SharePoint, but they could at least be isolated and protected against modification or deletion, for retention, control and compliance purposes.

Archive mailboxes, including ‘auto-expanding archives’, also exist in Exchange Online. In the Exchange Online archiving service description, it is noted that:

Microsoft Exchange Online Archiving is a Microsoft 365 cloud-based, enterprise-class archiving solution for organizations that have deployed Microsoft Exchange Server 2019, Microsoft Exchange Server 2016, Microsoft Exchange Server 2013, Microsoft Exchange Server 2010 (SP2 and later), or subscribe to certain Exchange Online or Microsoft365 plans. Exchange Online Archiving assists these organizations with their archiving, compliance, regulatory, and eDiscovery challenges while simplifying on-premises infrastructure, and thereby reducing costs and easing IT burdens.

The new ‘in place’ model

A newer form of in-place records management has appeared with Microsoft 365.

Essentially, the new model simply means leaving records where they were created or captured – in Exchange mailboxes, SharePoint sites, OneDrive or Teams (and so on). and applying additional controls where it is required.

The newer model of in place records management is based on the assumptions that:

  • It will never be possible to accurately or consistently identify and/or declare or manage every record that might exist across the Microsoft 365 ecosystem. For example, it is not possible to declare Teams chats or Yammer messages.
  • Only some and mostly high value or permanent records, will be subject to specific additional controls, including records declaration and label-based retention.
  • The authenticity, integrity and reliability of a some records may be based more on system information (event metadata) about its history, than by locking a point-in-time version.

Microsoft appear to support this dual in place model with their information governance (broader controls) and records management (specific controls, including declaration) approach to the management of content and records across Microsoft 365, as described in the Microsoft guidance ‘Information Governance in Microsoft 365‘, which includes the graphic below, modified to show the relationship between the two in place concepts.

The relationship between Microsoft’s ‘in place’ focussed records management, and managing everything (including records) in place.

In place co-existence

Can both in place models exist? Yes. There is nothing to prevent both in place models existing in the same environment, in which some records may need to be better managed or controlled than others, but it is important to understand the distinction between the two when it comes to applying controls.

Image: Quarantine Building, Portsea, Victoria Australia. Andrew Warland 2021

Posted in In Place Records, Records management, Retention and disposal

Setting retention labels on folders in SharePoint document libraries

A common question asked by many organisations is whether Microsoft 365 (M365) retention policies – labels in particular – can be applied to folders in SharePoint document libraries so the content in those folders will have the same label.

The quick answer is yes, but it is a manual process and – for all its perceived benefits – is likely to be more of an administrative and support burden and not worth the effort. Folders should NOT be thought of as the replacement for ‘files’ (aggregations of individual records), but more like dividers in a lever arch (= the document library).

This post describes how labels can be applied to and work with folders, including in SharePoint sites linked with Teams. It also suggests alternative options.

How retention labels are applied to a library

Retention labels are created in the M365 Compliance portal under either the Information Governance > Labels or Records Management > File Plan sections.

Where labels are created in the Information Governance section of the Compliance portal

Labels created in the Compliance portal do not do anything once created; they must be applied to content in various ways to make them work. This includes by:

  • Publishing one or more labels as part of a retention policy to various locations including SharePoint sites, Exchange mailboxes and OneDrive (but not Teams – see screenshot of available locations below). In this scenario, each label will be visible to – and selectable by – end-users.
  • Auto-applying them to the same locations based on various options, including (for E5) trainable classifiers
  • Adding them to Content Types used in SharePoint Syntex.
Locations where labels can be published

Publishing labels to SharePoint sites

When one or more labels are published to SharePoint sites they don’t do anything until they are ‘manually’ enabled through one of the following options:

  • On each individual document library via the library settings option ‘Apply labels to items in this list or library’ (see screenshot below)
  • On each individual folder in a library (via the information panel, see screenshot below)
  • On each individual object in the library (also via the information panel)

Applying a label to the library

A label can be applied to the entire document library via Library Settings, as shown in the screenshot below.

Note that the ‘None’ option is shorter if no labels have been published here

If the drop-down option is set to ‘None’, and there are no options to choose from, it means that no labels have been published to this SharePoint site.

If labels exist, they will appear in the drop down list (below the default ‘None’). Note that only one label can be set as the default for the library. If the check box ‘Apply label to existing items in the library’ is selected, this will apply the label to all existing items. It will also likely override any existing label that may have been applied.

When the retention label has been applied to a library, the label only applies to the non-folder objects stored in the library as can be seen in the option below. That is, the retention label is NOT applied to the folders by default.

Document library folders without retention labels

The retention label can be seen when the folder is opened:

Content inside a folder, with retention labels applied

Applying a retention label to a folder or document

It is also possible to apply a retention label to a folder or object stored in the folder via the information panel, even when a default library label has been set, as shown below. This can be done on each individual folder including, for Teams-based sites, each folder that maps to a channel.

When applied to a folder in this way, any content stored in the folder will inherit that retention label.

Documents stored inside the June folder have inherited the folder’s label

If a default label has already been applied at the library level, the folder-based label will replace it, although in testing this, one of the original default labels wasn’t replaced automatically as shown below, but could be manually changed via the information panel.

Implications for Teams-based records (Files)

Every Team in MS Teams has an associated SharePoint site linked with the underlying Microsoft 365 Group.

Every non-private channel in the Team maps to a folder in the Documents library of the SharePoint site as can be seen in the two screenshots below. (Every private channel has a separate SharePoint site that would be covered by a separate retention policy).

The Team’s channels
Four channel-linked folders in a Teams-based SharePoint site

Keep in mind that retention labels remove the ability to delete objects stored in the library (including via the ‘Files’ tab in a Team). If end-users are working in Teams, this could be annoying and potentially put them off using Teams. However, end-users can remove the label by navigating to the SharePoint site and removing the label via the Information panel.

Why folder-based retention labels may not be a good idea

The default options to apply retention labels to content stored in SharePoint document libraries are:

  • By applying them at the library level. This can apply the label to all existing (and future) content stored in the library but does not apply to folders.
  • Through the auto-application of labels.
  • Via SharePoint Syntex using labels on Content Types.

Applying retention labels to individual folders in a document library is a manual-intensive process, one that may be a waste of time given the potential number of libraries that can exist and the ease with which they can be removed by end users.

Additionally, applying retention labels to the channel-linked folders of Teams may be pointless if end users:

  • Store documents at the same level as the channel-linked folders; that is, ‘above’ the folder structure.
  • Create new folders via a synced library or SharePoint. These folders are not linked to channels.
  • Create new libraries in the SharePoint site.

Keep it simple

It is very easy to deliberately or inadvertently establish over-complicated retention settings for content stored in SharePoint, especially as there is currently no simple way to see what label has been applied where.

Given the retention period linked with retention policies generally, there is a good chance that the person who applied the labels may not be around when the retention period expires, or to keep an eye on what has been applied or changed over time.

The best retention intentions may be overruled by practical necessity.

The best retention model, in my opinion, is a simple one that does not get in the way of end-users but ensures that records will be kept for a minimum period required. So, instead of applying retention labels to folders, especially on Teams-based SharePoint site libraries, it is recommended to:

  • Start by trying to avoid mixing content with different retention periods in the same SharePoint site or Team, or document library. That will make it easier to manage the retention outcomes. (If you can’t avoid mixing content, you may need to use auto-application of labels including via Syntex or trainable classifiers).
  • Use ‘back-end’ safety net retention policies applied to all SharePoint sites. This ensures a minimum retention period and does not get in the way of end-user activities.
  • Use retention labels on site libraries where more granular retention is required. Ideally, apply them as the default to all the content in a single document library (including the default library for all Teams-based SharePoint sites) and – preferably – only apply the labels when the content is inactive and the library can be made read only, to protect the records from that point.
  • Only use multiple labels on folders when (a) all the labels applied to the site relate to the same function/activity pair or subject matter, and (b) the content is largely inactive. Ideally, avoid folder-based retention to avoid complication in the future.