How to utilize a private Team and a 'public' SharePoint Site Collection as part of one single M365-based workspace

Using a combination of Atlas, ConneX, and Microsoft technology we are able to build and template a workspace experience that includes both a 'private' MS Team for internal work limited to fewer individuals and also a 'public' SharePoint area which includes everyone in the business as readers via the 'visitors' level of permissions.

This is our best practice advice and recommendation to ensure Microsoft Teams compatibility with Atlas and is a consideration for IT and your Microsoft 365 architecture roadmap.

The main benefits of using this workspace architecture are:

• Bringing Microsoft Teams documents into Search. This is a big and under-utilised consideration. If you want everything to be searchable from your intranet, Teams is not included in this Atlas umbrella until you commence provisioning Teams-associated workspaces through Atlas ConneX. Until this is done, the content and files in ANY out-of-the-box Team will not be surfaced in Atlas, splitting the search experience 'intranet for intranet, Teams for Teams' - leading to confusion and an awkward user experience. Of course the preference is to have all content in Microsoft 365 searchable from one place (Atlas Global Search) where the Atlas taxonomy enables intelligent searching and a positive user experience.
  • • Please note that Teams chat, posts, and comments are not searchable outside of Teams
• Reduce your IT footprint in M365 via the number of workspaces you need. In our experience, for a relevant department, office, sector - whatever it may be - an intranet area for comms is provided in the Atlas services, but there is still an OOTB Microsoft Team remaining in use outside of Atlas. We encounter this scenario regularly. Let's say, for example, both Atlas and MS Teams workspaces here are related to the PMO department, they have 2 workspaces to manage and govern and IT need to manage and govern both as well. If you multiply all of your intranet areas (or departments) by 2, this doubles the estate and also the work needed for good governance. You can reduce this to have both experiences driven through 1 workspace, potentially halving the estate and saving time and effort - especially as we know data and information tends to sprawl over time and eventually becomes very tough to review, migrate, and action, continually pushed to the bottom of the pile for higher priority work. It's clear to see the negative impacts of this over the long term.
• The third benefit, which is not functional but related to Change Management, is that most IT teams state they do not want to formally roll out Microsoft Teams as they aren't ready or aren't prepared, however the use of Teams is inevitable, and whilst not wanting to formalise the use of Teams, out-of-the-box Microsoft Teams workspaces are being spun up and used anyway - so you can try to use the public/private Teams set-up to educate IT on utilising an approach they may be more onboard with as it yields significant advantages to them as the de-facto M365 owners and administrators.

The Solution

Before delving into an explanation of how this public/private Microsoft Teams experience works, it would be better to start by outlining the Microsoft and Atlas combinative architecture which makes this possible, as it leads to a number of factors we leverage and will help your understanding of the solution.

......please note that when we refer to 'public' we do not mean general public, but instead parroting the terminology Microsoft utilises to denote an area that everyone in your firm (i.e. in your M365 tenant) has access to automatically, excluding external users or guests, however we have capabilities to bring them in too......

Teams and M365 permissions architecture

Teams-associated workspaces are a M365-group based workload, meaning they have to have a related M365 Group in Azure which allows management of permissions. The M365 Group does not have a visitor level, as shown below:

You, probably as a standard user without access to Azure, can see this in action - if you go to a Team you are an owner of, click the vertical ellipsis next to the Team name and select 'Manage Team'. You will soon see that there is no option to change someone to or add someone as a visitor. This is because Visitor level does not exist in M365 groups and subsequently do not exist in Microsoft Teams.

Now, we cannot change this behavior, but Atlas Workspaces add a SharePoint Group driven permissions level for Visitor which is housed in SharePoint within the site collection (visualized below) but as noted cannot be used in Teams.

For more detail on managing workspace permissions in Atlas, please visit this article.

This allows visitors, who do not have edit permissions, to visit the SharePoint site collection and workspace homepage and to view and browse content, as well as seeing the content housed in this workspace across the Atlas Platform (driven by the Atlas Taxonomy). However, there is no possible way they can see the Team from here, so they cannot see the conversations, the Teams related files, and can only view content via Atlas.

How we make the solution world-class

This is where we need to start referring to some technical changes we make in the workspace configuration. Please note a lot of Microsoft terminology used. If you need a deeper explanation over a screenshare please let us know by contacting your Atlas representative.

