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?
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.126.96.36.1994298459.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:
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.)
Microsoft 365 has become one of the world’s most accessed products for office collaboration. Jeff Teper, the ‘father of SharePoint’ at Microsoft, tweeted on 27 April 2021 that Teams had 145 million daily active users. (As reported in by the team at Office365ITPros.com.) According to the website ‘Microsoft Office Statistics and Facts (2021) | By the Numbers‘ , Microsoft Teams usage grew 40% during the COVID lockdowns.
Although organisations create, capture and store a range of records using the various Microsoft 365 applications, most records are likely to be created or captured in Exchange mailboxes or SharePoint (including OneDrive).
The volume and range of records has, in many respects, overwhelmed traditional standards-based models that required records (including emails) to be copied to a central electronic document and records management system (EDRMS) or identified and then ‘declared’ as records.
Given the reality of the new paradigm, organisations have tried various ways to manage records in Microsoft 365, including by retaining the EDRMS (for high value records), acquiring third-party products that promise to address the ‘gap’ in recordkeeping functionality, or working with the ‘out of the box’ capability.
Whichever method is chose, records managers need to have a very good understanding of where the records are in Microsoft 365 and how they can be managed. In many cases, leaving and managing them where they were created or captured (‘in place’ management), and using new and emerging capability to leverage the power of AI-based tools is likely to be the future state.
With the above in mind, and regardless of which method you follow, the following are ten points that I think are important to consider when managing records in Microsoft 365.
What are your recordkeeping obligations?
It is perhaps the most obvious question but organisations have sometimes rolled out Microsoft 365 without consideration of their obligations for managing records.
Records provide evidence of business activities and accordingly need to be protected to ensure their authenticity, integrity and reliability as evidence. The most common way of achieving this outcome until now has been to ‘lock’ digital records from change. Is this practical in the digital world? How do you lock Teams chats or stop a new thread in an email exchange? Could the same outcome be achieved by recording all changes and ensuring these are retained?
Records are usually subject to minimum retention requirements and understanding what these are is essential. Where there are minimum retention requirements, records cannot be destroyed before a specific period of time based on a particular trigger or event. These requirements are defined in legislation (sometimes based on statutes of limitation) or, for government agencies, in records disposal authorities or schedules (as shown in the example above).
As a starting point, look at these retention requirements and consider how these will be applied to Teams 1:1 chats, or team chats, or emails still in Exchange mailboxes, or OneDrive content. And then extend this to the content stored in Teams/Group-based SharePoint sites and sites not linked with Microsoft 365 Groups.
Consider also what is required to manage the outcome of retention. Do you need to review records due for destruction? Do you need to keep a record of what was destroyed? For all records?
There may be a requirement to categorise or classify records (especially to group them by context and/or for retention purposes where retention is based on classification). How will this outcome be achieved for Teams chats or emails that remain in Exchange mailboxes, or OneDrive content? What other metadata do you need for records?
Your recordkeeping obligations, in particular records retention requirements, should guide the management of records in Microsoft 365.
Where are the records created or captured in Microsoft 365?
Neither Microsoft 365 nor SharePoint is a dedicated recordkeeping system like an EDRMS (see my post ‘SharePoint is not an EDRMS’). Rather, it is an ecosystem of multiple applications that are used to create, capture, store and manage records.
Most records are likely to be stored in either SharePoint (OneDrive is a SharePoint service) or Exchange mailboxes.
A compliance copy of Teams chats are stored in a hidden folder of Exchange mailboxes. Content stored in the ‘Files’ tab is either stored in SharePoint or (for 1:1 chat) in OneDrive.
Of course, there will be some other records – Yammer conversations, tasks and plans, communication sites, calendar entries, forms and even WhiteBoard sessions. But, more than 95% are stored in Exchange mailboxes or SharePoint/OneDrive.
Knowing your recordkeeping obligations and the location of records are the main starting points. In fact, you can map your recordkeeping obligations (especially metadata and retention) to the location of the records.
Do you control the creation of Teams and SharePoint sites or not?
There two, broadly speaking, two approaches to controlling the creation of Teams and SharePoint sites:
Yes, we have controls – There is some kind of control or decision ‘gate’ for the creation of Teams and SharePoint sites.
No, we don’t have controls – End-users can create Teams and SharePoint sites whenever they want. In this case, the points below may not be of much use. You will likely rely on the built-in ‘records management’ capability to manage the records.
If your answer to the question above was ‘No’, then you will probably need third-party products and/or rely heavily on AI-based solutions to manage the records (which is the default Microsoft position).
Map sites and Teams to business functions – don’t mix content
Almost every organisation has a range of business functions. Some of these are common to all or most organisations (e.g., information technology, human resources, financial management, legal, property, etc) while others are ‘core’ (e.g., engineering, manufacturing, research, sales and marketing, etc).
Many organisations are structured around these business functions, and most records retention schedules are based on function (or business function).
If you can map new Teams and SharePoint sites to these functions, this will facilitate the management of records down the track. Mixing content across multiple functions – except where it makes sense to do this, such where there are related but smaller numbers of records in project sites – is going to make it harder to manage the records in the longer term – and more or less the same as letting end-users put whatever they want into a paper box for long-term storage.
A common example where records might be mixed are ‘Corporate Services’ areas that create or capture records across multiple functions, including property, IT, finance and so on. Unless all the records in a Team-based site can be kept for the same period of time, it may be a good idea to separate the records into different sites.
Also keep in mind that some business areas may exist for a long time; having a single (Teams-based) document library that has folders linked to channels may not be the best way to manage records long-term.
The suggestions above don’t take into account Exchange mailboxes, Teams chats or OneDrive accounts because these cannot be mapped to functions.
Naming conventions for sites and teams, and libraries
The main reasons for having naming conventions for SharePoint sites and Teams are:
It is good practice, to avoid acronyms and other less than useful names.
To prevent unnecessarily long names that end up creating very long URLs (e.g., ‘https://tenantname.sharepoint.com/sites/ExecutiveCommittee20202021MeetingsHeldDuringLockdownandrecordedviaMSTeamsSeniorManagersOnly‘.) It is important to know the difference between the URL name and the display name.
Ideally, the original names of Teams and SharePoint sites should be restricted to no more than 14 characters so that Document IDs (that have a 12 character prefix) can be the same as, or very close to, the URL name of the site. For example:
Aside from the default ‘Documents’ library of every Teams-based site, library names should also be subject to naming conventions and restricted to around 20 characters. There are several reasons for this.
The first is how they appear in the left hand navigation of a SharePoint site. There isn’t much point having multiple library names that aren’t easily visible (the two examples below have completely different names after ‘Financial Management’).
The third reason is that it is good practice to have some form of naming conventions.
Ideally, library names should map to the activities that produce the records AND include the year where this is relevant, e.g., ‘Meetings2021’.
There is NO need to repeat words in the tenant or site name – e.g., h**ps://tenantname.sharepoint.com/sites/TenantNameCorporateRecords/TenantNameFinancial%20Management%20%20Accounting%20%20Invoices%202021/Forms/AllItems.aspx
As noted above, this doesn’t apply to the default ‘Documents’ library in Teams-based SharePoint sites (the actual name is ‘Shared%20Documents’).
Metadata and Content Types
For many organisations, the minimum metadata requirements consist of (a) agent (e.g., the person who did something), (b) dates (when they did something) and (c) a unique identifier. That is, who did what and when?
If you need to add more metadata for certain types of records you can really only do this in SharePoint document libraries, including by adding them from the SharePoint Term Store (see below example). It can also be done in Outlook but these metadata terms are not linked with the SharePoint terms.
As for Content Types, do you really need them? SharePoint is made up of multiple Content Types already, including the default ‘Document’ Content Type. It is important to understand how Content Types work in SharePoint before making the assumption that they are required.
In many cases, choice metadata fields can replace the need for Content Types. Custom Content Types may only be needed for specific or high value record types.
Document retention policies and labels
In the first section about recordkeeping obligations, it was noted that most records will be subject to minimum retention requirements. Retention labels and policies are created in the Compliance admin portal of Microsoft 365.
Unfortunately, the current Compliance admin portal provides very little information to show what label or policy was applied where. The only way to do this is to document it yourself. One way to do this is to create a spreadsheet that lists on each row:
The business function and activity from a File Plan or Business Classification Scheme (e.g., Financial Management – Accounting)
Each retention class for that function/activity pair, including the reference number
If that class has been created as a label, what the label name is. If it has been created as a non-label retention policy, what that retention policy name is. (Generally speaking, disposal authority classes don’t refer to Exchange mailboxes, SharePoint sites, MS Teams chats or OneDrive content, so the organisation may need to determine what this minimum retention period should be and how it will manage the retention outcomes).
(Note, the above can be created in the File Plan section of the Records Management part of the Compliance admin portal, E5 licences only. However, it only documents the above information and does not show where the label has been applied.)
Where the label has been applied ‘manually’ – to which SharePoint site/document library, Exchange mailbox or OneDrive account. This point may have multiple location references.
Where the label has been auto-applied through the basic E3 option or, for E5 licences, the document understanding model (DUM) in SharePoint Syntex, or via trainable classifiers.
When the retention will expire.
Retention outcome – If a disposition review (E5 only) exists, the records will be destroyed automatically without any record kept, or ‘do nothing’. See also below.
Remember that retention labels and policies apply to individual items (emails, Teams chat, SharePoint or OneDrive content stored in libraries), not to aggregations (e.g., the entire library or site). The aggregation will continue to exist after the content has been destroyed and no ‘stub’ (a record of what used to exist) will remain.
How will you manage retention outcomes?
Generally speaking, Microsoft 365 retention policies destroy records when they are due for destruction unless they are subject to a label that has the disposition review option enabled or the ‘do nothing’ option has been selected.
Organisations need to understand how they will manage these retention outcomes especially as, in most cases, a review process is required. (See ‘Recordkeeping obligations’ above).
Even when retention label have the disposition review option enabled (E5 only), there are two points that need to be understood:
The ‘disposition review’ interface presents individual records with no context except for the original site URL name. Some additional (default) metadata is now included (from May 2021) but not any added metadata. In most cases, it will be necessary to return to the original library to view the context of the records presented for disposal, and if there are any others.
If records are destroyed through that review process, only basic metadata is retained about what was destroyed.
Organisations that have an obligation to undertake a full review of records due for disposal will likely need to consider establishing workarounds such as exporting the full set of metadata from a document library and then using that to review whether the content of the library can be destroyed. If approval is granted, that decision should be recorded, along with the metadata extract.
Allow end-users to get on with their work
End-users generally don’t have much interest in the management of records beyond the period of time they are important to them. They want to do whatever they want, whenever they want, using the applications they have available to them.
Collaboration no longer consists of email exchanges and document-based records. Creating control gates for the creation of Teams and sites, and insisting on naming conventions for sites and libraries (and folders) may be interpreted negatively.
There needs to be a fine balance between control and freedom and this can impact the creation, capture and management of records. Some of the ways to minimise the impact of recordkeeping requirements include:
Enabling Document IDs on every site.
Creating custom metadata columns on sites or libraries with default values.
Applying non-label ‘safety net’ retention policies to all workloads. Retention policies (along with the Recycle Bin for 90 days) helps with the recovery of accidentally deleted content.
Using various communication methods to highlight useful features including sharing (instead of attaching), the Recycle Bin, versioning in SharePoint/OneDrive, and the ability to have a ‘single source of truth’. These features can be used to ‘soften’ the impact of other recordkeeping obligations in some sites.
Pro-actively monitoring activity across the Microsoft 365 ecosystem, including by monitoring the various dashboards, searches, and audit logs, and responding to events.
Learning more about the Microsoft Graph Explorer and the potential to use AI-based options to manage records.
Use the system for other recordkeeping purposes
The Microsoft 365 environment can be used for other recordkeeping purposes as well. For example:
Managing physical records stored offsite in a SharePoint list.
Keeping a record of records (and SharePoint sites or other systems) that have been destroyed, as well as ongoing destruction review and approval processes.
Publishing policies and procedures (in a SharePoint site, not necessarily a communication site).
Communicating information about managing records (communication site).
Archiving social media content (to Exchange mailboxes).
Searching for content stored in other locations or systems including File Explorer and Line of Business systems (via connectors).
Archiving network file share content, where it can be better protected and then subject to retention and disposal outcomes.
Understanding where records are stored (via dashboards and Power BI reporting).
One of the first things to understand, when managing records in Microsoft 365, is where the records are stored.
Generally speaking, most records will be stored in either (a) Exchange mailboxes (which also store the ‘compliance copies’ of Teams chats) or (b) SharePoint sites (including sites linked with MS Teams). Some emails may be copied to SharePoint and some records may also end up in OneDrive accounts.
Records should provide evidence of business activities and may also be associated with metadata. But while records may be evidence of such activities, compliance requirements may differ. For example:
Some records must be retained permanently and transferred to archival institutions as a public record, while others may be of temporary or transient value.
The evidentiary value of records may depend on the context and content of the record. For example, records detailing a high value contract decision versus the minutes of a low-level team meeting.
With the above differences in mind, the following is a suggested decision tree for the management of records, in a controlled Microsoft 365 environment. This decision tree will not apply in organisations where end-users can create their own Teams and SharePoint sites.
The decision tree below starts with the simple question to the end-user or business area wanting a new Team or SharePoint site:
The answer to this question should help to identify what type of SharePoint site, or Team (with a SharePoint site), is required to manage the records. Note that ALL of the boxes should be considered BEFORE a site (or Team) is created.
Note: the box outline colours represent the four different types of site that are likely to be created.
How will the content be accessed?
It is important to understand how end-users will create, capture, manage and access the content that is stored in SharePoint.
Microsoft have made it clear that they expect ‘most’ end-users will access SharePoint via Teams.
They may also sync the SharePoint document library to File Explorer. If that option is not removed, then it is important to ensure that end-users know how to access the Recycle Bin and version history by going to the Files tab in Teams and clicking on ‘Open in SharePoint’.
If end-users are likely to mostly use the Teams Files tab or the synced version in File Explorer, it may be useful to suggest that they save the SharePoint site as a favourite in their browser.
It is important not to lose site of the Microsoft 365 Group-based option which gives the Group an email account that can be accessed via Outlook (the SharePoint site for the Group can also be accessed directly in Outlook Online).
What type of SharePoint site will be required?
Once the two points above are clear, it is then possible to understand what type of site will need to be created, and how the records will (or will need to) be managed. For example, if Content Types and/or additional metadata is required.
As a general rule, the SharePoint sites linked with Teams are more likely to remain simple, folder-based libraries because, while additional Content Types and metadata can be used, end-users may not react favourably to additional document saving requirements, especially if they access the library via File Explorer.
Organisations with more complex recordkeeping requirements might consider establishing SharePoint sites dedicated for that purpose and accessed via the browser. These may and may not be linked with Microsoft 365 Groups.
The following shows how the new site will be created (if it’s not scripted). Microsoft recently announced that it will add the ‘Created From’ column to the list of active sites in the SharePoint admin portal.
Different site types are likely to have different security controls. Team/Microsoft 365 Group-based sites use the Group Owners and Members to restrict access to the SharePoint site (the Owners and Members Group are added (respectively) to the Owners and Members permission group of the SharePoint sites), whereas a SharePoint site not linked with an M365 Group is more likely to use Security Groups.
Communication sites are likely to have very few Members and ‘Everyone except external users’ added to the Visitors permission group.
Finally, a decision needs to be made about what type of retention policy will be applied to the SharePoint site or the content stored in it. My suggestion is to apply a broad ‘safety net’ retention policy to all SharePoint sites and then use label-based policies as necessary.
As much as possible, the content of sites should ‘map’ to business function and the retention classes in that business function. For example, try to avoid storing legal records with HR records and property records on the same site. Retention management will get complicated.
Label-based policies might have no disposal outcome (‘Do nothing’) but they ensure that the records cannot be destroyed and are labelled accordingly. For example, records that are of permanent value could be labelled with a ‘Do nothing’ retention label in dedicated document libraries where edit rights have been removed, thereby locking them from disposal.
Once the site has been created, it should be provisioned with three key elements shown below.
Records managers should be assigned to a Security Group that is added to the Site Collection Admin area of every SharePoint site. This will allow records managers to manage the content of those sites.
Document IDs should always be enabled and configured (remembering they have a 12 character prefix limit)
The SharePoint Viewers feature should be enabled on every site to provide visibility of who viewed the content.
The decision tree should help to guide the create of new sites and Teams (which have a SharePoint site) for the storage and management of records.
SharePoint Online (SPO) is the primary location to store digital objects and documents in Microsoft 365.
In this sense, it replaces on premise network file shares and drives as a location to store information although a bit ironically, it can also be accessed from File Explorer.
In Microsoft Teams channels, SPO sits behind the scenes via the ‘Files’ tab. This tab presents the content of the folder from the default Documents library that has the same name as the channel (General channel = General folder in the Documents library).
SPO can also be accessed via the SPO app on a mobile device and even directly from Outlook Online.
So, which one is the best way to access your information stored in SPO? The answer is – it depends on what you need to do. You could use all five options.
This post describes five ways to access content stored in SPO, with positives and negatives.
1- For day to day use – synced via File Explorer
Most people use File Explorer to store, organise and access their content, and generally only work from a few folder locations They don’t want to have to open a browser or other application.
The good news is that they can sync SPO document libraries to File Explorer and work directly from there. They can sync a document library from the SPO site or via Teams.
So, for most users, the main change will be a different location to access their content from File Explorer. It looks a bit like the image below. The first words after the folder are the site name, then the hyphen, then the library name. To make it as easy as possible, the library should ideally be the same as the old top level folder on the network file share.
Syncing downloads the metadata about the content that is stored the SPO library. The content is not downloaded to the location device (C: drive usually) until it is opened. From that point on, there is a ‘local’ copy. If that local copy is modified, the changes are synced back to the SPO site.
End users can share directly from File Explorer. The dialogue box is exactly the same as the SPO/Teams option. This makes it much easier to share rather than attach a document to email.
End users can co-author an Office document opened from File Explorer provided they have the most recent version of Office installed. Other end-users may be accessing the same document at the same time via the online versions of Office in Teams or SPO.
The main negatives about the sync option are as follows:
Only basic File Explorer metadata is visible – Name, Date modified, etc. If end-users need to add or see added metadata columns, they will have to access this via the Teams Files tab or the SPO library.
More restrictive, granular-level permissions cannot be set (e.g., on a folder or a document). These have to be set from SPO.
End-users cannot access the version history or Recycle Bin (to restore deleted items)
A folder added at the same level as a Teams channel-mapped folder, will not create a new channel. However, folders created under the Teams channel-mapped folder will be visible.
2 – To collaborate – access via MS Teams
Microsoft have positioned Teams to be an ‘all in one’ collaboration application, allowing end-users to chat, upload and store files, have video calls and more.
In the 1:1 chat area of Teams, the ‘Files’ tab presents documents shared from the OneDrive account of a participant in the chat. OneDrive is, of course, a SharePoint service.
In the Teams area of Teams, the ‘Files’ tab displays, for each channel, a folder with the same name in the Documents library of the Team’s SPO site (every Team has a SPO site). End-users can create, capture and manage content in the channel’s Files tab, as shown in the example below.
There are several positives of accessing SPO via Teams:
Teams includes additional collaboration options, including the ability to chat at the same time as a document is viewed or edited. Content (and folders) can be shared easily.
If this library is synced to File Explorer, any changes made in either location will be automatically updated in the other.
Any metadata columns added to the SPO document library will be visible here.
The SPO site can be accessed directly from a link on the menu bar.
The main negatives of accessing content via the Teams ‘Files’ tab are as follows:
End-users have to open and use an unfamiliar interface (although it has become more common)
The three dot ‘ellipsis’ menu is limited compared with the full SPO version. For example, it does not include versions. See the screenshot below.
The Recycle Bin is not accessible – you have to click on ‘Open in SharePoint’ to access it there.
3 – To see Group emails and files – access via Outlook
Microsoft 365 Groups are a key element in Microsoft 365 and provide a range of functionality that can replace or supplement existing access control and collaboration purposes.
Every Microsoft 365 Group has an Exchange mailbox and a SPO site, and can be linked to a new Team.
If the Microsoft 365 Group is created first, the Exchange mailbox is visible to the Group members in their Outlook.
If the Team is created first, a Microsoft 365 Group with a SPO site and mailbox are created, but the Exchange mailbox is not visible via Outlook. It is there only to store the compliance copies of chats and for calendaring purposes.
Microsoft 365 Groups can be used to replace shared mailboxes or to give business areas the ability to access both email and SPO-stored content from the same location (as well as via File Explorer and Teams).
In the first screenshot below from Outlook Online, you can see a square ‘documents’ icon to the right of the words ‘Send email’. This square icon opens the Group’s SPO documents library (next screenshot). In the installed version of Outlook, clicking this link opens the SPO site in the browser window.
In the screenshot below, you can see the Group’s files from the Documents library, General folder in Outlook Online.
The main positives of accessing SPO content from Outlook Online is that it is relatively easy to move between the Group’s emails and document stored in SPO. End-users can open and documents directly from Outlook, although this (currently) opens Word Online.
The main negative of accessing SPO content from Outlook Online is the limited functionality available from the ellipsis menu, including the inability to see previous versions or access the Recycle Bin. It is also not possible to modify the view (display columns). However, any changes made to the view in either Teams or SPO will be visible in the Outlook Online view.
4 – Anywhere, anytime – via mobile devices
Both Google and Apple provide the SharePoint mobile app, as well as apps for OneDrive, MS Teams, Outlook and Microsoft Office.
This means that mobile users can access their SharePoint content directly from a mobile device. They can also use the SharePoint app to search for any content they have access to.
The main negative with accessing SharePoint from a mobile device is the functionality is very limited. End-users can access and edit the content (if they have the relevant app installed), and can share the documents, but that’s all.
On the other hand, they can access the content anywhere, any time. That makes it very useful.
5 – From the browser – the full SharePoint experience
Of course, the end-user may also access SharePoint from the browser and it is usually a good idea to let them know they can do this for the reasons below.
They can access the browser version in multiple ways:
By clicking on ‘Open in SharePoint’ from the Files tab in Teams.
By saving the site as a favorite in their browser.
By clicking on the files option in a Group’s email inbox area in Outlook installed on the desktop.
The main or common reasons they might want to access the browser version of SharePoint are:
To recover a file they deleted (from any of the other locations, including File Explorer), from the Recycle Bin. This option is available for 93 days after the file was deleted. After that point, unless a retention policy has been applied (in which case the document will be in the Preservation Hold library, accessible to admins), the file is gone forever.
To see who has been working on a file, from the version history.
To see who has viewed a file (when this feature is enabled).
To seek approval for, or see who has approved which version of, a document. This functionality comes with every SharePoint library and list.
To add additional metadata to the content.
To use the full functionality of document sets. Note that these appear as normal folders in a synced document library.
To copy or move documents.
To check out a document.
To search for content and to view content in multiple ways through views.
Access to SharePoint has never been easier, but it is a good idea to let end-users know that they can access their SharePoint content in multiple ways.
Some users may rarely access it via Teams (unless they are interested in collaborating more effectively than attaching documents to emails), and even less so via the full SharePoint browser interface. In summary:
Day to day use where no additional metadata or labels are needed. Sharing (instead of attaching)
For Groups that also use the Group mailbox.
Anywhere, anytime access
For the full set of functionality, including the Recycle Bin, versioning history, viewing, usage information, searching and more.
It is important to let end users know the functionality that they can access in the different areas, especially the version history and Recycle Bin in the browser version of SPO. These alone can be ‘life savers’.
The international standard for records management, ISO 15489-1:2016 (‘Information and documentation – Records management – Part 1: Concepts and Principles’), defines records as ‘information created, received, and maintained as evidence and as an asset by an organization or person, in pursuit of legal obligations or in the transaction of business’.
Among other things, the standard notes that records systems may exist in a variety of forms, not necessary as or in a single or dedicated application. It also underlines the importance of appraisal; that is, the recurrent analysis of business context, business activity, processes and risk for the purpose of determining what records to make and keep and how to manage them over time – especially given the complexity of contemporary recordkeeping.
In terms of risks, the standard states that risk management is required to develop strategies for managing records and the management of records as a risk management strategy in itself.
Unlike traditional electronic document and records management (EDRM) systems that are used to store copies of records created and stored in other applications (‘exception management’), the Microsoft 365 environment is a single system in which records are a sub-set of the entire content (‘exception identification’).
This post discusses how records can be collated, grouped and aggregated in Microsoft 365 to meet requirements for management records. It emphases the point made in the international standard that the risk to records should be understood and minimised.
Records and context
Records are usually created or captured in some form of context – for example a business activity or project. This in turn provides the basis for collating, grouping or aggregating those records according to that context – commonly, a ‘subject’ or ‘topic’.
Records may be a subset of a broader subject (or series). They may be relevant or relate to more than one context or subject.
Digital records that may have no obvious context when they are first created or capture (for example a casual email about an ‘unusual virus outbreak’ in November 2019) may form part of a specific context only when their value is recognised (‘global pandemic’).
Grouping digital records
Grouping records in the digital world has up until now usually involved copying a digital record, created or captured in one system (such as email or a network file share), to a digital ‘file’ in another system such as an electronic document and records management (EDRM) system. The digital ‘file’ in those systems is a virtual representation; the records are actually stored in a file share, linked by metadata in the form of a file number.
The grouping of digital records as exceptions had (and continues to have) several flaws:
It assumed that all types of digital records could be stored in a digital ‘file’ from where they could be faithfully and reliably rendered (and not just stored as zipped versions of exported content from the originating system).
It relied on the willingness of end-users (often after training) and/or a technical third-party system, to copy a record to the system. This ‘exception management’ meant that some records were not copied to the EDRMS.
It was a ‘point in time’ capture. The original digital record remained in the system where it was created or captured, and might also be attached to emails and from there saved to multiple other locations.
There was no way of knowing if all the records in the file were all the records relating to the subject.
Where are the records created or captured in Microsoft 365
Most business records in Microsoft 365 will be created or captured in Outlook/Exchange mailboxes, SharePoint site libraries or MS Teams (which stores chat in Exchange mailboxes and documents in SharePoint or OneDrive). (For the purpose of this post, OneDrive is seen as a personal working space that should not be used to store business records.)
Regardless of whether they are created or captured in Exchange or SharePoint (including via Teams), all of the content – records and non records – created or captured in Microsoft 365 is stored in the Azure substrate. This effectively means that records in Microsoft 365 are a sub-set of all the other content stored in the Azure substrate.
Consequently, the management of records in Microsoft 365 involves exception identification. That is, identifying records and ensuring they are managed appropriately as much as possible where they are captured or created – and placing other controls over all the other content as necessary.
Everything created and stored in Microsoft 365 – including all the very rich metadata associated with every digital record – is subject to the Graph. The Graph identifies relationships and ‘signals’ not only between digital content but between people (agents) and business activities.
The Graph powers Delve and Discovery and the soon-to-be-released Project Cortex, presenting information (they have access to) to end-users that can sometimes be unsettling for people used to working in relative privacy. See below for further discussion about Project Cortex.
Additionally, as all the content in Microsoft 365 is stored in the Azure back-end, most of it can be searched and (where necessary) exported through the Content Search option in the Compliance portal, a capability that supports eDiscovery. This capability means that even when records are not ‘manually’ identified as records, there is a better chance they will be found.
How are records aggregated in Microsoft 365
There are three main ways that records are, or can be, aggregated in Microsoft 365: Exchange mailboxes, SharePoint site libraries, and Microsoft Groups that have a mailbox and a SharePoint site and can be linked to (or created from) a Team in MS Teams.
Exchange aggregates email records by:
Personal mailboxes, accessible only the ‘owner’ (end-user).
Shared mailboxes, accessible to those who have access.
Microsoft 365 Group mailboxes, accessible to the members of the Group (including anyone added to the Group).
Although a mailbox is a form of aggregation, there is no way to relate or link emails stored there with other related records stored in SharePoint unless they are copied to a SharePoint document library, as can be seen in the example below. This is recommended if an organisation wants to keep emails together with other records.
Emails copied to a SharePoint document library are a ‘point in time’ copy; there may be additional replies to the email, forming a thread that isn’t captured.
The alternatives to copying emails to SharePoint are:
Leave all emails in mailboxes and use Content Search to find and export them to SharePoint as a PST.
Creating a Microsoft 365 Group with an associated mailbox and SharePoint site, so that the records are retained in the context of the Group.
In any case, all mailboxes should be subject to a minimum retention period to ensure that any email that might be a record is preserved for that period. Certain mailboxes (for example, senior or key staff members) may be kept for longer periods and then exported for permanent storage.
SharePoint document libraries are logical aggregations for the storage of records, including emails copied from Exchange mailboxes.
Ideally, individual libraries that are used for the storage of records should map to a business activity and/or records retention class; this mapping should be reflected in the library name.
NOTE: Individual document libraries should not be used to store records relating to multiple subjects or mapping to more than one retention class or policy.
Document libraries may be assigned as much metadata as required, and content stored in them can be defined through the use of metadata and/or content types.
Microsoft 365 Groups (including Teams in MS Teams)
Microsoft 365 Groups provide a way to group and manage records, including MS Teams channel chats, in the context of the Group.
Every Group includes a mailbox (visible in Outlook) and a SharePoint site, and can be linked to new Team in MS Teams. Teams channel chats are stored in a hidden folder in the Group mailbox. Any documents and records are stored in the ‘Files’ tab of the channel, which surfaces the default ‘Documents’ library in the connected SharePoint site.
If the creation of Teams is allowed from the MS Teams application, every new Team creates a Microsoft Group (with the same name) and a SharePoint site (with the same name), however the mailbox (with the hidden folder for channel chats) is not visible from Outlook.
(The exception here are private channels; if these are allowed: (a) the chat content is stored in the Exchange mailbox of the each participant, and (b) a new SharePoint site is created for the ‘Files’.
The relationship between the content created by the Group is most obviously visible from the ‘Activity’ web part of the SharePoint site of the Group as can be seen in the screenshot below. This shows (right to left), an original incoming email from Outlook in the Group’s mailbox, the copy saved to the SharePoint document library, and the Word document reply. The specific context of the record (= the ‘file’) – ‘Correspondence 2020’ – is defined by the document library.
What about records in 1:1 Teams chat
As with OneDrive, Teams 1:1 chat should not be used to create or capture records, but may be used as a ‘working’ space.
However, ‘should’ and ‘reality’ can be different things. There are two ways to address this:
Explictly, through communication to end-users. Make it clear that Teams 1:1 chat and OneDrive are NOT to be used to create or capture records. Applying short-term retention policies to this content may assist with reducing (or increasing) this risk.
Implicitly, through monitoring and retention policies. Apply longer-term retention policies to the content and use Content Search/eDiscovery to look for content that may be records. Additionally, review the content of the OneDrive of departed staff and ensure that any records are kept.
Implications for managing records
The implications for collating, grouping and aggregating records in Microsoft 365 are as follows.
SharePoint document libraries will continue to be the primary aggregation for managing corporate records, including emails copied from Outlook.
Organisations should establish an architecture model for SharePoint sites that are used to manage records. The model may include a mix of the following: (a) sites mapped to business functions with libraries mapped to business activities and retention classes, (b) entire sites used to create and capture records relating to a single activity, where the entire site is mapped to a retention class, and (c) MS Groups (and Teams) with an associated SharePoint site, where the Group (mailbox/SharePoint site) is subject to a single retention class (and the Team channel chat also).
More effort, in terms of site/library set up, metadata, access controls, retention and end-of-retention process is likely to be required for the management of high-level, high-risk and permanent records.
Personal mailboxes in Exchange will continue to exist as a form of aggregation, and consideration should be given to having different retention policies for different ‘types’ of mailbox, to ensure that any email that could be a record is not deleted too quickly.
Addendum – Other options that collate, group and aggregate content in Microsoft 365
As noted earlier, all of the content created or captured in Microsoft 365 is stored in the backend Azure substrate. Consequently, it is possible to search across all or part of that content to find related information and, where required, export it to a different location.
The global Content Search is accessed from the Compliance portal and access requires elevated privileges – Global Admin or Compliance Admin.
Searches are created as cases and are based on keywords, conditions (such as ‘Sender’ for emails), and locations – all or specific. When a new content search is created or run, the Global Admins are alerted, providing a form of oversight in addition to audit logs.
While content searches find content is related to the search parameters, and legal holds can then be applied to that content, they do not create any form of aggregation in a recordkeeping sense.
The Graph, Delve, Discovery
Microsoft describe the Graph as being ‘the gateway to data and intelligence in Microsoft 365 [that can be used via the Microsoft Graph API] to access the tremendous amount of data in Microsoft 365, Windows 10, and Enterprise Mobility + Security’ and ‘… build apps that support scenarios spanning across productivity, collaboration, education, people and workplace intelligence, and much more. (Source ‘Overview of Microsoft Graph‘)
The Graph is commonly represented in diagrams similar to the one below.
Most end-users will encounter the Graph through either Delve or the Discover option in both the office.com portal and their OneDrive for Business accounts.
It is not uncommon for end-users to express surprise at the content (that they have access to) that is presented. Commonly this will show documents that a colleague is working on, or connections between people. Disabling Delve does not fix permissions; if a person has access to a document that appears in Delve, they will be able to search for it and find it that way.
Over time, the Graph can also provide other information based on the relationships or ‘signals’ it finds between all the different content in Microsoft 365.
While the Graph can present groups of records that have some relationship to the end-user, it does not aggregate those records or maintain a single consistent view. However, the Graph powers the new Project Cortex that does do something similar.
Project Cortex was announced by Microsoft in April 2019. To quote the announcement, Project Cortex:
Uses advanced AI to deliver insights and expertise in the apps you use every day, to harness collective knowledge and to empower people and teams to learn, upskill and innovate faster.
Uses AI to reason over content across teams and systems, recognizing content types, extracting important information, and automatically organizing content into shared topics like projects, products, processes and customers. Cortex then creates a knowledge network based on relationships among topics, content, and people.
From a recordkeeping aggregation point of view, a core functionality of Project Cortex is its ability to create ‘topic cards’ based on the rich metadata that makes up all the content in Microsoft 365. Again to quote the announcement:
Project Cortex securely collects content that is created and shared every day in Microsoft 365—including files, conversations, recorded meetings and video—and it categorizes the content based on its type, and tags it with extracted metadata.
AI then applies advanced topic mining logic—whether its content contained in Microsoft 365 or connected from external systems—to identify topics and relate content to those topics.
Topics can reflect any knowledge that’s important, including customers, products, projects, policies and procedures. Technically, AI is creating knowledge entities, a new object class, in the Microsoft Graph. The relationships between those topics—those knowledge entities—and the experiences that connect this knowledge with people creates your knowledge network.
Topic cards – or ‘knowledge entities’ – are a form of AI-generated aggregation.
However, topic cards will only present information that an end-user has access to and so the nirvana of presenting emails or Teams 1:1 chats in these cards as a form of aggregation for recordkeeping purposes is not likely to be realised through Project Cortex.
Office 365 is sometimes referred to as an ‘ecosystem’. In theory this means that records could be stored anywhere across that ecosystem.
Unlike the ‘old’ on-premise world of standalone servers for each Microsoft application (Exchange, SharePoint, Skype) – and where specific retention policies could apply (including the Exchange Messaging Records Management MRM policy), the various elements that make up Office 365 are interconnected.
The most obvious example of this interconnectivity is Microsoft Teams which stores chat content in Exchange and provides access to content stored in both SharePoint (primarily the SharePoint site of the linked Office 365 Group) and OneDrive, and has links to other elements such as Planner.
Records continue to be created and kept in the various applications but retention policies are set centrally and can apply to any or all of the content across the ecosystem.
Managing records in Office 365, and applying retention rules to those records, requires an understanding of at least the key parts of the ecosystem – Exchange, Teams, SharePoint and OneDrive and how they interrelate, and from there establishing a plan for the implementation of retention.
What types of records are created in Office 365?
Records are defined as ‘evidence of business activity’ and are often associated with some form of metadata.
Evidence of business activity is an overarching term that can include:
Documents and notebooks (in the sense of text on a page)
Plans, including both project plans and architectural plans and diagrams
Images/photographs and video
Chat and/or messages
Conversations (audio and/or video based)
Social media posts
All digital records contain some form of metadata, usually displayed as ‘Properties’.
Where are the records stored in Office 365?
Most records created organisations using Office 365 are likely to be created or stored in the following parts of the ecosystem:
Exchange/Outlook – for emails and calendars.
SharePoint and OneDrive – for documents and notebooks (in the sense of text on a page), plans, images/photographs and video.
Stream – for audio and video recordings.
MS Teams – for chat and/or messages, conversations (audio and/or video based). Note that 1:1 chats are stored in a hidden folder of the Exchange mailbox of the end-user/s participating in the chat, while Teams channel chat is stored in a hidden folder of the linked Office 365 Group mailbox.
Yammer – for (internal) social media posts.
It is also possible to import and archive certain external content such as Twitter tweets and Facebook content in Office 365.
The diagram below provides a overview of the main Office 365 applications and locations where records are created or stored. Under SharePoint, the term ‘Sites’ refers to all types of SharePoint sites, including those associated with Office 365 Groups. Libraries are shown separately because of the potential to apply a retention policy to a library – see below.
Note also that this diagram does not include network file shares (NFS) as the assumption is made that (a) NFS content will be migrated to SharePoint and the NFS made read only, and (b) all new content that would previously have been stored on the NFS is instead saved either to OneDrive for Business (for ‘personal’ or working documents) or SharePoint only.
Creating a plan to manage records retention across Office 365
In previous posts I have recommended that organisations implementing Office 365 have the following:
A basic architecture design model for SharePoint sites, including SharePoint sites linked with Office 365 Groups (and Teams in MS Teams).
A plan for creating and applying retention policies across the ecosystem.
Because SharePoint is the most likely location for records to be stored (aside from Exchange mailboxes and OneDrive accounts), there should be at least one retention policy for every SharePoint site (or group of sites), as well as policies for specific document libraries if the retention for the content in those libraries may be different from the retention on the overall site.
For example, a ‘Management’ site may contain a range of general content as well as specific content that needs to be retained for longer.
The site can be covered by a single implicit retention policy of (say) 7 years. This policy will delete content in the background, based on date created or data modified.
The document library where specific types of records with longer or different retention requirements are stored may have one or more explicit label-based policies applied to those libraries. This content will be retained while the rest of the site content is deleted via the first policy.
Structure of a retention plan for records in Office 365
A basic plan for creating and applying retention policies might look something like the following:
User mailboxes – one ‘general’ (implicit) retention policy for all mailboxes (say, 7 years after creation) and another more specific retention policy for specific mailboxes that require longer retention.
SharePoint sites – multiple (implicit) retention policies targeting one or more sites.
SharePoint libraries – multiple (explicit) label-based retention policies that are applied manually. These policies will usually a retention policy that is longer than any implicit retention policy as any implicit site policy will prevent the deletion of content before it reaches the end of that retention period.
Office 365 Groups (includes the associated mailbox and SharePoint site) – one ‘general’ (implicit) retention policy. See also below.
Teams channel chat – one ‘general’ (implicit) retention policy. Note that this content is stored in a special folder of the Office 365 Group mailbox.
1:1 chat – one ‘general’ (implicit) retention policy. This content is stored in a special folder of the participant mailboxes.
OneDrive documents – one ‘general’ (implicit) retention policy for all ODfB accounts, plus the configuration of retention after the account is inactive.
At a high level, the retention policy plan might look something like the following – ‘implicit’ policies are shown in yellow, SharePoint document libraries may be subject to ‘explicit’, label-based policies. The ‘+7 years’ for OneDrive relates to inactive accounts, a setting set in the OneDrive Admin portal.
To retain content for a Microsoft 365 group, you need to use the Microsoft 365 groups location. Even though an Microsoft 365 group has an Exchange mailbox, a retention policy that includes the entire Exchange location won’t include content in Microsoft 365 group mailboxes. A retention policy applied to an Microsoft 365 group includes both the group mailbox and site. A retention policy applied to an Microsoft 365 group protects the resources created by an Microsoft 365 group, which would include Microsoft Teams.
The actual plan should contain more detail and included as part of other recordkeeping documentation (perhaps stored on a ‘Records Management’ SharePoint site). The plan should include details about (a) where the policies have been applied and (b) the expected outcomes or actions for the policies, including automatic deletion or disposition review (for document libraries).
Keep in mind that, unless the organisation decides to acquire this option, there is no default backup for content in Office 365 – once a record had been deleted, it is gone forever and there may be no record of this beyond 90 days.
This post describes how Office 365 Groups, with their associated mailbox and SharePoint site, can be useful when there is a business requirement to manage aggregations of email and document-based records for a given function or subject, and why this option should be considered as part of your architecture model for managing records in Office 365 and SharePoint.
What are Office 365 Groups?
Office 365 Groups are a relatively new concept and still remain poorly understood, especially in organisations implementing Office 365.
Because they are not well understood, organisations may implement all the elements of Office 365 without necessarily being aware that:
Every new Group in Outlook, Team in MS Teams, Planner, and Yammer group creates an Office 365 Group with an associated SharePoint site.
End-users can create SharePoint sites from their individual SharePoint portal (the default ‘Team site’ option creates an Office 365 Group)
SharePoint sites will proliferate without any controls over naming or content.
In very simple terms, Office 365 Groups:
Are Azure Active Directory (AD) objects, similar to Security Groups (also known as AD Groups).
Like Security Groups, have members and give those members access to certain (but usually different) IT resources.
Have an associated Exchange mailbox and SharePoint site (that links these two in the same context), and can be linked with a Team in MS Teams. The members of the Group have access to both the mailbox and the SharePoint site. Members of Security Groups may also be added to the SharePoint site but won’t be able to see the mailbox or the Teams chat.
Are similar to Distribution Lists or a shared mailbox in the sense that all the members of the Group can receive emails from the one mailbox.
Include other functionality, including Planner, and can be linked with Yammer groups/communities.
The records management problem that Office 365 Groups can help to resolve
One of the key recordkeeping problems in many organisations (aside from managing digital records generally) is the disconnect between email and other forms of records on the same subject or context.
Emails are created, sent to and from, and stored in mostly inaccessible ‘personal’ accounts (with the odd shared mailbox). Emails may have attachments and the attachment may be the only version of the record. Shared mailboxes partially help this issue but there remains a disconnect between emails and other records.
Other digital records (including saved email attachments) may be stored across network file shares (including ‘personal drives’ and the local C drive) and other locations, including USB drives and unofficial cloud-based systems. Unofficial and unapproved storage locations heighten information security risks both from storing official records in unofficial locations, but also the potential for malicious links.
In the early computer days the only way to keep these records together was to print them and put them on a file, a practice that (sadly) continues to exist. Over the last 20 years, electronic document and records management (EDRM) systems have provided a similar functionality by requiring end-users to copy original documents to a digital version of the file (leaving the originals in place in most cases).
The problem that most organisations face is that records about the same subject or business context, in multiple forms (email, documents) and formats (including chat, messaging and social media) are stored across multiple systems (Outlook, network file shares, personal drives, personal apps on mobile devices).
As a case in point, in 2018 I asked a business unit of so-called ‘mobile workers’ how they kept in touch and ‘collaborated’. Their responses included Facebook Messager, Whatsapp, DropBox (and others) and private emails.
How can Office 365 Groups help recordkeeping?
As noted above, Office 365 Groups have a mailbox, SharePoint site and a Team in MS Teams.
If set up correctly, a single Office 365 Group can provide a single point of context for both email and other digital records including chat, without end-users having to copy or move content anywhere else.
The following are examples (from real life experience) of how Office 365 Groups can be used to keep related records in context.
Organisation often have a central point for the management of all incoming correspondence. In the past, this was likely to be a shared mailbox and correspondence might be uploaded (including after scanning of paper mail) to an EDRMS or other system for routing and responses.
Instead of using a shared mailbox, the Office 365 Group mailbox can be used to receive all emails (where they can remain), and its connected SharePoint site can be used for the storage of digital content including template responses (that could also be stored in Content Types created on the site). A Team in MS Teams may also be created to provide a forum for discussion about the correspondence or other matters – for example, a channel to discuss draft responses.
All the members of the Office 365 Group can access the mailbox, chat and collaborate on content within Team channels, and use the SharePoint site. They can use the ‘share’ option (rather than attaching document to emails) to share drafts with others, or use the ‘out of the box’ ‘Request Sign Off’ flow available in every document library to seek approval.
Additionally, if the Group’s SharePoint site front page has the default ‘Site Activity’ web app displayed, this will show new emails coming in to the Group’s mailbox as shown in the image below. These emails are only accessible to the members of the Group.
Storing records by function/activity/subject
Office 365 Groups could be used to manage the records of a particular business function and activity, particularly those where there is a lot of email.
For example, the functions of ‘Fleet Management’ (or ‘Asset Management’), ‘Property Management’, or even ‘Financial Management’ are all likely to have both email and document type records.
Emails relating to the function can be sent to and managed from the Group’s mailbox by the members of the Group, rather than using a shared mailbox (which is disconnected from the other records).
Documents (including emails from the mailbox, if required) relating to the function can be stored in SharePoint document libraries that map to the activities that are being performed. For example, in a ‘Meetings’ library.
There may be a single retention policy for the entire site or one or more label-based retention policies used on individual libraries, or a combination of both (the longest retention policy will take precedence).
In this way, emails and documents about the same subject can be managed from a single Office 365 Group.
Senior executive management
Office 365 Groups can be used to support and secure communication between senior executives. It provides them with a single restricted access mailbox and SharePoint site, access to both of which are controlled by membership of the Office 365 Group. It also provides them with a Team in MS Teams.
Additional security measures can be applied to more sensitive information including:
More restricted security on some parts of the SharePoint site
Data Loss Prevention policies for very sensitive information
Retention policies to prevent the deletion of content (or capture ‘deleted’ content in a hidden Preservation Hold library).
Stronger monitoring of all activity by end-user.
IT Operations/Service Desk
The IT Service Desk is a common point of contact in most organisations and most service desks will have a shared mailbox to review and triage incoming emails. They will also have a requirement to keep records relating to service support issues.
An Office 365 Group, perhaps named ‘ITServiceDesk’, can be established.
The Group mailbox can be the central point of email contact for the Service Desk (ITServiceDesk@organisation.name).
The associated SharePoint site can be used for the storage of service support documents and other content.
The Group’s Team in MS Teams can have multiple channels to support each application or aspect of IT as required. The Service Desk can use the one-to-one chat and sharing screen capability to resolve service issues.
Office 365 Groups can change the way we work
As noted above, ‘personal’ emails and the use of mostly uncontrolled network file shares (and other storage locations) have been a common way of working for three decades.
Changing these work habits can be hard. However, change can be brought about with minimal impact, provided end-users are assured that the content they need to access will still be accessible and protected, and there is a tangible benefit in doing so in adopting the new ways of working.
These changes should start small, with a focus on mainly small business units that would benefit from being ‘converted’ to an Office 365 Group. The changes that come with an Office 365 Group include:
Replacing shared mailboxes and some (mostly smaller) distribution lists with Office 365 Group mailboxes – still accessed from Outlook.
Replacing network file shares with a File Explorer-based view of the Group’s SharePoint site libraries (via the sync option). This will allow end-users to continue to work in a familiar way. Note that added metadata is not visible from File Explorer and certain metadata options, such as making a column mandatory, will cause the File Explorer view to become read only.
Introducing end-users to MS Teams initially for one-to-one chat, and pointing out how their Group also has a Team where they can chat and access the SharePoint site and other resources.
Demonstrating how the browser-based version of a SharePoint site can show (via the ‘Activity’ web part) emails coming from the Group’s mailbox. And that document libraries have a range of additional document and records management functionality.
Managing retention for all aspects of the Group, ensuring that content is kept (and can be recovered) for as long as required. This action can be hidden from end-users.
The end result should be better management of all records relating to specific subjects or needing to be kept in context.
What about other records stored in email and SharePoint sites?
This post has focused on the benefits of using Office 365 Groups to manage certain types of records within a given context. This model may not be suitable for all types of records. For example:
End-users will probably, for years to come, create, send and manage emails in ‘personal’ email accounts. Email won’t go away as it provides a useful medium for certain types of communication.
End-users will also continue to use their personal space in OneDrive to create and store records that should be stored in SharePoint. It is not easy to monitor this content and so end-user training is essential to ensure that final versions of records are stored in SharePoint.
Security Groups are still valid, especially for groups of 30 or more and can be used in parallel with Office 365 Groups. For example, a small business area may have an Office 365-based SharePoint site and decide to give read only access to the members of the members of a Security Group (with different members), by adding that Security Group to the Site Visitors group. Any member of the Security Group who also happens to be a member of the Office 365 Group will continue to have Member (add/edit) access.
High level business department/divisions may prefer to retain standard SharePoint sites with limited Member access and with Visitor (read only) access controlled via Security Groups (especially those with hundreds of members). An Office 365 Group with more than 30/50 members is still possible, but the benefits compared with using Security Groups is debatable, especially if a Team is linked with the Office 365 Group. Experience using Yammer since 2012 suggests that (a) Teams with more than 30 people can become very quiet and (b) a mailbox with more than 30 members is not useful.
Office 365 Groups:
Should be part of the information architecture model for managing records in Office 365. They are well-suited for lower-level and/or small business units with fewer than 30 members as experience suggests that the more people in the group the less likely everyone will actively participate and contribute.
Can and should, in many instances, replace existing functionality including shared mailboxes and network file shares.
Will allow end-user to continue to work in familiar ways, via Outlook and File Explorer, while offering new options to communicate and collaborate.
Should reduce the volume of ‘personal’ emails and attachments to emails.
May enable the creation, and facilitate the storage and management of records relating to the same business context, including within a function/activity pair.
May never replace the requirement for email or ‘standard’ high level business division or departmental SharePoint sites.
On-premise versions of SharePoint were standalone systems, usually administered by a trained and qualified SharePoint Administrator. Records managers may and may not have had access to or a role in that environment.
Generally, the only other group that would typically have access to SharePoint on-premise were the DBAs who managed the (SQL) database.
SharePoint Online is no longer a standalone system but a core part of the Office 365 ecosystem.
This post describes, for records and information managers, how SharePoint Onlineneeds to be understood in the context of the broader Office 365 administration, and how other admin roles can configure or change settings that can affect SharePoint and OneDrive for Business.
The highest level admin role in Office 365 is the Global Admin (GAs).
To protect the security of Office 365, there should be a very small number of GAs. GAs should have unique cloud-only log ons preferably using multi-factor authentication for added security. End-user accounts should NEVER be assigned the GA role.
GAs can access everything across Office 365, including the content of emails, SharePoint, OneDrive for Business and MS Teams. All activity carried out by GAs (and anyone else) is recorded in the audit logs.
Organisations that outsource the GA role to third-party companies need to be aware of the capability of the GA role and, ideally, also have at least one GA log-on account so they can, among other things, access the tenant and review the audit logs if required.
The key activities that GAs are responsible for, that impact on the management of SharePoint, are as follows.
Assigning licences. Licences (e.g., E3) provide user access to the various applications in Office 365, including Exchange, SharePoint, OneDrive for Business, MS Teams and Office (via http://www.office.com). Generally speaking it is inadvisable to remove individual options from licences. Note that the SharePoint licence gives access to use the application, it is not the admin role (next point).
Assigning roles. Roles provide admin access to the core applications (listed in the previous point) and to a range of activities (for example, Billing, Compliance, Security, User Admin). Office 365 Admin roles should always be cloud only and never assigned to normal end-user accounts. This ensure that the person logs on to perform an admin activity, as opposed to a general end-user activity. It is common (and good) practice for users may be logged on to two ;separate accounts at the same time.
Creating Groups. Groups are Azure/Exchange objects. The three main types of groups are: (a) Security Groups that control access to resources but are not email enabled; (b) Distribution Lists that provide the ability to email multiple people but don’t control access to resources; and (c) Office 365 Groups that a cross between Security Groups and Distribution Lists with much more capability. Office 365 Groups are a core element across Office 365. Every O365 Group has (a) an email mailbox, (b) and a SharePoint site. If the ability to create these types of groups is not controlled, every new Team in MS Teams will create an O365 Group with a SharePoint site (with no controls on naming). Accordingly, there needs to be close cooperation between the GA, the SharePoint admin and/or the records/information manager in relation to the creation of O365 Groups.
Enabling external access for SharePoint. This setting allows the GA to determine whether SharePoint sites and OneDrive for Business, and the content in them, can be shared externally. The setting only makes the option available for SharePoint sites but allows ODfB content to be shared externally. Individual sites must still be enabled (by the SharePoint admin) for external access.
SharePoint/OneDrive for Business Admin
The SharePoint Admin will normally be a qualified SharePoint administrator and may have administered earlier versions of SharePoint. They will also generally be the OneDrive for Business admin (as OneDrive is a SharePoint service).
The SharePoint Online admin role is much less complex in Office 365 than it was in the on-premise version. Records managers who currently manage an EDRMS could potentially become a SharePoint admin, with some training.
Additional training is required only if the organisation wishes to do additional customisation or development work, integration, or has third-party applications.
The SharePoint Admin has a number of roles:
Configuring SharePoint settings in the admin portal. This is usually a one-off activity that may be reviewed from time to time. Configuration settings should be documented.
Creating new SharePoint standard and communication sites – but NOT ‘modern’ team sites that are based on Office 365 Groups, as noted above. These should be created by the GAs who will need to be advised about (a) preferring naming conventions (if any) and (b) Group ownership and membership (which flows through to SharePoint site ownership and membership).
Provisioning new sites. This activity involves changing site collection features and site features to enable things like Document IDs and Document Sets. It also includes assigning the initial Site Collection Admin and Site Owner permissions. It may also include some basic additional options such as a new document library or list.
Assigning access and permissions. Records managers who have responsibility for managing records in SharePoint should be added to the Site Collection Admin section, ideally as part of a Security Group. This ensures that records managers can access all SharePoint sites as required (including the Preservation Hold library on sites where implicit retention policies have been applied) and, if they have the responsibility to do so, create and configure new document libraries to manage records. Both Site Collection Admins and Site Owners can apply explicit (visible) retention policies to document libraries and lists, if used.
Monitoring and managing the SharePoint environment, including resolving issues and working with Site Owners.
Managing the OneDrive for Business admin portal, including setting (a) the size of the ODfB storage and (b) the retention period for ODfB accounts after an end-user leaves.
Providing training to Site Owners, if no other training is provided.
The relationship between the various Office 365 admin elements, SharePoint admin, and the end-user experience is described in the graphic below.
SharePoint admins access the SharePoint admin portal by logging on to http://www.office.com, clicking on the ‘Admin’ option, the then SharePoint admin portal (or directly to that admin portal if they save it as a favorite).
End-users access SharePoint by logging on to http://www.office.com and clicking on the ‘SharePoint’ app, or via the mobile app.
Exchange Online Admins
The primary role of the Exchange Online (EXO) admin is to manage that application. The EXO admin may also be the MS Teams admin – see below.
If the creation of Office 365 Groups is not controlled as noted above, both EXO admins and end users can create a new Office 365 Group from Exchange or Outlook which in turn creates a new SharePoint site.
While emails can be copied from Exchange to SharePoint, Microsoft’s model assumes that the vast majority of emails will remain in end-user mailboxes.
Records managers need to work closely with the EXO admin/s and the Compliance admin/s (see below) to ensure that an appropriate Office 365 retention policy is applied to the content of the mailboxes. There may also be a requirement to remove the default MRM policies.
An Office 365 retention policy may initially appear to conflict with, but can support and replace previous backup strategies deployed to recover mailboxes in case of disaster or for investigation purposes. This means that a single retention policy that keeps all emails for a specific period of time will be applied to all mailboxes.
MS Teams Admins
The role of the MS Teams admin is to configure and manage the MS Teams environment. As noted above, the EXO admin may also be assigned the role of MS Teams admin.
MS Teams includes two main component parts:
Chat. One-to-one chats are stored in a hidden folder in the Exchange mailboxes of individual users. Channel chats are stored in a hidden folder in the mailbox of the linked Office 365 Group. These hidden folders are not subject to a retention policy applied to the rest of the mailbox.
Documents. These are stored in either (a) OneDrive for Business for one-to-one chat, or (b) in the linked SharePoint site for Teams channels.
Records managers should work with the MS Teams admin and the Compliance Admin to identify how retention policies will be applied to both the chat and SharePoint content in MS Teams.
Microsoft separated the Security and Compliance portals in early 2020. Consequently, there may be an admin to manage each component part – one for Security and one for Compliance.
The Compliance admin portal includes a range of actions relating to the management of information. These actions include:
Data classification. This option is still in preview but for E5 licence holders, will allow data to be classified automatically and retention policies applied to that content as an alternative to pre-defined (SharePoint site/library) ‘classification’.
Setting and monitoring alerts.
Viewing reports on various compliance matters, including the status of retention policies.
Creating and monitoring retention labels and policies. This includes retention policies for Exchange mailboxes, SharePoint Online, OneDrive for Business, and MS Teams.
Creating and monitoring data loss prevention policies.
Assigning permissions to individuals.
Managing GDPR data subject requests.
Searching audit logs (90 days of history only).
Searching for content across all of Office 365.
Reviewing disposition for records covered by explicit retention label policies, where this option is enabled
Some or all of these roles may be performed by senior records or information managers.
The Security admin portal provides access to the following actions, some of which may impact on SharePoint (sensitivity labels in particular).
Reviewing security related reports
Creating and managing sensitivity labels and information types (and also creating and publishing retention labels)
Creating a range of security-related policies including for devices, threat protection
SharePoint on-premise was a standalone system that generally did not interact or integrate much with other systems.
SharePoint Online is a core part of the broader Office 365 ecosystem. A range of roles and configuration settings set across that ecosystem have – or can have – a direct impact on SharePoint Online.
Records managers who are involved with SharePoint Online need to understand this crucial difference and either learn or seek to be assigned key roles that impact on the management of records across the Office 365 ecosystem, not just in SharePoint.
There are, broadly speaking, two ‘bookend’ options when it comes to creating new SharePoint Online sites and the document libraries in those sites:
‘Controlled’ model: The creation of new sites is restricted to a small group of individuals with admin rights, who also oversee the creation of document libraries and application of metadata. A combination of controlled and manually applied classification and metadata and retention policies are used to access and manage content over time. Artificial intelligence (AI) tools can also be used to manage content.
‘Chaos/uncontrolled’ model: The creation of new sites, including the creation of document libraries is not restricted. AI tools (including auto-classification) and auto-applied retention policies are used to classify, access and manage content over time. This model assumes that any form of random categorisation applied by end users (e.g., library names, metadata) is mostly ignored by AI tools.
From a traditional information governance and records management (ISO 15498/ISO 16175) point of view, the second ‘chaos’ or uncontrolled model option seems to run counter to conventional wisdom and agreed standards.
From a practical point of view, the first ‘control’ model option seems to run counter to common sense given the volume and range of digital information and the difficulty of classifying or categorising information and records correctly.
Which option is better?
Confusingly, perhaps, the answer may be a combination of both.
Certain types of more formal records, such as those required for corporate compliance, formal policies, staff files, accounting information not stored in a finance system, property information, and/or product information, is almost certainly going to be better off in a controlled SharePoint sites with pre-defined libraries and metadata. These types of documents are more likely to be subject to records retention requirements and almost certainly may be subject to eDiscovery and legal holds.
Other types of less formal records, including ‘working’ documents, chats and conversations may be better off stored in uncontrolled SharePoint sites, including SharePoint sites linked with Office 365 Groups and Teams, and in MS Teams/Outlook. These types of records are less likely to be subject to records retention requirements but may be subject to eDiscovery and legal holds.
Ultimately, the way the organisation needs to implement Office 365, including SharePoint Online and apply retention policies and other options will depend on its need to comply with oversight and legal requirements (including minimum retention periods), and/or its tolerance for risk.
How does this work in Office 365/SharePoint Online?
If both options Organisations need to make a conscious decision to allow both options, and be prepared to manage both.
The key features of Office 365 and SharePoint to allow both options are listed below:
Office 365 retention policies apply to all of Exchange Online, all OneDrive for Business accounts, entire sites (invisible to users) or parts of sites (visible to users).
Some retention policies may be applied based on the auto-classification of records, subject to review.
The creation of SharePoint sites is either controlled (requested and provisioned) or uncontrolled (created by end users) via either (a) ‘Create sites’ in the end-user SharePoint portal or (b) when a new Team is created in MS Teams.
All sites, including Office 365 Group/Team sites are reviewed regularly for activity and inactive sites with no content of value deleted.
All controlled sites are assigned either an invisible retention policy or individual visible retention policies (with disposal review), depending on their content.
All uncontrolled sites are assigned an invisible retention policy. Uncontrolled and inactive sites with content are also made read only.
Features of controlled and uncontrolled SharePoint sites
SharePoint Online is quite different from older versions of the application and those who dismiss it based on previous experience should consider having another look as a lot has changed in the past couple of years.
SharePoint Online allows the creation of sites that contain important content that needs to be controlled of managed as records, as well as sites created and managed entirely by end-users. And, as an added bonus, all the content is stored in the one place, not in multiple locations (network drives, email servers, EDRM system, etc).
The elements that make up both types of sites, as well as ‘informational’ sites, are described below:
Where the organisation’s official records are stored and managed.
Created by SharePoint Administrators.
More formal in nature, containing the official records.
Structure decided by business areas – for example, document libraries using agreed naming conventions.
Use of Content Types and site column or local library metadata to define the content.
Application of Office 365 retention policies to entire sites or individual document libraries, with disposal reviews. Auto-classification is less likely to be required as the content has already been structured as required.
Usually based on end-user created Office 365 Groups or MS Teams.
Where ‘working documents’ are created and managed, with the emphasis on allowing end-users collaborate and communicate easily and effectively – and move content to formal sites when required.
Created by end-users but naming monitored by SharePoint administrators (or using rules).
Informal in nature, used for working documents (effectively replacing personal and network file shares, and other unapproved systems).
A fluid structure for document libraries, driven by end-user requirements (not imposed by others).
Little if any use of Content Types or metadata.
Retention based on Group activity (E5 licences), otherwise based on Office 365 site retention policies and/or auto-classification options.
No disposal reviews – content is deleted after a given period of time.
Communication sites (e.g., ‘intranet’)
Used to publish information to the organisation
Things to watch out for
It is largely true that if you give people an option, someone is bound to try it, sooner or later, especially if it says ‘Create site’, ‘Create team’, or ‘Create group’. Early adopters learn quickly and can just as quickly abandon something that provides no benefit.
In a ‘free for all’ SharePoint environment, where end-users can create new sites, teams or groups (both of the latter have a SharePoint site), the most likely issues will include:
Sites with names that are very similar to ones that already exist, created because the end-user didn’t know another existed (it may not be obvious) or didn’t like the name.
Sites with names that make no sense (including common acronyms) or are just ‘wrong’ or contrary to preferred naming conventions.
Sites used to create and store content that really should be stored in a more formal site or, conversely, doesn’t belong in the organisation’s official information systems (e.g., photos of someone’s wedding).
All of these issues require some general rules about the creation of new sites (or Office 365 Groups or Teams or Yammer Groups), including suggested naming.
Global and SharePoint admins can monitor the environment and fix issues when they arise rather than wielding a big stick.
What’s great about it
You can have the best of both worlds with SharePoint Online.
Keep formal official records in ‘formal’ sites with controlled structures and metadata.
Allow end-users to get on with creating, collaborating, sharing (one copy, not attachments), chatting, on any device.
If your communications and change management are good, end-users will soon learn how much fun it can be to use Teams, or access their content from File Explorer (or both!), without having to having to be trained how to save records. All they need to know is how to use the ‘Move’ option to move the final version of records to a formal site.
The foundation of any compliance program is knowing where all of your data lives and then classifying, labeling, and governing it appropriately.
Organisations have stored and managed records in on-premise versions of SharePoint for many years. Generally speaking, these records had to be managed in – and disposed from – individual site collections.
Office 365 now includes a range of roles, access controls and settings that can be used to manage records across the ecosystem, making it much easier to manage records centrally.
This post describes the suggested user accounts and roles, and the options they provide access to, that can be used by records and information managers to support the management and administration of records in Office 365.
The short version
If you’d like to avoid reading the entire post, the details in summary are:
User Account: A dedicated ‘records manager admin’ Office 365 user account (separate from a normal end-user account), with its own O365 licence (E3 recommended).
Admin role: EITHER the ‘Compliance Admin’ role set in the Office 365/Azure admin portals OR the same role in the Security and Compliance portal OR a custom role group (e.g., ‘Records Management’).
The Compliance Admin role provides additional options that may not be required, hence the suggestion to create a custom role group.
Security Group: An Office 365 Security Group that includes the records management admin account (and others).
The addition of the O365 Security Group to the Site Collection Admin section of every SharePoint site.
Anyone with any kind of admin access or role in Office 365 should have an admin account, in addition to their normal end-user account.
Admin accounts will usually (but not always) require an Office 365 licence.
Office 365 admin accounts should exist only in the cloud and their naming convention should reflect that difference. For example:
Normal AD end user account name: email@example.com
To access the records management features in the Office 365 Security and Compliance portal, records and information managers should have either (a) an appropriate Office 365/Azure admin account (see below) or (b) an ‘admin’ user account. The admin user account name could be something like:
There are around 35 admin roles in Office 365/Azure, in three broad role types:
Global admins. This role has unlimited access and can edit any setting.
Application-based roles such as Dynamics 365 admin, Exchange admin, SharePoint admin, and Teams admin.
Activity-based roles such as Billing admin, Compliance admin, Helpdesk admin, License admin, Security admin, Service admin, and User admin.
There is NO specific Office 365 admin role for ‘records management’ – the closest in terms of access and functionality required is the ‘Compliance Admin’ role.
Office 365 admin roles are assigned to user accounts either (a) from the individual user account or (b) from the ‘Roles’ section in either the Azure Active Directory admin centre or the Office 365 Admin portal.
Except for the Global Admin role which can access anything, all other roles provide access to specific parts of the Office 365 admin portal or to other admin portals. For example:
The SharePoint Admin role provides access to the SharePoint admin portal.
The Exchange admin role provides access to the Exchange admin portal.
The Security Admin and Compliance admin roles provide access to the Security and Compliance admin portal BUT NOTE that these two roles can also be assigned directly in the Security and Compliance portal which only give access to that portal – it does not give the person access to the Office 365 Admin portal. See below for what this role provides access to.
Users who are assigned and logged on with Office 365 admin roles will see the ‘Admin’ icon in the list of Office 365 apps in their office.com apps listing. If they are granted either the ‘Security Admin’ or the ‘Compliance Admin’ role, they will also see the ‘Compliance’ app as shown below.
Security and compliance portal – records management roles
The Security and Compliance centre (https://protection.office.com) includes a number of sections and options, including several that a records manager should probably have access to or manage:
Retention labels (published as retention policies)
(Two other options specific to security/sensitive information)
Data loss prevention
File Plan (if used when creating retention labels)
Events (that can be used to trigger retention policies)
Dispositions (where disposal is managed)
Import (PST files and social media content)
Archive (for Exchange mailboxes)
Retention (create labels and publish them as policies (which replicates the options under ‘Classification’; create retention policies (without the option of a disposition review) for specific SharePoint sites)
Audit logs (up to 90 days)
eDiscovery (cases, and legal holds)
All the options above, and the ones listed below, are accessible to anyone assigned the Office 365 ‘Compliance admin’ role. Not all of these may be relevant or required by records managers – and indeed may provide too much access.
Permissions (to manage roles)
Use to define policies that capture email and 3rd-party communications
Dashboard, Submissions, Review, Policy
Dashboard, Message trace
GDPR Dashboard, Data subject requests
Data Investigations (new)
Dashboard, Manage Schedules, Reports for download,
Four options with information about the Security and Compliance centre.
Because the Office 365 Compliance admin role provides so much access, it may be better to create a custom role group in the Security and Compliance Centre with fewer roles.
The minimum set of roles most likely to be required by a records manager, and the options they provide access to, are Disposition Management and Retention Management which (together) provide access to the options listed below. The ‘RecordsManagement’ role is redundant because it includes the same last three main dot points listed below that are included with the above two roles.
Retention labels (create and publish)
Sensitivity labels (create and publish)
BUT NOT Sensitive info types
File Plan (review)
Dispositions (review and manage)
Retention (create and publish)
BUT NOT Import, Archive, or Dashboard
If records managers need to search and view audit logs and also access the eDiscovery section, it may be better to assign the Compliance Admin role to the records manager (or at least one of them. The portal warns that because the results of these logs could contain sensitive information, the role should be used only by those people with a specific need to know to details.
Organisations will therefore need to consider if records managers should be assigned the Compliance admin role (with more options), or a ‘lesser’ custom role with fewer options created with the Compliance centre directly.
SharePoint-specific roles and access
Security Group to manage SharePoint Site Collections
In addition to the SharePoint Administrator (Office 365 admin) role, every SharePoint site has two key local ‘admin’ role groups:
Site Collection Administrator (SCA)
SCA access allows records managers to:
Access all parts of a SharePoint site (for review purposes, and also to guide Site Owners on best practice records management)
Apply label-based retention policies to specific lists and libraries
Export metadata for document libraries before the library content is disposed of as part of a retention policy
Manage inactive SharePoint sites
Adding the Security Group to the Site Collection Administration section of every SharePoint site
As SCAs can configure settings and access all parts of SharePoint sites, records managers should be in the SCA group on every SharePoint site, but not by name.
Instead, they should be added to a Security Group created in the Office 365 admin portal (under ‘Groups’) or Azure AD. This SG should be added to the SCA group on every site.
The screenshot below shows where and how the Security Group is added to the SCA group in SharePoint:
If the ability to create Office 365 Groups is not controlled, end users will be able to create SharePoint sites either directly from their SharePoint portal or by creating a Team, Plan, or Yammer Group; the O365 Group Owners are added to the SCA group.
Accordingly it may be necessary to retrospectively add the Security Group to SharePoint sites created by end users who create Office 365 or Yammer Groups, or Teams in MS Teams.
Expiry rules for Office 365 Groups and associated content
Organisations that have AD Premium can create expiry rules for Office 365 Groups that can result in the deletion of all aspects of an Office 365 Group, including its SharePoint site, if the Group becomes completely inactive (including no views of any content) within a given period of time.
Generally speaking the action of creating such rules would be restricted to the Azure Admins/Global Admins. In organisations that have AD premium, the records administrators will need to know if an expiry policy is in place OR direct what that policy should be. It is understood that any content in an Office 365 Group’s SharePoint site will not be deleted in this way if the SharePoint site (including via a retention policy applied to the Group) requires the content to be kept for longer.
Auto-application of retention policies
As noted above, records administrators may need to be able to use the ‘auto apply’ option in retention policies based on certain conditions being met. An E3 licence only allows two conditions:
When the content contains certain (machine identifiable) sensitive information (same as the DLP options)
When specific words, phrases or other properties can be identified via a keyword query.
An E5 licence allows additional conditions including based on the auto-classification (machine learning/teaching) of content.