Posted in Electronic records, Microsoft Teams, Records management, Retention and disposal, Training and education

What happens when you delete or edit sent Teams chats and posts

Teams chats and channel posts are a bit of a problem to manage as records because it is not easy to capture them – either individually or as a thread. The most common solution is to screenshot them but this is hardly ideal.

End-users may be able to delete or edit sent chats and posts. What happens to these? How can you know if a sent message was deleted or edited? Can you see the version history for edited messages?

This post explains.

Settings that allow deleting and editing

The Messaging policies section of the Teams admin center (https://admin.teams.microsoft.com/policies/messaging) contains the global settings that allow end-users to delete and edit sent chats and channel posts.

In addition to the global settings, Team Owners may also modify the same settings for a Team only if the above options are enabled:

Editing sent chat messages

Here is an example of a sent chat message. We can see from the little ‘eye’ icon on the right of the sent message that the recipient has seen it.

The image below is the same message that has now been edited. The time stamp doesn’t change and no version history is available to the sender or recipient (but see below). The person who received it may not necessarily notice that the text was edited (who goes back to read messages?).

Editing sent channel posts

The following is an example channel post. Only the author of a channel post can edit it.

If the message is edited, this is indicated as shown but the time stamp stays the same. Again, no version history.

How to see the version history for chats and posts

A ‘compliance copy’ of all Teams chats and channel posts is stored in Exchange Online mailboxes until they are deleted. If there is no retention policy set for these chats and posts, deleted messages are (permanently) deleted relatively quickly. If there is a retention policy, they remain in the mailbox until the end of the retention period and are then subject to whatever action is set on the policy (e.g., destroy, do nothing).

The only way to check the previous versions of a chat or post is to create a Content Search case in the Compliance admin center. However, access to Content Search is restricted because it allows the person with access to search across all emails, Teams chats and posts, OneDrive and SharePoint.

Consequently, content searches for Teams chats/posts are likely to be only carried out for specific reasons – for example, threatening or harassing messages that were then edited.

The image below shows the results of a content search for myself as the author. The search returned two results for the edited channel post – one for the original and one for the edited message. Every time the message is edited, another copy will be retained. Note that the visible timestamp hasn’t changed.

When the messages are exported (as a .eml file), the only difference between the two is the ‘CorrelationVector‘, ‘a format and protocol standard for tracing and correlation of events through a distributed system based on a light weight vector clock’.

  • Original message correlation vector: “phE37FG2rU289DE7MmZndA.1.3.1.1194298459.1.0”}
  • Edited message correlation vector: “kZOVelgz1UWNU5DIxmO+NQ.1.4.1.1221869943.1.0”}

Everything else (apart from the edited text) is identical.

What happens when messages are deleted?

Microsoft’s guidance on Teams messaging policies dated 25 November 2021 appears to show no difference between deleting chat and deleting sent messages.

If deleting is allowed, what happens to these deleted chats or messages depends on whether a retention policy has been applied. Either way, if the chat or post has been deleted, it will be indicated as follows:

Deleted chat
Deleted channel post

When a chat or message is deleted:

  • If there is no retention policy, the messages are completely deleted within a day or a few days and cannot be found after that via a content search.
  • If a retention policy has been applied to chats and posts and it hasn’t expired, the messages can be found via a content search.
  • If a retention policy that applied to these messages has expired, then the messages will be deleted within a few days unless the disposal action is ‘do nothing’ or ‘keep forever’.

Implications for records

Organisations need to decide if Teams chats/posts may be records and, if they are, how they are to be captured especially given that a ‘compliance’ copy is stored in Exchange mailboxes until they are deleted.

At least four approaches are possible:

  • Allow end-users to delete Teams chats/posts whenever they like, with no retention applied. Chats or posts that are not deleted will simply remain until the Team is disposed of. This approach has potential implications if chats/posts contain harassing or offensive content.
  • Set a relatively short-term retention period for both (e.g., 30 days or 3 months), on the basis that chats/posts are not official records – but end-users are encouraged to capture any that could be records, probably as screenshots stored in SharePoint (or somewhere else). This approach provides the option to recover a message within a reasonable period of time.
  • For Teams 1:1 chats (that are stored in the personal mailboxes of participants), set the same retention period as the Exchange mailbox.
  • For Teams channel posts (that are stored in the mailbox of the associated Microsoft 365 Group), set the same retention period as the SharePoint content.

Managing Teams chats and posts as records is not a simple process. Organisations should consider the implications of allowing end-users to delete or edit sent chats or posts and set retention periods accordingly.

Addendum – there are a number of third-party products that can capture Teams chats and posts. However, one of the biggest problems with any type of chat is that a related thread may contain several messages. It may actually be easier to focus on applying retention to the chats and posts stored in the mailboxes.)

