SharePoint, Office 365 Groups, and Teams – it is a convergence of worlds! It’s no secret that Microsoft is releasing updates to Office 365 at a rapid rate. Office 365 Groups were announced at Ignite 2015 and since their release the rest of us have been asking, “when do you use a Group vs. a Team Site?”
ThenTeamsjoined the family and the conversation got even more complex, we now had yet another user experience to perform the same collaboration/sharing activities. As a practitioner in the space, I have been having the “what to use when” conversation for the last 3 years.
All of this has now changed. The announcements from the SharePoint Conference in Las Vegas this May introduced previews to upcoming releases that essentially merge experiences and capabilities. While Team Sites, Groups and Teams will continue to have their respective user experiences, the capabilities of a Team Site will be brought almost completely to Teams, Teams will be able to be added to a Group, and Team Sites can be “Groupified.” Confused? Let me break this down.
SharePoint Team Sites to Microsoft Teams
- Teams Files/Libraries will have all the same capabilities, including columns, metadata, Flows, and filtering/sorting as a Team Site. Likewise, Channel File Libraries in a team will correspond to folders in the Team Site Document Library. Access the same content in Teams or through a browser in SharePoint.
- Lists can be added as a tab to a Team Channel.
- SharePoint Pages can be added as a tab to a Team Channel.
- Planner can be added to a SharePoint Team Site.
“Groupify” SharePoint Sites
- Establish a connection to existing Team Sites to an Office 365 Group
- Provides message sharing through the Group membership list
- Allows for management of security and sharing using the Office 365 Group controls/Azure AD
- Add a Team to an Office 365 Group
- Allows for a single group identity through the Office 365 Group
Okay, there is a lot of back and forth between these three workloads. What does this all mean?
My main takeaway is that you no longer have to think about the capabilities you get with one vs. the other when choosing where you want to host your collaboration space. The parity between a Team Site and a Team is such that you can use either or both at the same time and still get the same features. The focus is now on allowing users to work in the user interface they prefer. Does this mean we should leave it all intentionally open and allow users to choose? Maybe. I still believe training, comfort level, and power users play an influential part to your plan to managing Teams/Channels and Team Sites.
This could mean that all Team Sites and Teams are Groups moving forward. This can be a foundational element of governance that you define to ensure a consistently managed experience. This then brings us to our next question:
Why would I want to “Groupify” a Team Site?
The fundamental difference between a Group and a Team Site is the security permissions managing it. A Group creates the group ownership, membership, and guests in Azure AD whereas Team Site permissions are managed in the site collection and site through SharePoint Online. Why does this matter? Managing permissions in Azure AD will enable Office 365 Admins to manage permissions in a central location, and also deploy changes or policy as needed. Managing permissions in SharePoint Online is adhoc and will be done at the site collection or site level. Ultimately, you’ll probably still have sites whose permissions are managed inSharePoint Onlineand Azure AD, and this may cause a bit of confusion for Admins.
What should I know before I continue to pursue “Groupifying” Team Sites?
There are some fundamental differences that you should be aware of before you consider “Groupifying” Team Sites. First, you can establish the connection from existing Team Sites to an Office 365 Group through a PowerShell script.
- Assess Team Site readiness with the modernization scanner in Github – Sharepoint.modernization
- The script will assess which sites are ready for group connection and will address warnings and blockers.
- You can also learn more about the site pages used in your tenant.
- Groups cannot have nested security groups (if a site has a security group you will have to add individual members one by one to the site to give them access).
- Public vs. private – The script will detect if a site is shared with everyone in your organization or if it is private. Office 365 Groups are either public or private, then further security in owners, members, and guests can be applied. The connection will convert the site to a public group by default.
- Subsites in the site collection cannot be “Groupified.” Sites will need to be unnested. This follows the different membership constructs between SharePoint and Azure AD Groups and the lack of security group nesting.
Groupifying is very different from the way SharePoint Admins had previously managed security, access, site maps, and information architecture. Does this change the way you should think about information architecture? Absolutely. While Microsoft is making its direction a little more clear, the lines are still not finely drawn and the admin experience will continue to be disjointed for some time. It also warrants conversations about how you plan out your Office 365 and SharePoint Online experience for end users and also for administration.
While this convergence may be altering how we administer these tools, the conversation has shifted away from when to use which workload. It shifts the focus from being a pro/con analysis about the tools and more about end user preference. I think this move retains the true essence of SharePoint and the reason why so many of us have been using this platform for such a long time. We were originally drawn in by the power of lists, libraries, site extensibility and integration with Office. Now we get these same features any way we want it.
Have specific questions on how to roll out Teams in your organization?
Speak with a consultant online today, or give us a call at240.348.4208
