Posted in Governance, Information Management, Microsoft Teams, Products and applications, Records management, SharePoint Online

Why end-users cannot create a Team in MS Teams – a common question

In the last few months, as more and more organisations implement Office 365, I have been asked one of two questions relating to teams:

  • From IT – How do we stop end users creating a new Team in MS Teams
  • From end users – Why can’t I create a new Team?

This post is for end-users, to help understand why the ability to create a new Team in MS Teams has been disabled.

A Team is (much) more than it appears

The simple reason is because of the flow-on effect (see below) and the need for IT to maintain control over the environment, especially the creation of SharePoint sites.

The diagram below, an extract of a larger diagram created by Matt Wade (credit below image), visually shows what happens when a new Team is created (and, for that matter, various other elements).

O365GroupsTeamsetc
Source: @thatmattwade / https://www.jumpto365.com/infographics/everyday-guide-to-office-365-groups

A new Team creates a range of other things (described below) including a SharePoint site. The SharePoint site that is created is visible as the ‘Files’ tab in the Team channel, as you can see below:
image.png

A Team is directly linked with an Office 365 Group

The thing that links all these things together is what are called ‘Office 365 Groups’ (O365 Groups).

O365 Groups only exist in Office 365 and are like a cross between: (a) an Active Directory (AD) Security Group (that controls/grants access to IT resources and systems) and (b) usually small Distribution Lists (a list of people you can email) – but with a lot more functionality.

What do you get with every Office 365 Group?

As can be seen in the diagram above, every O365 Group creates a number of other Office 365 elements. Each Group:

  • Has at least one owner. This is the person who creates the Group, and becomes the linked SharePoint site owner and the owner of the Team. If there is only one owner, then the owner leaves, there is no-one to manage the group, SharePoint site and Team members. This is one good reason why this should be centralised in IT (who usually create all other AD group types).
  • Has members. Members usually belong to a logical and generally smaller (<30 people) business unit or work team, similar to membership of an AD Security Group. Membership of the Group (and Team and SharePoint site) is managed by the Owner.
  • Has a dedicated SharePoint site. The URL of the site is the same as the Group. The members of the Group have default add/edit rights to the SharePoint site. Others, and AD Security Groups, can also be added to the SharePoint site directly (for example, as visitors) but that only gives them access to the site, NOT the Team or the mailbox.
  • Has an email address/mailbox. The mailbox for the Group appears in the Outlook of every member of the group. You can send and receive mails to/from that Group (similar to a Distribution List).
  • Has a Planner and a OneNote notebook.
  • Can be linked to a Team in MS Teams when the Group is created.

What happens if you allow end-users to create Teams?

Conversely, if you create a Team in MS Teams, it creates everything in the previous dot points but with no controls for:

  • Office 365 Group/Team naming. End-users can create a Team with whatever name they want, which then assigns the same name to the Office 365 Group and SharePoint site.
  • Group membership. The person who creates the Team becomes the Owner of the O365 Group and is responsible for managing the Group/Team membership.
  • SharePoint site structure including document library/ies and folders. If the Team uses only the default ‘Documents’ library, it is very likely to create multiple folders, including via File Explorer. The likely outcome is the mess that is often found on network file shares.
  • Everything else that comes with every Team, including Planner and OneNote.

Some organisations have allowed their employee to create new Teams in MS Teams and then had to retrospectively clean up the mess created by random SharePoint sites, poor Team names, confusion between O365 Group members and AD Security Group membership and quite a bit more.

Should we even use Teams?

Yes. Read this post from CMSWire titled ‘The State of Play with MS Teams‘ to see why it is a very useful application to implement. Three points from that article:

  • Chat is the most used function in Teams, making up 70% to 95% of all messages. Chat has 13 times the number of messages than Teams channels. Chat is being used to keep local teams connected in real time.
  • Staff, on average, are members of three teams but are mostly active in one. While most employees have a “favored” team, Teams operating as forums or communities were identified to help employees engage beyond their local team.
  • The most active team has 25 members, all active and connected to each other, interacting at the rate of 365 channel interactions/per day or 14 interactions/per member/per day. This does not include chat.

Note that the most active team has 25 members. This underlines the point made earlier that Office 365 Groups work best when there are fewer than 30 members.

Where is the data stored?

