Forum Discussion
ROLLING OUT: SharePoint Online team sites + Office 365 Groups & Pages
Hi, This sounds great! But I'd love to get some steer from Microsoft about what they see the purposes of Team Sites vs Groups are. It seems like they are getting closer and closer together in functionality. Some examples of when you see each being used would be great.
First, I'd say the main differrence in how to think about it is that it is not Groups vs Team, it's Office 365 + the full power of a SharePoint Online team site. Groups is the list of members, and SharePoint is where they get work done - right alongside the ability for the group to have a shared inbox and calendar, a team notebook, group Skype ("Meet now"), etc. SharePoint Online team sites have always contributed the default document library for the group, "Files." And with this update, we more fully expose all SharePoint capabilities within the same site collection.
LincolnDeMarisMicrosoft
The purpose of groups is for getting work done together. SharePoint is one of the tools the group has. Outlook for mails, calendar for calendar, planner for tasks, SharePoint for files, pages, lists, apps, Flows, PowerApps, etc.
- I'm sure that by the end of the Ignite conference at the end of the month it will be much clearer.
Mark-Kashman, I am also a little confused by the path this has been taking.
See, earlier we had SharePoint Team Sites which would provision a shared notebook, team calendar, shared documents library, and a site mailbox automatically. Add in people with appropriate permissions and it became a group.
Now, the route is to create an O365 Group first, which would then provision a shared notebook, team calendar, shared documents library, group mailbox, and very soon a team site, automatically.
What really is the difference? I mean apart from an entry-point in Outlook.
First main diff to consider is that Office 365 Groups creates an object in Azure Active Directory (AAD), where it can then support auth across apps more easily. Next I'd say we are using the best of all apps. For example: Calendaring and mail are best offered via Exchange Online - and Office 365 Groups uses EXO to provide the group with a shared cal and inbox; and improvement over SharePoint calendars and site mailboxes. We do use SharePoint Online for the Group's notebook, document library (Files) and now the site itself for pages, lists, subsites and biz apps. And beyond these examples, Groups brings access to Planner, Power BI, Skype for Business, etc.. with much easier integration and permisisons management. Initial thoughts. Hope it helps. - Mark.
- Thank you so much @MarkKashan for the clarification. You've explained it so better, that I see that this is a much improved way of connecting the components together as compared to the earlier team-sites with site-mailbox and cal etc.
That reminds me of asking another question - Am I correct in my understanding that when a group is created, the default documents library is located in a separate site-collection (and that host web will contain only this document library) and the new team-site will be provisioned as a separate sub-site inside a pre-designated but different site-collection? So, in effect there will be two SharePoint sites involved with one group? Or am I completely wrong and that there is only one site-collection which holds all the SharePoint components together for a group?
I'd have previously described Team Sites as a 'container', designed to bring everything your team needs together in one place. This used to be a collection of standard apps or experiences built within SharePoint. I think Groups are assuming this role, but are instead acting as a container for Microsoft products built outside of SharePoint. In the process of this happening, Team Sites have effectively been demoted from a container to one of several products that sit within the new container, Groups.
Leon Summerfield-Kehoe - Me too. Site Collection is the big container. It contains SP groups, and libraries\galleries for site collection wide assets (e.g. list templates etc.). If you want a column to be available everywhere in the site collection, then you create it in the top level site of the site collection. The top level site also contains the Site Collection admin settings. A site collection admin is all powerful in the context of a site collection. I know this world very well.
We have groups disabled in our tenant and therefore planner. We want to enable them but the architecture isn't mature enough to work in a large tenant. For example we have been blocked over things like the inability to manage the namespace of groups and planner. I thought we were close, but one uses Azure AD to manage namespace and the other uses graph so we stuck again. As a result I will be late to the groups bandwagon. Where do they fit in to my world view? The old world view was akin to nesting dolls. Put your sites in site collections, put your lists and libs in sites and put your content in lists and libs. Choose what is inherited and what is unique. Use groups to manage permissions and try to organize things so you don't have to assign permissions at the item level, but you can if you really need to.
Honestly I am a little anxious about all this. I have been working some very simple records management artifacts (policies and content types) to promote in our organization. I want to promote the use Managed Metadata. One of SharePoints strengths was that departments could create structured solutions and automate processes. Is all that going away? What if I recommend using SharePoint Online as a repository for files that have a retention schedule that lasts a few years, am I going to live to regret it? I hear nothing of these subjects, there are no improvements in the pipeline. I assure people that Microsoft has our back, that they won't pull the rug out from under us, but my confidence is waning.
Can a guy get a little reassurance?