Feature image – Miguel Á. Padriñán via Pexels.

Posted in Artificial Intelligence, Compliance, Electronic records, Information Management, Microsoft 365, Microsoft Viva, Records management, SharePoint Online

Changing patterns of office work

A recent (September 2021) Verge post titled ‘File Not Found‘ by Monica Chin (@mcsquared96) noted how pre-defined storage locations for digital content have become mostly redundant for the younger generation that grew up using Google to find content – ‘the concept of file folders and directories, essential to previous generations’ understanding of computers, is gibberish to many modern students.’

The post resonated for two specific reasons:

  • The way people create and access content in the modern digital environment, especially how they do this out of the office on mobile devices.
  • The enduring ‘requirement’ in many organisations to create pre-defined aggregations to store records, with an expectation that end-users will voluntary and consistently store content in those aggregations.

In my opinion, there is a fundamental clash between these two things in the modern digital world.

It reminds me of the transition to Web 2.0 from around 15 years ago. The ‘semantic web’ changed the way we interacted with the internet.

A diagram from 2009 showing how Web 2.0 would work

According to the University of Melbourne in a blog post in 2008, ‘Web 2.0 is the term used to describe a variety of web sites and applications that allow anyone to create and share online information or material they have created. A key element of the technology is that it allows people to create, share, collaborate and communicate. Web 2.0 differs from other types of websites as it does not require any web design or publishing skills to participate, making it easy for people to create and publish or communicate their work to the world.’

Fast forward ten years, and end-users can do just that, creating and publishing as much web content as they like through a host of apps, none of which requires a pre-defined folder structure to manage the content.

Is this the future for the modern digital office?

Aggregate or collate?

Expecting end-users to capture all digital content about the same subject in pre-defined aggregations has been a challenge since computers first appeared in the workplace. The fact that email systems have always been physically separate from other digital content stored on file shares didn’t help.

Organisations attempted to resolve this dilemma, with varying degrees of success, through ‘controlled’ folder structures on file shares, or acquiring EDM/ERM systems.

The success of these models was (and remains) often linked to the degree of compliance required by regulators, or the penalties for non-compliance. That is, the best document and records management systems were usually (and continue to be) in organisations that had a high compliance requirement. Everything else was about managing risk (and reputation).

The reality, for most organisations, is that not all relevant digital content is (or can be) captured in pre-defined aggregations. Some of the key ‘missing’ content may include emails, text and chat messages, content created in ‘personal’ spaces, and content not created using corporate systems. This is why FOI and discovery requests inevitably involve asking end-users to locate and produce relevant content.

So, it is just a waste of time to try to aggregate (some) digital records?

I think there is still a comfortable place for the creation and management of content in pre-defined aggregations, where it makes sense to do so and/or there is a specific compliance requirement to do this AND it works.

But, with some exceptions, pre-defined aggregations have a key shortcoming – they may not capture all digital content. Yahoo attempted to categorise the internet from 1994 (as ‘Jerry and David’s Guide to the World Wide Web’), when the reality was that most people preferred the simple Google search bar – without worrying about how the information may be have been aggregated or collated.

The modern workplace is heading in a similar direction. The illusion that all related digital content, of whatever type or format, can be grouped in pre-defined aggregations makes no sense. There is simply too much digital content and a lot of it cannot even be copied to or saved to a single aggregation point. Phone text messages have always been a case in point here.

What makes more sense, like Web 2.0, is to use technology to automatically find the connections between disparate digital objects and collate them in a way that makes sense in the context we want to see it. We already see this model in many online platforms that draw on our digital exhaust (and possibly our voices) to work out our interests or potential interests.

The digital office

The 2 November 2021 announcement of a range of updates to the Microsoft office.com portal, ‘Creating a hub for your content with office.com‘, is consistent with the need to address changing patterns of work and the shift away from pre-defined aggregations as the primary method of storing and finding all relevant content. Instead, the focus is on ease of creation, quick access to content that is relevant to the use based on their digital activities, search, and recommended actions.

The new office.com portal

As noted already, this new approach does not remove the requirement to create pre-defined aggregations; it simply needs to be understood that these may only contain some of the content or records. The rest may remain stored in email accounts or other systems, in many cases out of reach (thanks to access controls) to the people who may want to see it.

However, behind the scenes, the Microsoft Graph makes use of this information (‘signals’) to draw inferences and make recommendations including for content that the end-user can access. For example, Fred and Mary may chat in Teams or exchange emails about a given subject, but Fred is unaware that Mary is working on a document that he has access to. The Graph works out that this may be of interest to Fred and recommends it to him.

Microsoft 365 provides the capability to recommend content and, with products like Viva Topics, has the ability to automatically group relevant content beyond the scope of pre-defined aggregations.

It may not be able, or ever need, to completely replace pre-defined aggregations, but it is heading in the direction to make that scenario increasingly more likely.

