More specifically, if I have a site collection I can create groups while in the root site. I can also create groups while in the various subsites. But from browsing the available groups in the subsites, regardless of whether or not the subsite is inheriting permissions or has unique permissions, I get the feeling that any changes to the groups in the subsite will impact the rest of the collection.

So are all SharePoint groups attached to the site collection? The root site of the collection? or to the individual sites within the collection?


I am asking the question because I need to map a SharePoint group name within a K2 Workflow. For reasons I do not fully understand, the K2 Workflow's SharePoint Group name resolution requires not only the K2 Security Label, but also a relevant site name prior to the group name. When using the K2 SmartObject for listing groups on the site, all the groups come back with names like this:

root site\group 1
root site\group 2
root site\group 3
subsite A\group 1
subsite A\group 2
subsite B\group 2
subsite B\group 3

The K2 SmartObject list shows the groups in many of the collection's sites. However, the groups do not appear in all sites. I created two nested sub-sites under an existing sub-site, then broke inheritance and created a new group in both sites. The new groups show up, prefaced by the site name for the root site and many of the first level sub-sites. However, I did not see them with their own site names. What rules does SharePoint follow when assigning names to groups?

  • 1
    The scope of your question has changed somewhat from the original but I'll try to answer what you're after. Groups definitely live at the site collection level. The "visibility" of a SP group is separate and distinct from its usage in SP. You can make a SP group "visible" in any subsite in a site collection. Ex - Our prod root site has three groups that are shown in quick launch on every subsite. After that, the site-specific groups are also shown. There is no "naming convention" enforced by SP, only valid characters, so you can change the names on a whim. Commented Apr 5, 2013 at 13:26
  • 1
    Also, the "visibility" of a group in quick launch does not affect whether or not it can be used to apply security or otherwise be used in any subsite. You can make a SP group that doesn't show up in any group quick launch, and it still functions. Look at /_layouts/groups.aspx and you'll see all the SP groups for the entire site collection, no matter where you open /_layouts/groups.aspx from. Commented Apr 5, 2013 at 13:31
  • @DrewLanclos - Sorry about the changed scope, but your discussions, answered my original question. I should probably ask a separate question about the K2 BlackPearl group references within K2 Workflows.
    – Zarepheth
    Commented Apr 5, 2013 at 16:23

3 Answers 3


Internally, all users resides inside a special list known as "user information list" at the root site (/) of any SharePoint site collection. This list can be accessed through


Groups are virtual collections of users against this list maintained inside the SharePoint Content Database and have different acls mapped against each securable objects . A securable object can be a site,list or item.

All groups can be only managed from the root site , and they can be used across anywhere in the entire site collection.

Essentially, you can create a group , add users to it , give permissions at a site level however to use them in subsite by breaking inheritance only means mapping them to securable object towards any depth of the subsite or items from the root site. This only makes a reference of the group residing in the top site to its absolute destination.

Edit: Please refer this link for more details on this topic.

  • Groups can be managed from subsites. I'm not sure where you get the idea that they're not. What do you consider "managed"? Commented Apr 4, 2013 at 18:44
  • To be precise - they live at the site collection level but you can still manage them from a subsite without having to open Site Collection Settings or navigate to the root site. Commented Apr 4, 2013 at 18:45
  • By manage, I mean add users, delete/rename the group. Ofcourse you can assign permissions to that group against any item in the subsite , but for the group itself it will take you to the root site always for administrative activity against that group.
    – ArkoD
    Commented Apr 4, 2013 at 18:47
  • "but for the group itself it will take you to the root site always for administrative activity against that group" -> I thought you might mean that, so I just checked in my SP2010 environment, and it does not. Different in SP2013 perhaps? Commented Apr 4, 2013 at 18:48
  • Its the same in 2013. I am sure there is a disconnect here. Lets come to chatroom if that's possible.
    – ArkoD
    Commented Apr 4, 2013 at 18:52

SharePoint groups live at the Site Collection level (SPSite) but are generally exposed in the Group Quick Launch of the site where they are created. The Group Quick Launch can be edited for each site and subsite within a site collection. Site Actions->Site Settings->People and Groups, then click the Groups heading in the lefthand navigation, and then in the main panel, Settings->Edit Group Quick Launch.


So are all SharePoint groups attached to the site collection?

As far as I know they do reside in root site collection, and when you create a sub-site by default it inherits permissions from parent web.

or to the individual sites within the collection?

Only when you break inheritance and assign custom permissions, you can always create custom groups with custom permissions levels too.

Security planning for sites and content (SharePoint Server 2010)

SharePoint groups live or stored in content database where your site collection is residing.

Check this MSDN article about groups out.

You can always break inheritance for sub site and then assign custom permissions to sub site.

  • Groups in a web application? Commented Apr 4, 2013 at 18:39
  • @DrewLanclos I think you didn't read that sentence properly :) Commented Apr 4, 2013 at 18:40
  • Well, the web application isn't really relevant to the discussion at hand, so that's what threw me off. Web applications aren't stored in content databases. Commented Apr 4, 2013 at 18:42
  • I never said web application are stored in content databases, however when we create a new web application we must have to create a root site collection, however root site collection is created by default for SharePoint 80 web application, In short I am referencing to root site collection of a web application, not a web application itself. Commented Apr 4, 2013 at 18:47
  • "content database where your web application or site collection is residing" Commented Apr 4, 2013 at 18:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.