Finally, where is the data stored?

  • One-to-one chats:
    • Chats are stored in a hidden folder in the participant’s email mailboxes.
    • Documents are stored in the OneDrive of participants.
  • Chats in the Team channels
    • Chats are stored in a hidden folder in the Office 365 Group’s mailbox.
    • Documents stored in these channels are stored in the O365 Group’s linked SharePoint site.

Should we use Teams?

Yes, definitely, but understand what is happening ‘under the hood’ if you allow end-users to create new Teams.

Organisations that are new to Office 365 should consider disabling the ability for end-users to create Teams by disabling the ability for end-users to create Office 365 Groups.

Smaller organisations can leave the option available but ensure that there is a guide for the creation of new Teams, including naming conventions and Group/Team membership management.

It will generally be better to centralise the creation of MS Teams in IT as they will normally be responsible for the creation of Active Directory Security Groups and should therefore be responsible for the creation of the more powerful Office 365 Groups.

Posted in Electronic records, Exchange Online, Governance, Information Management, Microsoft Teams, Office 365, Office 365 Groups, Products and applications, Records management, Retention and disposal, SharePoint Online

Setting up SharePoint Online to manage records (as part of Office 365) – Part 1/3

This is the first of three posts that describe the main elements involved in setting up SharePoint Online to manage records.

This post focuses on the recordkeeping related elements in the Office 365 and Compliance admin portals:

  • Office 365 Admin – Licences, Roles and AD Groups (including Office 365 Groups)
  • Compliance Admin – Retention labels and policies (and some more options)

The second post focuses on SharePoint Online Admin centre configuration.

The third and last post focuses on SharePoint site collection provisioning and configuration to manage records

Office 365 admin center

O365AdminPortalUsersRolesGroups

The main elements that impact on the management of records in Office 365 are Users (for licences), Roles and Groups, as can be seen in the screenshot.

Users – licencing and applications

Organisations that acquire Office 365 will generally have the relevant licences required (a) to set up and administer SharePoint Online, and (b) for users to use it (and OneDrive for Business).

This post assumes that organisations will have at least an E3 licence which includes SharePoint for end users, visible as an app when they log on to https://office.com, along with all other applications included in the licence, for example Exchange/Outlook, OneDrive for Business, MS Teams and so on. End users with access to these items will also be able to download and use the equivalent mobile device apps.

Roles

The three key roles that impact on the management of records in SharePoint are as follows:

Global Admin (GA)

Global Admins:

  • Are responsible for managing the entire Office 365 environment. This includes creating new Groups (Security Groups, Distribution Lists and Office 365 Groups).
  • Are responsible for assigning key roles, including the SharePoint Administrator and Compliance Administrator (and other roles).
  • May have responsibility for, and/or the skills and knowledge required to set up and administer SharePoint Online and create new sites for the organisation.
  • May also be able to create and publish retention policies in the Compliance admin portal.

Note – Organisations that outsource the administration of Office 365 should always have at least one GA account to access the tenant if ever required. If they don’t have a log on, they should have or acquire a very good understanding of the access and privileges afforded to the outsourced company. 

SharePoint Administrator (SP Admin)

The SP Admin role will usually be a ‘system’ role that is responsible for managing the SharePoint environment, including OneDrive for Business. As noted above, a GA with the right skills can also manage the SharePoint environment. 

Generally speaking, SharePoint Administrators will focus on the technical and configuration aspects of SharePoint. They are not usually responsible for confirugint SharePoint to manage records, managing records, or creating and publishing retention policies. This role usually falls to either the GA or Compliance Administrator.

Compliance Administrator

The Compliance Admin role is responsible, among other things, for the creation and publishing of retention labels and policies in the Compliance Admin portal. A GA can perform this role (along with all other roles) if required.

Compliance Admins will usually be responsible for disposition reviews linked with retention labels, and be involved in eDiscovery cases.

The Compliance Admin can search and view the audit logs for all activity across Office 365 and can carry out broad content searches with the ability to export the content of those searches. As this role is relatively powerful, it should be limited to key senior individuals in the organisation.

Office 365 and Security Groups

Office 365 Groups are Azure/Exchange objects just like Security Groups and Distribution Lists. Accordingly, there should be controls around their creation, including naming conventions.

As every Office 365 Group has an associated SharePoint site, organisations should consider restricting the ability for end users to create Office 365 Groups, and only allowing Global Admins and members of a Security Group to do this. Neither SharePoint Admins or Compliance Admins would normally create AD Groups.