Feature image: Photo by Rebecca Diack from Pexels

Posted in Compliance, Licences, Microsoft 365, Records management, Roles

What licences or roles are needed to manage records in Microsoft 365

One of the difficulties for many records managers new to Microsoft 365 is that they may not know or have access to everything they need to know to manage records in that environment.

This post provides an overview of the accounts, licences and roles that may be needed to manage records in Microsoft 365.

As will be seen, a good understanding of both (a) the options provided with different licence types, and (b) the roles and what access or functionality they provide, is essential. The simplest options may be summarised as follows:

  • Technically skilled or qualified records and information managers, including those who previously administered EDRM systems, could become SharePoint admins (an assigned role), ideally with a cloud-only account in addition to their normal user account.
  • Records and information managers with broader compliance-type responsibilities, including the requirement to access detailed audit logs, search across all content, establish and run eDiscovery cases, create and apply DLP policies, create and apply records retention labels and policies, and create and apply information protection labels, should be assigned the role of Compliance Admin or Compliance Data Admin. They should also be assigned the Global Reader role to be able to access reporting and details of all settings in the various admin portals. If there is sensitivity about this access, they could instead be assigned the Reports Reader role which provides access to (and the ability to download) usage reports in the Microsoft 365 admin portal.
  • Records and information managers who need to do most of the above excluding access to audit logs and some other features could be assigned the roles of Records Administrator and Reports Reader.

Accounts and licences

To access Microsoft 365 anyone will need an active Active Directory (AD) account and, except for Global Admins, a Microsoft 365 licence.

Microsoft 365 accounts may either (a) be synced from on-premise AD to Azure Active Directory (AAD), or (b) be cloud-based only (for admin accounts) as described below.

Administrator accounts

Global Administrators (GAs) have access to all parts of Microsoft 365. It is unlikely that records or information managers will be GAs. In organisations that outsource their IT, the IT provider will usually be the GAs, further limiting internal access and knowledge.

Microsoft recommend (‘Protect your Microsoft 365 Global Administrator accounts‘) that (a) there should be no more than four Global Administrator (GA) accounts, and (b) that GA accounts should always be created in the cloud and not be privileged accounts synced from AD. This is not always the case.

GAs do not need a Microsoft 365 licence.

In the same link above, Microsoft notes that ‘you should consider whether additional accounts with wide-ranging permissions to access the data in your subscription, such as eDiscovery administrator or security or compliance administrator accounts, should be protected in the same way’ – that is, created as cloud-only accounts.

These administrator accounts include the following:

  • Exchange Online administrator
  • SharePoint/OneDrive administrator
  • MS Teams administrator
  • Security administrator
  • Compliance administrator.

Note that certain ‘admin’ roles may be created to provide access to parts of the Compliance admin portal. These roles, which may not necessarily require a cloud-only account, are described under the ‘Roles’ section below.

Cloud-only account names should include a user ID to make it possible to identify the actual person assigned to the account who used it, including in audit logs. For example:

  • GA_jnguyen
  • SPOAdmin_achu
  • EXOAdmin_psmith
  • Compliance_ahaitham

Suitably qualified or skilled records and information managers, especially EDRMS admins, could be assigned either a SharePoint admin or Compliance admin account.

  • To be clear, this means that records and information managers should ideally have two separate accounts: (a) an admin account with a specific role (see below), and (b) their normal account.
  • Note that being assigned to an account doesn’t provide any access, yet. The account holder still needs a licence and a role.

Some organisations do not follow Microsoft’s advice and don’t create separate admin accounts for SharePoint/OneDrive, Exchange, Teams or Compliance/Security admins. Instead, they assign roles to normal end-user accounts (see below). This may be partially to reduce licencing requirements.

Licences

With the exception of the GA account, all other accounts must be assigned a licence to access the relevant parts of Microsoft 365. For example, a SharePoint admin needs a licence that includes access to SharePoint.

The type of licence that is assigned will affect what options the account can access. From a records and information management point of view:

  • E5, or the E5 Compliance add-on (for specific users), provides the highest level of recordkeeping functionality including all the options in the Compliance admin portal including Data Classification, Audit, Content Search, Advanced eDiscovery, Data Loss Prevention, Information Governance, Information Protection, and Records Management (including auto-application of labels based on trainable classifiers or SharePoint Syntex, and Dispositions).
  • E3 provides a basic level of functionality – mostly the ‘Information Governance’ part (retention labels, label policies and retention policies) of the Compliance admin portal (access to which requires a role – see below) and some other parts such as Audit (logs), Content Search, Data Loss Prevention, Information Protection, and eDiscovery.

See ‘Microsoft Information Governance in Microsoft 365‘ for more details of what is provided in the Compliance admin portal.

