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)