If the ability to create Office 365 Groups is not restricted, an Office 365 Group will be created with an associated SharePoint site whenever:

  • A new Team is created in MS Teams.
  • A new Group is created from Outlook.
  • A new Yammer Group/Community is created.

External sharing

The ability to share content externally from SharePoint and OneDrive for Business is controlled from the Office 365 Admin portal. This is a global setting that can be disabled by the Global Admins if required.

It is assumed, for the purpose of this post, that that setting is enabled to allow external sharing.

Note that enabling external sharing at the global level does not enable it globally for all SharePoint sites; sites must be individually modified to allow it.

Compliance Admin

The Compliance admin portal can be accessed by the GAs and also the Compliance Admins (and some other roles). It is where retention labels and policies are created (in line with the corporate file plan/BCS) and published, and disposition reviews are undertaken, so records managers need access.

Other options in this section that relate to the management of records include the audit logs, content search and eDiscovery.

Retention policies

Retention policies may be applied to all the key workloads in Office 365 where records are stored:

  • Exchange Online
  • SharePoint Online
  • OneDrive for Business
  • MS Teams
  • Office 365 Groups

Retention labels published as retention policies are visible to and can be applied by end-users. Generally these are more likely to be applied at the document library level rather than to individual records, or in mailboxes or OneDrive for Business.

Retention policies that are not based on labels may be applied to all, or parts of, the four workloads listed above. For example, they may be applied to all, or a sub-set of Exchange mailboxes or OneDrive for Business accounts, or SharePoint sites. Retention policies may also be applied to individual or team chats in MS Teams.

Organisations seeking to use retention policies in Office 365 should understand how these work, have a plan for their implementation, and keep track of what has been applied where.

  • Retention policies for all mailboxes or all ODfB accounts may replace previous on-premise backup options for those workloads. It is unlikely that end-users will (or will want to) apply retention labels published as policies to individual emails or folders in mailboxes or OneDrive.
  • SharePoint sites are likely to have either or a combination of explicit and implicit/invisible retention policies. Implicit, single period retention policies may be more suitable for entire smaller, short-lived SharePoint sites. Explicit retention policies may be more suitable for the diverse range of content on more complex and long-lasting sites. Some sites may be created and populated around the need to keep a particular type of record for a long period of time – for example, employee records.

Audit logs

The Office 365 audit logs are found in the Compliance admin portal. For an E3 licence, the content in the logs is stored for 90 days.

As audit logs are an important element in keeping records, organisations may need to consider ways to retain this content for a longer period.

Note – SharePoint document libraries record the name of anyone who edited a document (and also previous versions), but they don’t record the name of anyone who simply viewed it. SharePoint lists also include audit trails, making it possible to track changes in individual rows of a list.

Content searches and eDiscovery

The Compliance admin portal provides two similar options to search for content across Office 365. Both the Content Search and eDiscovery options provide the ability to establish a ‘case’ that can be run more than once.

The eDiscovery option provides the added ability to put content on Legal Hold. Advanced eDiscovery is available with a higher licence.

Next

Click on the links below to read the next two posts:

  • SharePoint Online Admin centre configuration.
  • SharePoint site collection provisioning and configuration to manage records.
Posted in Compliance, Electronic records, Exchange Online, Information Management, Microsoft Teams, Office 365 Groups, Products and applications, Records management, Retention and disposal, SharePoint Online

Understanding and applying retention policies to content in MS Teams

This post highlights the need to understand how retention works in MS Teams, why it may be related to how long you keep emails (including for backup purposes), and why you need to consider all the elements that make up an Office 365 Group when considering how – and how long – to retain content in MS Teams.

Overview of retention in MS Teams

If you are unfamiliar with how retention works with MS Teams, these two related sites provide very useful detail.

overview_of_security_and_compliance_in_microsoft_teams_image1
Image from the first link above – Security Compliance Overview

The quote below from the second link is relevant to this post:

‘Teams chats are stored in a hidden SubstrateHolds folder in the mailbox of each user in the chat, and Teams channel messages are stored in a hidden SubstratesHolds folder in the group mailbox for a team. Teams uses an Azure-powered chat service that also stores this data, and by default this service stores the data forever. With a Teams retention policy, when you delete data, the data is permanently deleted from both the Exchange mailboxes and the underlying chat service.’

and

‘Teams chats and channel messages aren’t affected by retention policies applied to user or group mailboxes in the Exchange email or Office 365 groups locations. Even though Teams chats and channel messages are stored in Exchange, they’re only affected by retention policies applied to the Teams locations.’