• The OOTB document library for this workspace is the one connected to Microsoft Teams, so we need to leave this in for the Teams users, and on the assumption that this is the 'private' document area not everybody should have access to see, we break permissions against this document library and remove the visitor level, so the SharePoint visitor Group DOES NOT have access to this library and therefore the document being worked on from within the MS Team. Even if they visit SharePoint, this document library is hidden.
• An additional 'public document library' for everyone, supported by Atlas, is created. This will automatically take the 'visitors' level from the workspace permissions inheritance so everybody can see this document library and the content housed here. The document library will be the 'public' facing area to house documents. This document library is also not shown in Teams so there is no confusion for the 'private' members and owners. And as the members/owners of the Team are the only users with edit rights, they are the ones managing the documentation in the 'public document library'. We have even discussed building a publishing process from one document library to another to formalize the 'release' of information and assets from private to 'public'.

Templating

It's important to mention that out-of-the-box 'public' Teams add 'everyone' to the members permissions (as Teams/M365 groups do not have a visitor level). To bypass this functionality from Microsoft, we advise to create the shared public/private workspace as Private, and then to add-on the 'everyone' AD Group permissions into the Visitor level as part of the Atlas ConneX Studio Template Provisioning (which you can read more about here) or as a post-provisioning action. There is a setting in ConneX Studio called 'default visitors' which will ensure the AD Group set here will be applied to all new workspaces provisioned from this public/private template as an automated provisioning action. The AD Group for 'everyone' should be dynamic too - so that users in the tenant are added automatically - saving IT precious time not having to manage permissions to this group, or workspace owners having to 'approve' access requests to this site from those left-out of 'everyone' AD Group. 

The below steps can be followed to set-up this workspace experience.

Steps to create ConneX Source Site (XSS) workspace template

• Provision private XSS source workspace
• Create new Atlas-supported public document library (steps can be found here)-  this will still be inheriting the private permissions
• Break inheritance on the OOTB document library, and remove the visitor group (so only owners and members can access, in-line with Teams access)
• Create template in ConneX Studio
• As part of the template settings ensure an AD Group containing ‘everyone’ in the business is part of the ‘default visitors’ option in ConneX Studio template options
  • Unfortauntely the OOTB SharePoint dynamic group Everyone except external users cannot be used here.
• Provision a private workspace from the template through ConneX
  • The visitor group has already been added to the permissions through the workspace templating options.
• OOTB document library will have broken inheritance from the templating, so no visitor group will be added – this is the private Teams document library. Permissions here are still fixed via owner and member areas in the m365 group even though inheritance is broken on the visitor side. Permissions could even be dynamic if there’s an appropriate field to configure dynamic rules against.
• Visitors will have access to the public document library as it inherits the default visitor setting from connex studio (as inheritance is not broken here, or on any other lists or libraries excluding the OOTB document library)
• Visitors will have read only access to the OneNote app.

Combining dynamic rules into 365 group permissions

This is where we we advise to bring in additional automated governance to permissions management through the use of dynamic rules inside Azure M365 groups. Our vision here is that the dynamic rules automatically add members which meet the criteria of being in that department, office, or role, and adds them into the 'private' Teams permissions in 365 as members. This is a hands off approach with a 1-time set-up, saving IT hundreds of hours of permissions management when onboarding and offboarding staff and fielding permission-related service desk tickets.

You can read more about why we advise to use dynamic rules in Azure 365 groups within Atlas here.

The combination of dynamic rules for members, a dynamic rule for 'everyone' and the ConneX Studio default owners/visitors settings, will enable strong governance which is automated as soon as the workspace is provisioned and dynamic rules set in Azure for each workspace. And for those concerned with breaking permissions in this scenario - as the owners and members are ideally being fed dynamically from M365 - breaking permissions has no knock-on effect EXCEPT removing the visitors group (also dynamic).

Do you like the sound of this scenario and configuration set-up? Do you believe, like we do, that this is the most efficient way to manage your central Microsoft Teams and Intranet areas? Would you like to see it in action? We'd be more than happy to show you - please get in touch with your Atlas representative for a demo.

Considerations which may drive the need for 2x separate workspaces instead of one shared workspace.

• If pages and other content types need to be private. Breaking permissions inheritance on other lists or libraries, such as pages, can be onerous. For example, if the workspace will need 'private' pages only limited to a certain few people, breaking inheritance on individual pages is not recommended.
• Sensitive areas such as 'Senior Management Workspace' or 'Partner Only Portals' where there's a policy-based need to create separation.
• If the Comms Intranet owners need the ability to manage content and the workspace itself, as they will need to be owners or members to manage content and would get access to the Microsoft Team - this may be an overriding factor in needing 2 separate workspaces for separate permissions and content management purposes.