So, to summarise this section, records and information managers will need the following at a minimum to be able to manage records in Microsoft 365:

  • An admin account, or their normal account assigned a specific role (see below)
  • A licence (E5 or E3)

A licenced account will not provide access to anything more than the basic options available to all users, until the account has been assigned a role.

Roles

There are multiple roles in Microsoft 365 for a wide range of tasks.

Roles and custom roles (and ‘role groups’ that contain sub-roles) may be assigned to accounts via:

  • The Azure AD admin portal (~ 77 pre-defined roles most of which are repeated in the two dot points below)
  • The Microsoft 365 admin portal via ‘Role assignment’ (shows everyone who has been assigned that role) or applied directly on accounts (~ 64 Azure AD roles and ~ 13 Exchange admin roles)
  • The Compliance admin portal under ‘Permissions’ (9 Azure AD roles and 49 ‘Compliance centre’ roles). Same roles as the Security admin portal.
  • The Security admin portal under ‘Permissions and roles’ (9 Azure AD roles and 49 ‘Email and collaboration’ roles). Same roles as the Compliance admin portal.

Microsoft note that ‘admin roles give users permission to view data and complete tasks’. Therefore, they recommend to ‘give users only the access they need by assigning the least-permissive role’.

Most roles can be assigned to user accounts from either the Azure admin portal or the Microsoft 365 admin portal. Only the most common roles are listed below, most of the other roles can be viewed from the section ‘Show all by category’ below this listing. When a role is assigned to an account, the ‘Admin’ icon appears in the list of apps available to that account in office.com.

Organisations will need to decide what roles will be assigned to what accounts. The licence assigned to that account may affect what options the account can access through the role they are assigned to.

What roles do records and information managers need?

The most obvious roles for records and information managers accounts that are set in either the Azure or Microsoft 365 admin portals, are:

  • SharePoint admin
  • Global Reader
  • Reports Reader

The following roles that relate to the management of records that are set in the Microsoft 365 admin portal, Azure admin portal, or the Compliance admin portals are as follows:

  • Compliance admin
  • Compliance data admin
  • Records Administrator (only set in the Compliance admin portal)
  • Records Management (only set in the Compliance admin portal)
  • Knowledge Administrator (only set in the Azure admin portal)
  • Knowledge Manager (only set in the Azure admin portal)

Details of what these roles can do or have access to are described below.

In most cases, the simplest option will be to grant the records or information manager account (preferably a cloud-only account) the ‘full’ Compliance admin role or alternatively the Compliance Data admin role (with slightly reduced capability).

While additional roles, sub-roles, or even custom roles may be assigned or created for specific purposes, these may only be required in more complex organisations where those roles can be assigned to someone with that responsibility. For example, a ‘Privacy Manager’ person/account could be assigned the Privacy Management role

SharePoint admin

Records or information managers who were EDRMS administrators might be assigned the SharePoint admin role, including in support of more technical SharePoint admins.

Accounts assigned to the SharePoint admin role can create new sites and manage the SharePoint environment, including managing the Managed Metadata Term Store. They can guide site owners how to use their sites, including:

  • Creating and applying site columns and content types to libraries and lists.
  • Creating and configuring new document libraries and lists
  • Editing page content

SharePoint admins may apply, or help site owners and members apply, retention labels and recover content from the Recycle Bins and Preservation Hold library (if a retention policy has been applied to the site).

Global Reader

This role provides read-only access to all of the options in all the Microsoft 365 admin portals. Accounts assigned to this role can also download reports. It is a useful role to have if the records or information manager needs to view settings and reports.

Reports Reader

This role provides read-only access to various sections of the Microsoft 365 admin portal only including: Users, Teams & Groups, Roles, Billing, Settings, Reports (Usage reports), Health (but not the Message Centre). Accounts assigned to this role can also download reports.

Compliance admin/Compliance Data admin

Accounts assigned to the Compliance admin role group have full access to the Compliance admin portal, including the following areas:

  • Data classification (E5). Access to trainable classifiers, content explorer, activity explorer.
  • Reports (Dashboards).
  • Audit logs (3 months for E3, 12 months for E5)
  • Content Search (search across all Exchange mailboxes (including Teams compliance chats and posts) and SharePoint/OneDrive)
  • Data Loss Prevention (create policies based on a range of criteria)
  • eDiscovery (search for content, apply legal holds)
  • Information Governance (with E3 licences, basic retention labels, label policies, and retention policies)
  • Information Protection (information sensitivity labels)
  • Records Management (with E5 licences, more advanced retention label options, label policies, dispositions)
  • Privacy Management

