A key factor that needs to be considered when planning for the creation of team sites for the management of records is access control. Getting this right (or as close to right as possible) early on for team sites with sub-sites will save a lot of potential pain later on.
Team sites will normally have three levels of access permission:
- Site owners. Full control. One to three for each site collection.
- Site members. Contribute rights, i.e., add/edit/delete.
- Site visitors. Read only access.
There are generally three ways to manage access controls in team sites that have sub-sites:
- Inheritance, broken as required. Top level site owners control all sub-sites, site members and visitors can be the same.
- Independent, within a site collection. Different site owners/members/visitors between the top site and sub-sites – although the site owners could be the same.
- Independent, separate sites but linked. Different site owners/members/visitors for each site.
Inheritance model
This is the default access model for team sites with sub-sites and is enabled when a Site Administrator creates a new sub-site without choosing ‘More options’ on the ‘Create’ Team Site dialogue page. Site owners control the top and sub-sites, site members and visitors are the same unless inheritance is broken on any part of the site (sub-sites, libraries or lists, or documents).
- The benefits of this model is that site owners control all the site collection and both members and visitors can be the same.
- The negatives relate to the effort involved in restricting access and giving unique access to sub-sites, libraries/lists, or documents. For example, to provide access to a specific area, a person who is not part of the default members or visitors group must be either added to one of those groups, or added individually. When they are added individually by user name, their user name appears across the entire site collection; they will be able to navigate ‘up’ (and down) but they won’t see any content in any page, library or list. Another negative is that, once selected, it is not possible to revert to the independent model (unique permissions); it is only possible to break the inheritance model and create new security groups which is a bit messy.
Independent model, within a site collection
The option to select this model must be selected when the new sub-site is created by clicking on ‘More Options’ after the Title and URL name are entered. A new dialogue box opens with a section ‘Permissions’. This notes ‘You can give permissions to access your new site to the same users who have access to this parent site, or you can give permission to a unique set of users’. It adds, ‘If you select “Use same permissions as parent site”, one set of user permissions is shared by both sites. Consequently, you cannot change user permissions on your new site unless you are an administrator of this parent site’.
There are two options:
- Use unique permissions
- Use same permissions as parent site (the ‘inheritance’ model above).
Again, there are positives and negatives to this model:
- The benefits of this model are that you can have unique access permissions on sub-sites, removing the requirement to break inheritance or worry about what users with access can see on the other parts of the site collection. Each sub-group within a team can have their own site that cannot be accessed by the other parts of the team – although you might consider giving other parts of the team visitor access, with the sub-group having ‘contribute’ rights.
- The negatives of this model are in the requirement to manage multiple access permissions for the top level site and sub-sites. Consider a common team environment – normally only a couple of people will be the site owner. If the site collection has multiple sub-sites with unique permissions, each of those sub-sites will have their own site owners. Of course, you can assign the same person to the site owner of each sub-site, but it is still a degree of overhead you don’t get with the inheritance model.
Independent model, separate site collections
This model simply consists of either of the first two options, with separate site collections added as links either on the global (top) or current (left hand side) navigation. End users don’t know that these links are completely separate sites unless they look at the URLs.
- The benefits of this model are the same as the benefits for the second option above (independent model). Each site collection has its own unique permissions. It also allows you, if you restrict team sites to one sub-site level, to have sub-sites on the linked sites, to get around that restriction. Separate site collections could have either ‘open’ access to everyone, or ‘closed’ access.
- The negatives of this model are also the same as the negatives for the second option above. Generally, however, there will usually be a good or compelling reason for having a completely separate site collection linked to the primary team site, and this often relates to the proposed site audience. For example, members of the team may be involved in a project; the (separate) project site can be linked to the main team site, but only those members of the team site with access will be able to see it.
In summary, it is important to consider access controls carefully, understanding both the benefits and the negatives of each option, then plan and implement accordingly. Otherwise, if there is a requirement to change the access type, this could be difficult to implement later on and the sub-site may have to be re-created.
Records about the world 