Teams is highly focused around teamwork, and along with that it promotes ideas like transparency and openness. So the whole team knows what’s going on, who works on what topic and all work and have access on same files. Chat is central for exchanging ideas, asking for help and sharing information.
It didn’t originally take long when peers and customers started to ask for more privacy. “How I can limit access to certain areas – just like in traditional SharePoint workspaces we have now?”. Usually my answer to that question is another question “Why?” (hey, you have to always start with why) and continuing with following talk to really question the need and reasons to limit this wonderful transparent tool by building walls and doors to hide information.
The need is real
I´ve done several discussions with different people about this topic in both internally in company, with customers and in different public forums.
There are several real scenarios that call in for privacy inside a working group / team
- The team is most often a project with both internals (in-company) and one or more types of externals (customer, other partners in the project, auditors) in it.
- The team is like above, but customer has created it (so we are externals in there). The customer has multiple partners working on the project.
- The team is internal, but includes first-line workers (store or site workers) and also foremen/supervisors/shift-managers or management and their materials. Manager discussions and materials may include feedback about workers (positive or negative) and thus have to keep confidential from first-line members. For example this team could be a store with workers, foremen and store managers/owners.
- The team is internal, but there are some management materials and talk which cannot be seen by others. These talks and materials usually are about strategy and organization development & projects.
The trend is clear: the more often you have externals in teams, the more there is a need to limit some information from others. The need exists and it is a real one and not just something “nice to have” or “we want private channels since this is the way we have been working since 1999”.
What options you have to do it currently?
You can achieve some of the goals even now.
- Create more teams to limit the access. When you have to double your number of teams this is not so appealing.. And you need to remember to manage permissions in two places.
- Create limited document libraries or SharePoint sites and link them into the team – thus limiting access to certain documents. You need to remember to manage permissions in two places.
- Add a group chat (or persistent meeting) to include chat with limited audience. Remember to add new members to the chat (and share history).
- Share files from personal OneDrive along with group chat
- Use a SharePoint Site and Yammer
SharePoint Site and Yammer
One of the options to go outside of Teams and create a private Yammer group (external or internal) and a SharePoint site where the documents are. But before proceeding with this stop.
What happens when you create a Yammer group? Depending on your options, you create a Office 365 Group behind the Yammer. Sure, you can use this to collaborate but if your counterparts don’t really use Yammer that much you end up with a additional step they need to take. Sure, in the near future you can add a Yammer tab to Teams – which makes this a bit closer interaction but I would advice against this. From active Teams users point of view: you are just adding a another team – but with more difficult UI due to Yammer’s different nature.
And especially if you do this for internal use – it will relatively unused due to need to switch a tool.
If you and your external counterparts use Yammer actively – this might be option if you use external group. Go through the needs and requirements before proceeding.
Group chats
If somebody does not belong to the group they need to leave the group by their own action- you can’t kick them out. This can cause trouble if a person needing to leave can’t do it immediately and there are confidential discussions that he can’t see.
Files are also separate from the chat. If you want to do it right you need to share files from a SharePoint document library with links – and this is not user friendly or easy to do unless you do it almost daily. What usually happens, is that files are uploaded directly into the chat. Or you end up sharing your personal OneDrive 4B folder for the group.
Why this is bad? In chat files are always shared from that person’s OneDrive for Business. If that person leaves the company (or the chat) and nobody remembers to move them to another place the files are easily lost or there are multiple copies present. Not ideal.
You can’t add a SharePoint document library as a tab to a group chat.
Use of group chats will work in some cases, as long as you agree on files and other practices. Mostly it works perfectly for small cases and ad hoc needs – not for long term work.
Limited document libraries or separate SharePoint sites
This is just like stepping back to “old times”. You have different permissions to different areas in SharePoint. While generally there isn’t anything wrong with this, it does create some practices that need to be remembered:
- manage permissions manually
- remember to revoke access
Document libraries allow many things like sharing (and control of it), document management (metadata, labels, retention) and of course flows too. Document libraries can be attached as tabs to Teams. This allows these libraries to be included in Teams – and only certain people have access to these documents “management documents”.
What is the downside, is that these documents are not related to any chat and if they are included in the Management channel some people may not realize that the chat is public to rest of the team.
Separate document libraries (with different permissions) work really well if you need to limit access to only documents and make sure people know where to chat if they need privacy.
If you create a new site (group) for these documents then why not add a whole Team instead? While this can be under argument, usually it ends up as a new Team due to simplicity.
More teams
The simplest way is usually to create a new team for the project. This seems like the best alternative, until you end up being in 20 active (and 20-40 inactive/rarely used) projects that have 1-n teams each. If you have a large project with multiple partners you can end up with interesting scenarios.
- One team for the project (where everyone is). Depending on people and project drivers this can be active or just a document store.
- One internal team for the project per party. While this not add more teams to your view, it also means the information won’t be up to date. However, private channels won’t fix this problem anyway. Avoid this if you can.
- One team with your partners without a customer (or from customer’s side one team with each partner without others). So you end up with teams like
- Project team
- Customer – Partner 1
- Customer – Partner 2
- Customer – Partner 3
- Project team customer internal
- This previous could also be
- Project team
- Vendor – Partners (no customer)
- Vendor – Partner 1
- Vendor – Partner 2
- Vendor – Customer
- Project team vendor internal
And so on.. Some teams are reusable. Customer might have several projects going on with the same partner. So you actually have something like this (looking this from customer side only now )
- Project team
- Customer – Partner 1
- General
- Project 1
- Project 2
- Customer – Partner 2
- General
- Project 1
- Project 2
.. and so on. However, then comes up the next project (or a sub project) that is extremely classified. It requires a personal NDA and it contains some of existing partners. So you add even more teams.
On firstline-supervisor-manager example teams could be something like this
- Store 1 team
- Store 1 managers team
- Store 2 team
- Store 2 managers team
- Managers teams in a area 1
- Managers teams in a area 2
This can be easily rethought for simpler approach. The problem is usually the organization who insists that the information must be siloed. This ends up easily to private chat or WhatsApp groups..
- Store 1 team
- Store 2 team
- Store managers team with channels for each store
And we need to keep in mind that a person can work (firstline, supervisor, shift-lead, foreman) in multiple stores, especially if it is a chain of stores.
Will upcoming private teams fix all this?
No they won’t. Some, but not all. You get back to the original question “Why????” and start working from there. What can you do to reduce the number of teams. How much information can be shared with project team members, what if you do require personal NDAs of participants? Can you help cut down that? Can you think a smarter team structure than what I did as a worst case scenario (and what can happen if you are not careful)? Easily.
Once you have private channels in place, you can organize things per team if you want to. So a single project can contain different limited channels for different partners.
However, private channels won’t fix this if you require even more channels to work with your partners. Instead of separate teams you might end up with lots of private channels in one team and it can increase the risk that you choose the wrong channel for the file or for discussion.
Continuing our example you might have
- Project team
- General (everyone)
- (other for everyone channels)
- Internal channel
- Internal management group channel
- Partner 1-channel
- Partner 2-channel
Once you star thinking “why” you can end up with a different result like
- Project team
- General
- (other for everyone channels)
- Internal channel
- If there is a specific and restricted partner part – it’s own channel
All other actions requiring privacy should go to either a Partner team (if you have lots of interactions) or group chats (ad hoc needs now and then)
What private channels do well, is that you can do meetings and attach tabs that are visible only tho members of those private channel members. Teams is way more than a chat and documents.
- access (links) to resources. Especially internal tools like ERP, CRM, etc
- Access to web sites
- Access to shared notes and documents others don’t have access to. Why this is important? If you have lots of these, they kill the tabs idea if you have lots of tabs you can’t access..
What will private channels be?
Only the product team knows this. There has been in speculations for a long time. There are two main options
- Private channels are teams linked to parent team. You can have members that don’t have to be in the parent team. It is just a “shortcut” but the UI is embedded into parent team. No other channels. This model would work with all resources and settings connected to team (Stream, Planner, Exchange, SharePoint, Classification,..) and you should be able to build separate DLP rules to it.
- Private channels are inside the host team, but have a broken permission chain:
- folder has different permissions
- OneNotes and other resources are created in that folder
- What about Stream? Planner? Channel meetings?
- What about the data and it’s classification? DLP rules?
The product team has earlier stated that there won’t be sub-teams / nested teams (just like in first option there). However, the first option could be the only way to handle different problems with private teams.
Go ahead and support and/or comment the User Voice entry to Private Channels. https://microsoftteams.uservoice.com/forums/555103-public/suggestions/16911079-support-for-private-channels
So there are issues the product team needs to conquer and most likely private teems have been way more problematic than first thought.
So what is the Best Practice?
Start with “Why” and tear down the needs and requirements. Go to as simple solution as you can, since it will also help to make Teams with private channels in future more simple.
Simplicity is the best practice. People know how to use the team and they can remember why, how, when and what. The more complex you try, the less it is used the way you want it.
2 thoughts on “Private channels”