I am looking for how others who currently are using O365/SP online, are governing their Team sites vs. SharePoint sites.
Background: There is a push from IT to have business units use Team sites for how they work.
Concern: I see issues with business units using Team sites due to the chat function in Teams. My understanding is that Team chats remain in the site as long as the site is active.
○ How would we apply record retention around Team chats if they stay in perpetuity?
○ What does this look like when there is a public records request or legal hold?
○ Has anyone else used O365 Teams for their business units, and if so, how do you govern chats?
As a consultant, I obviously can’t answer from the perspective of a user. However, from a consulting perspective, I would say your IT dep’t is wholly oblivious to any considerations of information governance. Does your organization have anyone in a GRC capacity? If so, are they away on leave?
And I say that as an MS partner and someone with close to 20 years of MS-centric business technology experience.
While “collaboration” and “team communication” are obviously very important in how people get work done, the content they create and consume doing it needs to follow a defined lifecycle with checks and balances and cross-departmental flow. If your business is a software development practice with the vast majority of staff working in Agile, then Teams might well be close to all you need. However, for pretty much any other organization, having the robust user experience management, configurable SEARCH, and controllable information architecture/taxonomies that SP can provide is far, far more appropriate. And that’s not to mention the miles deep and miles wide extensibility of SP via the vast ecosystem of 3rd party products that can really turn SP from the ‘base platform’ MS provides to a tool set that actually delivers order of magnitude ROI.
On top of that, from an RM view, Teams is close to being a disaster waiting to happen. The SharePoint site collections that get created are still “invisible” to the primary SPO admin experience, the only product that I’m aware of that really attempts to be able to apply retention is the O365 Labels functionality and you have to upgrade everyone to E5 licenses to be able to access and use the file plan function to make the labels reasonably manageable.
As Lorne points out, it sounds like your IT team is thinking of the internal organisation hierarchy, instead of the business processes. And that isn’t how information should be managed – breaking things down by organisational units leads to information being siloed, instead of being shared across departments and teams. Plus it can easily result in information getting hoarded in huge, ever-growing “buckets” (think of the typical “file share” with ever-expanding folders). So Teams might be the right answer to the wrong question 🙂
Whatever type of site you use, from a classic site to a Team, it should be for information about something and/or for something or someone. So a site per project, per case, per position being recruited for, per annual meeting etc. The “team” i.e. access permissions for the site would then consist of everyone who is working on that information, or needs to access it.
However, a departmental site might be OK of course if it’s for the department, about the department – so their internal information that doesn’t concern anyone else in the organisation. E.g. their internal planning, work management, ideas board, team away day, weekly team (online) meeting etc. Those don’t sound like something that would require strict retention policies, legal holds etc? If so, then Teams might actually work pretty well!
For anything else – i.e. the actual business processes – I would consider either the “ordinary” Sites (of appropriate type – so Team Site, Project Site etc.
Whatever is used, should then be customised – as a minimum, putting in place the relevant metadata and retention policies etc. automatically on site creation.
With regards to the problem of managing conversations data, using Modern Groups instead of Teams might offer a solution. They provide a standard Site together with a conversation facility that uses email conversations instead of the isolated discussion boards that Teams have, and can thus be managed just like any other SharePoint sites and emails.
By the way, the problem that Lorne mentions, with Teams (or Modern Groups) being “invisibile” to the admin seems to be going away now as Microsoft is updating the Office 365 and SharePoint Online admin centers. Also, practically all 3rd party tool vendors have released or announced support for Teams.
Kara, maybe not THE answer but I’ve worked, as a consultant, in companies that treat Teams sites as temporary sites that exist only as long as the project exists. They are then deleted and any content considered as a record is moved to a record center in SP. Also keep in mind that very few items, if any, in a team project site are considered as records that need to be kept. Your company could create a policy around Team sites that says they are only temporary sites and will be deleted at the end of the project.
One of the main reasons organizations move to SharePoint for document management is to leverage collaborative features like Teams. In addition, Teams requires SharePoint to provide document storage. However, to answer your question, we’ve implemented a hybrid approach for one of our clients that still allows us to enforce a standard information architecture.
There are 3 types of sites that we’ve deployed:
● Enterprise Sites (This is just a SharePoint Modern Team site with well defined document libraries and content types and metadata)
● Enterprise Sites with Teams Enabled (The same as #1 but with Teams enabled to provide persistence chat amongst the team)
● Adhoc Collab / Project Sites (Temporary sites provisioned with Teams with little information architecture but with a policy to move documents to a final resting place)
In regards to the hybrid approach, its option #2 stated above. Again I think Teams is a great collaboration feature for your users, but from a governance standpoint there was few things we needed to figure out. For example:
Teams integrates with SharePoint by using a single document library called Shared Documents for storage. If we design and develop a set of document libraries with well defined content types for that business unit, how do we ensure users are uploading documents to those libraries instead of the general Shared Documents library.
Enabling Teams allows users to access documents in either SharePoint or Teams. How do we ensure the experience is the same for both.
How do manage record retention for documents and Teams Chat.
Here is what we’ve done for each:
● We made the general Shared Documents library read only for everyone so it prevents users from uploading documents directly from Teams. If they want to share a document with someone via a Teams channel chat, they can use a link to the document. This forces users to use the well-defined document libraries we’ve designed for them.
● You can create TABs in your Teams channel to provide additional functionality in Teams. We’ve created Tabs for each of their document libraries so that they can be accessible in Teams like they are in SharePoint. We used the “Website” tab to do this instead of the “Document Library” tab since its provides the same experience as SharePoint like switching SharePoint views, etc.
● Since documents are stored in SharePoint, you can use Labels to manage record retention. Team Chats are stored directly in Teams but Labels will support conversations as well – More info here: https://docs.microsoft.com/en-us/office365/securitycompliance/retention-policies#locking-a-retention-policy
We are a wholesale and retail enterprise with over 26,000 people in 1600 physical locations. We also do business with a few dozen online specialty web sites. We follow an approach similar to Cham’s company. Here are some ways we have considered and implemented to insert governance into Teams deployment.
1. The open chats are only kept for 90 days. Channel chats are retained in accordance with the retention set for the Teams site. Microsoft lets you set retention for these separately in the O365 tenant.
2. “Ad Hoc” sites have to be renewed annually or they are deleted. This mostly fits the project use case or someone just playing around trying to learn how Teams works.
3. More formal Teams sites can be established for permanent workgroups. These are approved and “designed” by department or business unit leaders for specific business process needs. Channel chat and document retention for these is set according to the retention schedule established for the document types involved. These typically have a SharePoint document library attached for formal records with formal retention needs.
IMPO, any items held in Teams chat or files will be subject to discovery. The world is probably in for a painful and expensive experience to develop best practices to limit discovery costs and risk.
We are still learning and experimenting, so this not be our final governance scenario.
Ferguson Enterprises, Inc.