Microsoft Teams Room Architecture: Private and Shared Channels in Teams
Strategies for the use of Teams
During the introduction of Microsoft Teams at our customers, we repeatedly encounter the important questions about the right architecture, structure and, above all, security. In this article, I present the advantages and disadvantages of different scenarios with private and shared channels using practical examples.
Our Practical Example: Collaboration in the Project
A relevant use case of Microsoft Teams - in addition to collaboration in organizational teams such as departments - is the overarching collaboration of various internal and external employees within a project.
To better illustrate our examples, we simplify the parties involved and make the following assumptions:
- Maria (Marketing) and Steve (IT) are internal employees of our company.
- Both are actively involved in working on the Alpha project. Maria is also involved in the Beta project.
- Likewise, external users are active in both projects, Alpha and Beta. Erika (Partner) is to work on project Alpha and Edward (Customer) on project Beta.
- For both projects, there should be an internal exchange of information as well as an external exchange via Microsoft Teams.
- In our second example scenario, we also involve two other internal teams, the Purchasing and Sales departments.
Scenario 1: The Central Marketing Project Team
Alpha and Beta are projects whose functional responsibility lies within the Marketing department. In scenario 1, the marketing team has decided to map all departmental projects within a central "Marketing Projects" team.
- One central team to manage all marketing projects
- One team channel per individual project
This scenario results in the following advantages and disadvantages
If we consider only the aspects of security and relevance, this scenario is obviously not viable and does not at all meet the requirement for a purely internal exchange of content. What about when we consider the use of "private channels"?
The central project team with private channels
In order to guarantee a private area for each individual project as well as the access restrictions of the projects among each other, you should work exclusively with private channels in addition to the "General" channel. For each project you thus create two private channels, one channel for purely internal exchange and another channel for integrating the external users involved in the project.
- One central team to manage all marketing projects
- One internal private channel per individual project
- One external private channel per individual project
This scenario and the use of private channels result in the following advantages and disadvantages
This scenario requires discipline! It would be best if you subjected completed projects and the associated internal and external releases to regular review.
Otherwise, it is difficult to ensure that the parties do not exchange sensitive ones. The security aspect is also the decisive factor here. All project members meet at least in the "general" channel increases the risk of unintentional data loss.
An often asked question is: "Can we hide the General Channel?" Unfortunately, the answer to this is no!
But, it is possible to restrict the permissions to send messages in the "General" channel to the team's owners. You can also configure this for the storage of documents within the channel.
The central project team with shared channels
A fundamental difference between using Private and Shared Channels is the requirement of an existing team membership for Private Channels. Shared channels do not require that users are already members of the underlying team and therefore exclude central access to the "general" channel.
With Shared Channels you create a private area for each individual project and secure the access restrictions between the projects. So you create two shared channels for each project, one channel for pure internal exchange and one to include external users involved in the project.
- One central team to manage all marketing projects
- One internal shared channel per individual project
- One external shared channel per individual project
This scenario and the use of shared channels result in the following advantages and disadvantages
The security challenge is solved with shared channels within this scenario. However, there remains the organizational challenge of regularly reviewing the existing project channels and deciding whether content and approvals are still needed.
Scenario 2: The Dedicated Project Team
A major drawback of our first scenario and its variants is the self-imposed restriction or limitation of flexibility in the use of Team Channels. In the first scenario, we have organizationally determined that a fixed number of channels are required for a project in order to optimally support our use case. However, this loses the freedom and flexibility within a project to decide for itself how the project team wants to structure itself.
Therefore, our second scenario - the classic one - provides for a separate team per project. Within this team you can use open, private and shared channels, but with even more flexibility to support the productivity and acceptance of the employees.
The following view shows a possible example use case.
- One dedicated team per individual project
- One external shared channel
- Additional channels for specific sub-areas (open, private, or shared) such as project management
Shared channels allow a clear distinction between internal and external content. In this case, however, they are much more transparent and comprehensible for existing team members, since the two projects do not mix in the same team (scenario 1).
Furthermore, a separate project team naturally allows you to create additional channels to better structure yourself internally and to work on specific sub-aspects of a project in separate areas.
Let's go one step further and make the assumption that you need to involve other departments in your organization for certain project steps. Colleagues from the Purchasing and Sales departments accompany projects within the planning phase. In order not to permanently entitle them to all project teams and their contents, use shared channels and assign them directly to the teams of the purchasing and sales departments. The current projects thus appear directly as their own shared channel within the respective department teams.
- One dedicated team per individual project
- One external shared channel
- Internal shared channels for integration into other departmental teams
- Additional channels for specific sub-areas (open, private, or shared) such as project management
This scenario and the use of private and shared channels result in the following advantages and disadvantages
Are shared channels the better private channels?
To conclude my article, I would like to address a question you may have asked yourself when comparing private and shared channels.
Are Private Channels now obsolete?
Microsoft links Shared Channels in many presentations with the functionality for simple, cross-organizational exchange of information. However, as our example shows, you can also practically use Shared Channels to structure purely internal collaboration.
From my point of view, shared channels offer many advantages over private channels in the general authorization concept.
Possible exceptions could be security concerns regarding the required business-to-business (B2B) configuration or the assignment of ownership rights of shared channels. The owners of a private channel correspond to those of the underlying team. Shared channels, on the other hand, can be assigned their own owners. There is a risk of loss of transparency here, as well as the need to regularly review the owners of shared channels, just as with a team. Relevant questions here are:
- Are the relevant people still in charge and aware of their responsibilities?
- Are they still part of the company?
- Are there still any owners at all?
In addition, shared channels, which are used for exchanges with external people, have much higher visibility. Since there is no longer a need to change profiles for external users in Microsoft Teams, external content almost feels like internal content. Therefore, it is recommended to give the lifecycle of shared channels the necessary attention in your governance strategy.
Overall, as you have no doubt noticed, this is not a fully comprehensive look at the topic of security in the Microsoft Teams environment. Microsoft 365 offers a variety of additional capabilities that should be incorporated into the architecture of team rooms, for example:
- Consideration of B2B Direct Access configuration, which makes shared channels for cross-organizational sharing possible in the first place.
- Library, folder, and document level permissions
- Use of sensitivity labels and Microsoft Information Protection (MIP)
- Use of Data Loss Prevention (DLP)
- Capabilities for automatic expiration of shares and permissions
Conclusion
With the introduction of shared channels in teams, our first scenario becomes viable, at least as far as sharing content with external users is concerned. Depending on the scope and duration of a project, the first scenario is a possible approach for clear, simple project topics. However, if you want to work on projects in the most standardized and structured way possible, you are more likely to find yourself in the second scenario. However, you should think about governance and the lifecycle of projects in advance.
When it comes to the correct structuring of Microsoft Team Rooms, there is no clear right or wrong in terms of the optimal procedure. However, the best practice for a company is determined by the following factors:
Let's modify our first scenario by these factors and assume that the use case does not involve collaboration on projects, but on strategic focus topics for the company. In this case, the one central shared channel per topic may be perfectly adequate. Then all strategic topics can be consolidated within one team.
Then let our experts advise you free of charge - they are available to you at any time.
Written by