By: Arjun Chakraborty

Introduction:

Often times, I have to remind myself, is it appropriate to use web.SiteGroups, or web.Groups?  The same can be asked about web.SiteUsers vs. web.Users, but the convention is pretty similar.  Ultimately, I found out the difference:  Web.SiteGroups contains all the groups within the whole site collection (SPSite), regardless of the site (SPWeb) itself.  It almost makes more sense as a property of SPSite.  Web.Groups, on the other hand, only contains the groups which have some level of permission in that specific site (SPWeb).  Web.Groups can clearly be different from one subsite to another, unless role inheritance is always observed.

We should note, groups are a ‘property’ of the site collection, not the specific sites.  It’s not that way in code, but any group created anywhere is always available throughout the site collection.  So, a group created from the subsite’s site settings page will be available (for people pickers, and role assignments) within the super site.

To Demonstrate the difference, I created a site collection (called Root), and a subsite underneath it (called Sub Site).  When creating the subsite, I noted to not inherit permissions, and to create 3 new groups for the subsite.  In each site, I ran a workflow that would iterate through web.Groups and web.SiteGroups.  Before each iteration, the list’s size is noted.  Afterwards, In each iteration, the group names are also noted.

Result:

Here are all the groups within the site collection:

These groups were automatically generated by SharePoint.  When creating the subsite, if permissions were inherited, the 3 sub site groups would not have been created.

Here are the permissions for Root…

…and for Sub Site…

Once the workflows were run on the two sites, here were the results:

Root:
(Remember, Root site was set to give permission to all 6 groups, while Sub Site was not.)

Sub Site:

Here is the code block within the workflow which generated these Notes:

(Note, not putting any output in the catch block is generally a BAD practice.  It’s called exception swallowing.  It will give the illusion that everything is alright, when something might be going awry.  Sometimes, you will do this if you really don’t care what the result of that try was, but be sure to use with caution.)

Bonus:

You might notice that I also included web.AssociatedGroups.  This one is tricky, and I don’t really see a lot of use for it.  After playing around with it, I realized, if you create a group from the set permissions page for any site (SPWeb), that group becomes associated with that site.  This remains true, EVEN if that group no longer has ANY permission on the associated site (SPWeb).  Iterating through the AssociatedGroup list really only tells you if the group was created from this site’s site settings page or not.

Here is what the workflow returned for the Sub Site site, after I added a Test Group from the Sub Site’s permissions page, and then promptly removed that group’s permission from the Sub Site:

Just for fun, this is what the workflow noted for the Root Site as well.  Note, the Root Site did not receive any permissions for the Test Site:

Conclusion:

In conclusion, I would say, if you need to access any group at all within your Site Collection/Solution, for whatever reason, then you better use Web.SiteGroups.  If, on the other hand, you wanted to iterate through every group that can access your particular subsite (maybe you want to add users to those particular groups), use web.Groups.  Finally, I cannot think of any good use for the AssociatedGroups list.

By: Arjun Chakraborty