The Compliance admin role group includes all the following sub-roles. Items marked with an asterix are not included in the Compliance Data Admin role group and will mostly not be required. (That is, most records and information manager accounts could be assigned the Compliance Data Admin role).

  • Case Management *
  • Compliance Administrator
  • Compliance Search
  • Data Classification Feedback Provider *
  • Data Classification Feedback Reviewer *
  • Data Investigation Management *
  • Device Management
  • Disposition Management (manage disposition)
  • DLP Compliance Management
  • Hold *
  • IB Compliance Management
  • Information Protection Analyst
  • Information Protection Investigator
  • Information Protection Policy Admin
  • Information Protection Reader
  • Manage Alerts
  • Organization Configuration
  • RecordManagement (‘manage and dispose record content’)
  • Retention Management (‘create retention labels’)
  • (‘Sensitivity Label Administrator’ is included in the Compliance Data admin role)
  • View-Only Audit Logs
  • View-Only Case *
  • View-Only Device Management
  • View-Only DLP Compliance Management
  • View-Only IB Compliance Management
  • View-Only Manage Alerts
  • View-Only Recipients
  • View-Only Record Management
  • View-Only Retention Management

Records Administrator/Records Management/Knowledge Administrator

There are three specific role groups that provide more restricted records management-related capability.

The Records Administrator role group includes access to most of the day-to-day functionality that will be required, via the following sub-roles.

  • Disposition Management
  • RecordManagement
  • Audit Logs (but note that the account assigned this role must also be added to the Records Administrator role in the EXO admin portal to access the logs)
  • View-Only Audit Logs (comment as above)
  • Compliance Search
  • Case Management
  • Retention Management
  • Hold
  • Journaling (in EXO admin)
  • Messaging Tracking (in EXO admin)
  • Transport Rules (in EXO admin)

The Records Management role group include the following sub-roles:

  • Disposition Management
  • RecordManagement
  • Retention Management

This role provides access to most of the records management related options in the Compliance admin portal except the Audit logs.

The Knowledge Administrator role group provides access to a number of options in the Compliance admin portal has a single sub-role.

  • Knowledge Admin

The Knowledge Manager role provides access to a number of options in the Compliance admin portal.

Summarising the options

In summary, records and information managers will need the following at a minimum to manage records in Microsoft 365:

  • An active AD or AAD account
  • A Microsoft 365 licence, ideally E5 or E5 Compliance add-on. E3 may be suitable but provides fewer options.
  • One or more roles:
    • SharePoint Admin, if they will be managing SharePoint.
    • Compliance admin. This is suitable for most advanced records management related activities including accessing audit logs, creating, applying and managing retention labels and policies, DLP, information protection and more). Alternatively, one of the reduced Compliance roles.
    • Global Reader (or Reports Reader) to view usage reports/dashboards and settings.

Whatever role is required, records and information managers need to work closely with IT to determine the most appropriate role based on business needs.

Posted in Information Management, Knowledge management, Microsoft 365

Crossing the gangplank – How Microsoft 365 supports the capture of tacit knowledge

This post is dedicated to the memory of my former colleague and good friend Walter de Ruyter who passed away on 4 October 2021. The text is based on Walter’s many presentations and our close collaboration over almost 10 years.

Henri Fayol (1841 – 1925) was a French mining engineer who developed a general theory of business administration in his 1916 book, “Administration Industrielle et Générale,”. In that book, Fayol defined fourteen ‘Principles of Management‘, the ninth of which was the ‘scalar chain’. A scalar chain is ‘the line of authority from top management to the lowest ranks‘. In other words an organisational hierarchy.

In his 1937 paper ‘Relationship in Organization’, V. A. Graicunas showed that the number of subordinates in an organisation hierarchy could have an impact on a supervisor’s ability to control them (the ‘span of control’). If the span of control was too large, it could become difficult to maintain adequate controls. (Source: Graicunas, V. A., “Relationship in Organization (pp.183-187), Papers on the Science of Administration, edited by Luther Gulick and Lyndall F. Urwick, published by Columbia University’s Institute of Public Administration in 1937.)

Fayol had noted that communications should generally follow the scalar chain up and down, but in an emergency, there may be a need for a ‘gang plank’ or bridge between business areas to allow direct communication between subordinates at the same level.

Fayol’s model of communication became known as ‘Fayol’s Bridge’ or ‘hierarchy jumping’. It is commonly described in the following simple diagram.

Fayol stated that ‘It is an error to depart needlessly from the line of authority, but it is even greater one to keep it when detrimental to the business’.

(Incidentally, there is no shortage of criticism of this model, summarised neatly on this web page ‘Henri Fayol: Gangplank and criticism‘ dated 4 December 2020, accessed 5 October 2021.)

The problem with tacit knowledge

Almost every organisation has three broad levels of knowledge:

  • Codified knowledge in formal policies and procedures
  • Formalising knowledge in draft policies and procedures and other guidance.
  • Tacit knowledge.