In summary:

  • One-to-one chat in MS Teams is stored in a hidden folder of the mailbox of each user in the chat. Documents shared in those chats are stored in the OneDrive for Business of the person who shared it.
  • Group chat in Team channels is stored in a hidden folder of the mailbox of the associated Office 365 Group – and also in an Azure chat service. Documents are stored in the Office 365 Group’s SharePoint site (other SharePoint site libraries may also be linked in a channel).

Another quote from the same post:

‘In many cases, organizations consider private chat data as more of a liability than channel messages, which are typically more project-related conversations.’

Teams content is kept in mailboxes, retention may be similar

Typically, in the on-premise past, organisations will have backed up their Exchange mailboxes (and possibly also enabled journaling, to capture emails), for disaster recovery, ‘archiving’ and investigations. Unless a decision is made to invest in cloud back-ups, Office 365 retention policies may also be applied to Exchange mailboxes, effectively replacing the need to back them up. Retention policies applied to Exchange mailboxes don’t affect the teams chat folder.

Organisations should probably apply the same retention period to both emails and Teams chats as they do to email mailbox backups now. That is, if mailboxes are typically kept for 7 – 10 years after the person leaves the organisation, then keep the Teams chats for the same period.

Note that, even if a poster deletes an item (if that option is enabled), it will still be retained if there is a retention policy.

Suggestions for retention in MS Teams

As there can be different retention requirements, depending on the subject matter, here are some suggestions for retention:

  • One-to-one chat is like email, you will never know everything that is being said or sent. So a single retention policy that mirrors email would be appropriate.
  • Teams chat is more likely to be about the subject of the Team, which is based on an Office 365 Group, its own mailbox, and has a SharePoint site. In this case, you could consider a retention policy applied to all Office 365 Groups or specific Groups – for example ‘Project Groups’, then ensure that the retention policy or policies cover all aspects of the Office 365 Group (mailbox, team chat, SharePoint).
  • If all the records relating to a particular subject matter (including email, chat and documents) must be retained for 25 years, then you need to understand all the options.

It underscores the need to plan carefully for retention management for all the key workloads in Office 365.

Posted in Governance, Information Management, Microsoft Teams, Office 365, Office 365 Groups, Records management

Creating a Team in MS Teams creates a SharePoint site – and more

In recent weeks a number of organisations with ‘default’ Office 365 configuration settings have told me they are not using SharePoint but they are using MS Teams, and have even created new Teams.

Every new Team in MS Teams creates a linked SharePoint site via the Office 365 Group that is created when the Team is created. If the ability to create Office 365 Groups is not restricted the following is likely to happen:

  • Naming conventions go out the window. New Teams and SharePoint sites will probably be created with random names (eg ‘Andrews Team’, ‘Footy tipping’).
  • The SharePoint environment will ‘go feral’; new sites will not be provisioned according to business requirements.

This post describes what happens when a Team is created and recommends the creation of new Teams by creating an Office 365 Group.

What happens when a Team is created

At the bottom left of the MS Teams client is the option to ‘Join or create a team’. This option will be visible even if the ability to create Teams is not enabled for end users (because the control is on the creation of Office 365 Groups).

TeamCreate01

The dialogue box that opens gives the option to ‘Create Team’.

TeamCreate02

The user now has the choice to build a new team from scratch or create it from an existing Office 365 group or team. For the purposes of this post, we will assume the user chooses the first option.

TeamCreate03

The user is then asked if the team should be private, public or organisation wide. The options will affect the visibility of the Team to others. For the purpose of this post, the new Team is ‘Private’.

The next option is to name the site (‘Footy Tipping’) and give it a description.

TeamCreate05a

The user is then prompted to add members (people who have edit rights) to the new Team. They may add individuals by name, a distribution list, or a security group. If external access is allowed, they may also add people outside the organization as guests. People or groups that are added are made ‘Members’ by default but this may be changed to ‘Owners’.

A key point here is who will have access to the Team if there is a single Owner. What if that person leaves the organisation?