Tacit knowledge:

  • Is often the operational and often dynamic expertise held by employees usually in lower levels of the organisation (‘subordinates’), the people who are ‘hands-on’ and actually ‘do the work’.
  • Is the information in subordinate’s heads that doesn’t always make it into codified knowledge and often ‘walks out the door’ when the employee leaves.
  • May be extracted from some employees (e.g., through formal interviews) and/or float ‘upwards’ along the scalar chain until it becomes codified. Typically this doesn’t always happen as lower-level operational knowledge doesn’t become codified organisational procedures, but remains as ‘local’ work practices.

Crossing the gangplank

The emergence of always-on mobile devices connected to the internet, messaging and social media apps in the early 2000s provided a simple but unofficial way for employees in the same organisation (and in others) to connect with each other across the scalar chain of command.

These unofficial methods of communication, using tools not controlled by the organisation, sometimes resulted in unease for supervisors (who were not included in the communications).

Disallowing ‘gangplank crossing’ in this manner by subordinates might, among other things, result in mistrust of or by subordinates and the imposition or enforcement of conventions (‘the way something is always done’) or ‘groupthink’ (Irving Janis, 1972), where the desire for consensus among critical stakeholders could override the ability to evaluate alternatives.

Groupthink means that individuals typically avoid raising controversial issues or alternative solutions, and there is a loss of individual creativity, uniqueness and independent thinking – sometimes the very source of a lot of tacit knowledge.

Communities of practice

In many medium to large organisations, and especially those with employees distributed across a wide geographical area, employees may benefit from access to operational tacit knowledge, especially – but not exclusively – in an emergency or to support often routine operational business decisions or activities that are not detrimental to business outcomes (and are not otherwise codified). A simple example might be to ask how to fix something.

In the mobile device period (mostly to around 2005), such knowledge might be shared by phone or other often asynchronous communication methods (e.g., email, telex, fax) that contained information that was largely inaccessible.

The arrival of mobile devices and in particular social media-type apps and messaging made these processes more synchronous and the information more accessible. But in many cases, employees were in touch with each other informally using non-official methods and/or applications (Facebook for example).

The new networks

Microsoft recognised the existence of these unofficial networks and began to acquire and/or develop or release new communication options in Office 365 – Yammer (previously a web based standalone system), Office 365 Groups, and then Microsoft Teams.

These new models had one thing in common – they tapped into these often lower-level employee networks, allowing people in those networks to communicate using Microsoft tools (to keep the content in-house) rather than allow third-party products.