The new Team has been created with a ‘General’ channel. The three dots to the right of the name allow the Owner to modify the members of the Team, add channels, get a link to the Team (to send to others and delete the Team.

TeamCreate06

Along the top of the new Team are three default tab: Posts, Files, Wiki.

The ‘Files’ tab appears (for those who are new to this) to allow documents to be uploaded to the Team, Synced to their File Explorer and so on. This is actually the default Documents library of the SharePoint site that is created when the Office 365 Group is created when the Team is created.

TeamCreate07

What happens in Office 365 Groups

The end user is not likely to care much about what happens anywhere else, they have a new Team and can start chatting.

Meanwhile, in the Groups area of the Office 365 Admin portal, a new Office 365 Group appears. The Global Administrator should be keeping an eye on the creation of new Groups, if they are not controlled, especially if there is a requirement to adhere to naming conventions for all AD Groups (Distribution Lists, Security Groups, and Office 365 Groups).

The Group name has had the space removed in the Group’s email address (and, as we will see, in the SharePoint site). The Global Admin can review and change the Members.

TeamCreate09

The Global Admin may also changed the settings to allow external senders to email the Group and to send copies of Group conversations (in Outlook, see below) and events to Group members. (The Microsoft Teams settings takes the Global Admin to the MS Teams Admin portal).

TeamCreate10

So, an end user has ‘simply’ created a Team, but now there is a new Office 365 Group with a mailbox (not visible but can receive emails) and a SharePoint site.

What happens in Outlook

Every new Office 365 Group has an Exchange mailbox, similar to a shared mailbox, but when a new Team is created from MS Teams, the mailbox is not visible in Outlook. If the Global admin enables the ability to ‘send copies of group conversations and events to group members’, the group members may use that Group’s mailbox address.

The mailbox is visible when a Group is created first, which is a good reason to create a new Team by creating the Office 365 Group first.

Channel chat message are stored in a hidden folder in the Group’s mailbox, where they are subject to any retention policy applied to the chat messages, separate from any retention policy applied to the mailbox.

What happens in SharePoint

As noted already, every new Team gets a SharePoint site because the Team has created an Office 365 Group.

The SharePoint Admin will see the new site in the SharePoint admin portal:

TeamCreate11

The SharePoint Admin may, via the ‘Permissions’ section, view and update the Group Owner/s and also may add additional ‘Admins’. They may make the site a Hub site and decide whether the site can be shared externally or not (the default is not shared externally).

TeamCreate12

The SharePoint admin may also delete the site – but consider that it is not now just a site but a Team and also an Office 365 Group. Some care needs to be taken here – which should be deleted first, and what happens if a retention policy has been applied to the Teams channel or the Office 365 Group?

If the SharePoint admin opens the site they will see a standard ‘modern’ team site with a single default document library. This is the ‘Files’ library that appears as a tab in the Teams General channel.

In the Permissions section of the site, the Site Owners show as the Team owners group, and the Site members (add/edit rights) show as the Team members group. There are no site visitors.

TeamCreate13

If the SharePoint admin goes to Advanced permissions settings and clicks on Site Collection Administrators they will see that only the Footy Tipping Owners are in this section. Organisations should consider adding a Security Group, that includes any records or information managers, in this section. Otherwise, any records will be more difficult to manage and the records managers will need to request access from the SharePoint admin.

TeamCreate14

Two important points that are sometimes missed:

  • Aside from the Global and SharePoint admin, only the Team Owners and Members can access the SharePoint site.
  • The SharePoint site may be shared with another person (or Group) and given Member or Visitor access but this does NOT give them access to the Team channel. They need to be added to the Team Owners or Members to have access to the Team channel.

Summary

Allowing end users to create a Team in MS Teams has a flow-on effect:

  • It creates an Office 365 Group with an associated SharePoint site
  • It creates an Exchange mailbox
  • It will (initially, unless this is changed) make the SharePoint site inaccessible to records managers.
  • It gets complicated if it is decided to delete the Team, SharePoint site, or Office 365 Group.

It is recommended, in organisations rolling out MS Teams to end users, that the ability to create Office 365 Groups is disabled except for Global Admins, and any new Team is created from a new Office 365 Group that includes the option to ‘Add Microsoft Teams to your group’, as shown below:

TeamCreate15

This will result in the following outcomes:

  • Controlled creation of Office 365 Groups, SharePoint sites and Teams, with appropriate naming conventions.
  • A new and visible mailbox for both the Group and the Team.
  • Stop SharePoint from ‘going feral’ and becoming uncontrolled.
  • Establish better governance controls for recordkeeping.

 

 

Posted in Correspondence Management, Flow, Information Management, Microsoft Teams, Office 365 Groups, Products and applications, SharePoint Online, Solutions

Managing correspondence in SharePoint Online including using Teams and Flow

Many (if not most) organisations receive and respond to correspondence in the form of letters or emails. They may also respond to social media messages.

Correspondence may be managed in different ways. For example, some organisations may have a dedicated business correspondence unit while in others individuals or business areas may respond.

This post describes how SharePoint Online with MS Teams and MS Flow could be used to manage letters and emails that require a formal ‘organisational’ response. It does not look at managing responses to social media messages.

Core elements

The management of correspondence that requires a formal response generally involves the following elements:

  • Somewhere to store the incoming correspondence (including scanned paper documents) and responses.
  • A description of the correspondence (naming conventions and/or metadata).
  • Some form of workflow, including emails, used to notify people of actions they must take.
  • Various methods use to report on and track progress, and closure/completion rates.

SharePoint includes all these elements. The requirement for workflow can be met using emails, the built-in workflows, workflows built in SharePoint Designer, or MS Flow. MS Teams provides the opportunity to add additional value to the communication response process by allowing messaging, co-authoring of responses, approval processes, and more.

A model correspondence system

The model correspondence system described below is based on a correspondence management system that I developed for a large public sector organisation a few years ago, but using a different system.

The core elements of the model system are:

  • An Office 365 (O365) Group. The O365 Group has an email address and an associated SharePoint site.
  • The Office 365 Group’s SharePoint site.
  • A Team in MS Teams, connected to the O365 Group.
  • Microsoft Flow.

Office 365 Group

The O365 Group should have a name that reflects its purpose and makes it easy to recognise as it also becomes the email address name.

  • For example ‘GRP_Correspondence’ – the prefix ‘GRP’ is used as it defines it as an O365 Group, as opposed to a Security Group (SG) or Distribution List (DL) created under the same ‘Groups’ section in the O365 Admin portal.

The Members of the Group should be the group of people primarily responsible for managing responses to the correspondence. Other people can be invited to the SharePoint site directly (without having access to the Group’s Team) as Members or Visitors.

SharePoint site

The O365 Group’s SharePoint site has the same name in the URL – GRP_Correspondence.

The SPO site should have at least one document library with an obvious name, for example ‘Correspondence 2019’.

If there is concern about potentially long URL lengths, the library name could be reduced to, say ‘Corro2019’; the display name can still be ‘Correspondence 2019’.

Consideration might also be given to having a ‘drop off library’ in the Group site where anyone can save correspondence that may require a response.

The metadata required in the document library will vary between organisations. The core default metadata (for every new document library) already includes all the following:

  • Title
  • Created (date)
  • Created by
  • Modified (date)
  • Modified by
  • Version
  • Document ID (when enabled as a Site Collection feature, which is recommended)
  • Shared with
  • Shared with details
  • Check In Comment
  • Checked Out To
  • File Size
  • Folder Child Count
  • Item Child Count (shows how many documents in a folder)
  • Label setting
  • Retention label
  • Retention label Applied
  • Sensitivity

Additional metadata may include any of the following:

  • Sender (free text or potentially drop down choice)
  • Response Due date (Date)
  • Urgency (Choice – Routine, Urgent)
  • Description (free text)
  • Reply Status (Choice – Not required, Draft, Approved, Sent, Cancelled)
  • Response Type (Not required, By email, By letter)
  • Approved by (internal Active Directory name)
  • Date Completed (Date) < This date should correspond to the date on any reply.

Once the library has been created, content can be added.

  • Paper correspondence can be scanned and saved to the library. Many MFD (printers) now have the ability to save directly to SharePoint, perhaps to a drop-off library for categorisation and review before being moved to the primary library. The original paper can then be boxed and destroyed after a given period (3 – 6 months).
  • Emails can (and should) be copied from the Group’s inbox to the library (see screenshot below). To do this, sync the library to File Explorer and drag and drop.

EmailtoSyncLibrary

A new folder can be created for each new correspondence, as indicated in the screenshot below:

SPOCorroLibrary.JPG

Naming conventions

Both the correspondence and the folders where it is stored should be named according to naming conventions. Naming conventions can also be used instead of folders, to indicate the connection between the original and the reply. My preference is to use folders to group the original and the reply, and also because they are ubiquitous in the digital workplace.

Suggested naming conventions:

  • Folders: Surname-Subject-Date
  • Emails: EMAIL-Surname-Subject-Date
  • Documents: LETTER-Surname-Subject-Date
  • Replies: REPLY-Surname-Subject-Date-DRAFT or FINAL (the final version may be ‘signed’ and then saved as a PDF)

Always exclude spaces in names, as these will be replaced by ‘%20’ in the URL path.

If one or more standard templates are required for replies:

  • Create the new Site Content Type in the Site Content Types area.
  • Enable the management of content types in the ‘Advanced’ section of the document library settings.
  • Add the new Site CT to the library
  • Add or edit the Word template to be used by clicking on the Content Type in the ‘Content Types’ section, then clicking on ‘Advanced settings’ and ‘upload’. The template can continue to be modified as required directly from this area and ensures consistency in replies.

The new Content Type will appear in the ‘New’ menu in the document library but not in the MS Teams ‘New’ dialogue (see below). This means that standard replies using a template can only (currently) be created via the SharePoint library. Drafts, however, could be created with a standard document template first (same with emails, see below).

StandardReplyCT
SharePoint New options

MS Team

The Team in MS Teams can be connected to the O365 Group (it’s a one to one relationship, you cannot connected multiple O365 Groups with a single MS Team).

The Team can have multiple channels, and the SPO document library can be presented in a channel. For example, the channel named ‘Correspondence 2019’ includes the ‘Correspondence 2019’ document library as a tab, as shown below.

MSTeams_CorroExample.JPG

The use of Teams means allows drafts to be co-authored and chats to take place about the correspondence and other matters.

If the SharePoint site includes an ‘incoming correspondence’ drop off library, the Team could have a channel with that library as a tab. The channel could then be used to review and decide on what to do with the correspondence.

Routing incoming correspondence for a reply

Once the correspondence is saved in a SharePoint document library, a decision must be taken by someone whether a reply is required.

  • If no reply is required, this can be reflected in the metadata (‘No reply required’).
  • If a reply is required, the correspondence must be ‘sent’ or otherwise made available (see below) to someone to draft a reply. This can be a simple or complex process.
    • In some cases, a standard reply may be possible. The SharePoint site should contain at least one library that contains examples of standard replies to certain types of, or common, questions.

Simple routing

The easiest way to ‘send’ someone the correspondence for action is to use the ‘Share’ option on the folder where the incoming correspondence is stored. As the same ‘Share’ option appears in File Explorer when the library is synced, the sharing process can also be managed from File Explorer.

This means that the recipient only has to click on the folder link in the email they receive to see the content of the folder. As they have access to the folder, they can then use the ‘New’ option to create a draft reply, including to an email.

FolderLinkSent.JPG

Once the draft has been finalised, it can also be sent via the ‘Share’ option. Alternatively, an alert on the library will notify anyone who needs to be notified that a change has been made to the library.

Routing using MS Flow

A more complex routing process may be required if the draft requires several steps, for example:

  • Send to someone to create the draft reply.
  • Draft reply gets sent to someone else for approval.
    • If not approved, goes back to the person who created it. (This can loop several times)
    • If approved, a message is sent to the person who needs to finalise it
  • Reply is finalised, metadata is updated, and reply sent.

All SharePoint Online libraries include an in-built Flow workflow ‘Request Sign Off’. When a document is selected and the ‘Request Sign Off’ option is selected the first time, the person must select the option to ‘Create Flow’. The ‘Run Flow’ dialogue then appears, requiring someone to be identified as the Approver and a Message to be included. The approver can be anyone in the organisation, for example the person’s manager.

 

RequestSignOffWho.JPG

The Approver receives an email, allowing them to approve or reject, and add a comment. If rejected, the ‘Sign Off Status’ column in the SharePoint library is updated to ‘Rejected’, and the sender receives a message to advice them that approval was rejected.

RequestSignOffEmail.JPG

If approved, the sender receives an email to notify them, and the ‘Sign off status’ column changes to ‘Approved’.

Once the reply has been approved, it can be finalised and sent to the person who wrote the correspondence. All versions of the draft reply are kept in the same folder, along with the final.

Email replies

Once approved, any email reply could be sent directly to the correspondent from the O365 Group’s mailbox.

Reporting

Metadata from the document library can be exported to Excel, or to business intelligence systems (or PowerBI) for analysis and reporting purposes.

Summing up

Correspondence can be managed in SharePoint, with MS Teams used to provide additional co-authoring and ‘chat’ options for the team, and MS Flow used for more complex approval requirements.