Benjamin Niaulin from ShareGate described these new networks in a blog post from 2014 titled ‘Office 365 Redefines Knowledge Management‘ (accessed 5 October 2021. The article included the following diagram which illustrates the difference between the traditional scalar chain model and new responsive networks.

Whether they were part of a Yammer group/community, an Office 365 group using ‘conversations’ in Outlook, or using Teams chat or channel posts (and supported by content stored in SharePoint) employees now had the ability to tap into the tacit knowledge of other employees.

  • Employees doing the same job on planes or trains could easily connect and communicate with each other.
  • Employees with knowledge about something could promote this skill in their Active Directory profile to make it easier to find them.
  • Group chats (in Yammer, Outlook or Teams) allowed a community of practice to share tacit and uncodified knowledge more readily.

And underneath all this activity, the Microsoft Graph monitored the connections, relationships and ‘signals’ between all the different elements of the environment, allowing it to make recommendations or suggestions. Microsoft Viva extends on this knowledge base.

Allowing employees to connect in this way supported the creation of communities of practice, where certain formal work conventions (‘we’ve always done it this way’) could be tested.

So, rather than an employee defaulting to a established convention, the employee (in conversation with others on a collaborative platform) could access other insights, capture and apply them through a consensus point, under a subject matter expert (SME) or lead. The SME could then, if appropriate, begin the process of formalising the knowledge up the scalar chain to become codified.

But this is not the end of the process, ideally, codified knowledge that guides operational practices should be reviewed regularly within these communities of practice, especially where there are new or emerging situations or exceptions.

Collaborative Knowledge Management (KM) communities create a transition point where there is a balance between what parts of information traffic needs to flow up and down the hierarchy model captured as codified explicit knowledge whilst capturing the information flow across the stream/matrix with acceptable controls on delegation through a consensus point.

Instead of being hidden away in emails or personal drives, communities of practice can create valuable and searchable content and insights that can be accessed by new employees who join the community. As noted above, the content in these communities will also be picked up via the Graph and provide additional rich insights into the knowledge gained in this way.

Featured image – Photo by fauxels from Pexels

Posted in Electronic records, Governance, Information Management, Microsoft 365, Microsoft Teams, Records management, Retention and disposal, SharePoint Online

A basic retention model for Microsoft Teams

In my previous post about managing inactive Teams, the third option listed was to apply retention policies to those Teams. It included the graphic below.

This post provides more details of a basic retention model that can be applied to both active and inactive Teams.

Key takeaways

Key takeaways from this post for records and information managers:

  • Every Team has a ‘Posts’ (group chat messages) and ‘Files’ (documents etc) tab, and usually also starts with a Wiki tab (which can be removed). Other tabs may be added via the + option.
  • A Team in Microsoft Teams is not a single container or aggregation for the capture and storage of records. Almost all the records in a Team are stored in a hidden folder in Exchange Online (EXO) mailboxes (posts) or SharePoint Online (SPO) (files). Some records (conversations) may also be created and captured in the EXO mailbox of the associated Microsoft 365 (M365) Group.
  • It is not possible to apply a single retention policy to a Team; at least two separate policies will be required – one policy for the Team channel posts of EVERY team, and one or more policies for the content captured in SPO sites (files) or groups of sites.
  • Some records, created in and accessible from Teams, may be stored in other M365 applications (e.g., Tasks, Forms, WhiteBoard, etc) or third-party applications. It is not possible to apply any Microsoft 365 retention policy to records created by or captured in these applications.
  • Records and information managers should have access to the details (not necessarily the content) of every M365 Group, Team, and SPO site in order to establish a plan for the creation and application of retention policies to Teams. At a minimum, they should be assigned the Global Reader role (for details of M365 Groups and SPO sites) and the Compliance admin role (for retention policies).
  • It is relatively easy to overcomplicate the retention model for Teams, for example by applying separate retention labels to different folders and sub-folders in each channel ‘files’ tab.
  • Try to keep the model simple for as long as possible.

Core components of a Team

The main components of every Team are shown in the diagram below. If private channels are not allowed in the organisation, ignore the top two left and right elements.

The relationship of a Team to its M365 Group, Exchange mailbox and SharePoint site, showing where the content is stored (dotted lines).

As shown in the diagram above:

  • Every Team is directly linked with an M365 Group. Every M365 Group has an Exchange Online (EXO) mailbox and a SharePoint Online (SPO) site.
    • The Team, M365 Group, SPO site, and mailbox address (teamname@) all share the same name. The original name (which should be brief, <20 characters if possible) and the display name may be different.
    • The Owners and Members of the Team are the Owners and Members of the M365 Group and those Groups are added to the SPO site Owners and Members permission groups respectively.
  • A ‘compliance copy’ of every post in a normal channel is copied from the Azure-based Teams chat service (which is always inaccessible) to a hidden folder of the EXO mailbox of the M365 Group linked with the Team.
    • Where private channels are allowed, a ‘compliance copy’ of every post in a private channel is copied to a hidden folder of the ‘personal’ EXO mailboxes of all participants in the private channel.
  • Any content created or captured in the ‘Files’ tab of the Team channels is stored in the SPO site of the M365 Group linked with the Team. If any lists are created, they are either stored on the same SPO site or are linked from another site.
    • Where private channels are allowed, a separate SPO site is created (using the name of the ‘parent’ site followed by a hyphen then the private channel name, e.g., parentsitename-privatechannelnamesite). Any content created or captured in the ‘Files’ tab is stored in that SPO site.

So, a Team is a combination of at least four elements: the Teams user-interface (and back-end database), an M365 Group, a SPO site, and an EXO mailbox. The mailbox is used for three main purposes:

  • Email-based ‘conversations’ (when used).
  • Calendaring.
  • Storage of Teams posts.

This is why it is not possible to apply a single retention policy to a Team.

The basic retention model

The basic retention model for Teams assumes the following:

  • If the organisation’s retention schedule/disposal authority does not include coverage for Team posts (chat messages) and also general Team chats, there is a legally defensible policy that defines how long Team channel (including private channel) posts (and chats) will be retained. Note: This policy will define a single retention period for ALL posts and and a separate policy for ALL chats.
  • Records and information managers know the details of every M365 Group, Team (including number of private channels) and SPO site (including last activity and number of files).
  • One or more retention policies will be created for SPO sites.
  • One or more retention policies may be created for M365 Groups.
  • Unless it is done ‘manually’, there will be no review process before the content is destroyed at the end of the retention period.
  • No label-based retention policies will be applied (at this point). They may be added later as required (see below).
  • Unless the option to auto-expiry M365 Groups is used, there will be a manual process to delete inactive and empty M365 Groups or Teams; deleting either will also delete the linked SPO site.

Creating retention policies

Retention policies are created in the Information Governance section of the M365 Compliance admin portal under ‘Retention policies’.

Generally speaking, organisations should not create many of these policies as they should ideally target entire workloads (all SPO sites, all EXO mailboxes, etc) or in some cases major groupings (e.g., EXO mailboxes of senior executives, all other mailboxes).

And remember, these policies do NOT destroy the container (Team, SPO site, EXO mailbox), only the content in those containers.

Every new retention policy has three parts.

Name

The name of the retention policy should be easily recognisable, for example ‘Teams channel posts 7 years’ (all encompassing, for all channel posts, see next dot point), or ‘General SPO site retention 7 years’. The name section also includes a description that should always be used to link the policy to details in a retention schedule/disposal authority or corporate policy.

Location

The ‘location’ element is where the complexity arises as it is not possible to create a single retention policy for all the elements in a Team. Selecting either ‘Teams channel messages’ or ‘Teams private channel messages’ will disable all other options. It is not possible to select ‘SharePoint sites’ or ‘Microsoft 365 Groups’ AND any of the Teams options in the same policy.

Because of this limitation, at least two separate retention policies will be required for a basic retention model, with an additional one for private channels (if required):

  • A retention policy for either all or selected SharePoint sites, including private channel sites. The simplest model is to create a single retention policy for all SharePoint sites. This creates a preservation hold library on every site, retaining all deleted content for the minimum period required. Alternatively, and especially if there is a way to ‘group’ SPO sites (e.g., all project team sites), create retention policies for those groups and add in the site names. Always keep in mind that a retention policy applied to the SPO site has no connection with or impact on the channel posts.
  • A retention policy for all Teams channel messages. Note that this cannot include or exclude any Teams – it’s all or none. Depending on the retention selected for channel posts (next point), this could mean that channel posts are destroyed before (or after) the Team’s SPO content.
  • A retention policy for all Teams private channel posts. Similar to the previous point, this is an ‘all or none’ policy.

If the Team is also making use of the M365 Group’s ‘conversations’ in Outlook, consideration may also be given to creating a retention policy for M365 Groups (or included/excluded Groups). This policy will cover (a) Group ‘conversations’ and (b) the SharePoint site linked with the Group/Team. It will NOT cover the Team channel posts that may be stored in the M365 Group EXO mailbox. Note: It is possible to select just the M365 Group mailbox OR the M365 Group’s SPO site in this policy via a PowerShell script.

Retention period

Retention options are shown in the screenshot below. These options are the same for every retention policy.

Retention policies either automatically delete content after a minimum period or do nothing (includes the ‘retain items forever’ option). There is no disposition review. This means that the content in the SPO site and Team channel (including any ‘deleted’ content, which is not actually deleted, just hidden) simply disappears when the retention period expires.

Retention variations

Organisations may of course have different requirements or decide to apply retention differently. Each of these will still be some variation on the above model.

In most cases, there should be at least one retention policy in place for each of the different elements that make up a Team – the M365 Group, the SPO site, the channel posts, the private channel posts. Whether those policies have the same retention period will be up the organisation to determine, but in all cases, the details should be documented somewhere as currently this information is not easily available.

Retention labels

It is not possible to apply retention labels to Teams channel or private channel posts (or chats). There is only one option, and that is a single retention policy for each of these.

Retention labels may be applied to the content stored in the Teams linked SPO site, and these may be applied instead of using retention policies. This may be an effective model when combined with auto-expiry of M365 Groups as this (auto-expiry) will not occur if the content is subject to an active retention policy or retention label.

However, applying labels to the content stored in each Team channel ‘files’ tab has the potential to be a very complicated model that will become almost impossible to monitor or manage in time.

Each channel ‘files’ tab maps to a folder with the same name in the Documents library of the linked SPO site. As each Team channel may have been created for the records of a different subject with a different retention requirement, this means that each folder (or potentially even sub-folders) in the library may have a different label.

As retention labels (and policies) apply to individual items in the library (but not the folder), this means that individual items, stored in folders, that are subject to disposition review will come up for review in the future.

The application of multiple retention labels to folders within the single Document library of the SPO site is already complicated; having to review some of the individual items as part of a disposition review in the future is just adding to the complexity.

My view is that Teams should, as far as possible, ‘contain’ records relating to the same subject with the same single retention period that can be applied to the entire SPO site. Applying individual labels to folders or sub-folders within a single document library is a complex model both to apply and manage into the future.

What do to with empty Teams?

As noted already, retention policies (and labels) do not delete the SPO site, Team or M365 Group, only the content stored in them. Each of these ‘containers’ remain after the content has been destroyed within them.

Accordingly, it is advisable for records and information managers to (a) have access to the details of every SPO site, Team and M365 Group and (b) work closely with IT to determine when these containers can be deleted (and document that activity). Otherwise, the M365 environment will be left with the hollow shells of sites, Teams and Groups.

Further reading

The following Microsoft links provide further details on this subject.

Learn about retention policies and retention labels

Learn about retention for Microsoft Teams

Learn about retention for SharePoint and OneDrive

Create and configure retention policies

Apply retention labels to files in SharePoint or OneDrive

Teams messages about retention policies

Featured image: http://www.pexels.com

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)