When To Use A New SharePoint Site Collection VS. A New Sub Site

By: John Tallon | Comments | Related: > Sharepoint Design

Problem

I have been asked all too often by clients, "When should we use a Site Collection and when should we use a Sub Site?". What's the best option and how do I choose?

Solution

The good thing to remember is that there is no definitive answer to this question, however, there are more technical factors that can help you decide on whether you should chose a site collection over a sub site or vice versa.

Some of the reasons that I might pick a Site Collection

I have a branded new site and I want it created with no relation to any other site. If you are creating a new site and it's not related to any other sites that you have in your existing site hierarchy or SharePoint farm then you chose a site collection.
If you require a dedicated URL to your site. You want your client to access and upload documents so you want to create a URL for your partner at http://partner.mycompany.com. You can bind this URL to a site collection. This URL cannot be bound to a sub site of an existing site collection.
You want to create a managed path calleddivisionsand you want to create a site for each division you your organization. Each division wants complete control over their site and sub sites and want to be found at URLdivisions/divisionName.
Where you require to have a quota set on a site created you will need to use a site collection as only site collections can have quotas assigned to them.
If you need a dedicated Content Database for your site as you expect to have vast amounts of data and documents and you require it to be more secure that normal, you can can configure a dedicated site collection with a dedicated content database attached to it.
If you were purchasing hosted environments from a hosting provider then you would also see the difference in a site collection and a sub site in the cost model offered by the hosting company. You will notice that getting a site collection provisioned with have a higher admin cost than just creating a sub site. Sub site creation can be carried out by a member of the owners group of any site or site collection. Whereas site collection creation has to be completed by Farm Administrators unless there is a mechanism provided though web wizards.
As part of a backup and recovery policy you want your data to be very quickly restored if there are any problems or if there has been content that has gotten deleted that you need to retrieve. A site collection is better in this case because you can restore the site collection more easily than you can restore a site or a sub site of a site.

Some of the reasons why you should select a sub site:

You want to inherit the same security for the new sub site as its parent site & the security model for your organization already exists. You want to create a new site but you don't want to change or move away from the existing security model implemented already.
There has been a team in your organization unit that created many new site columns and site content types that you would like to use throughout your site and its sub sites -- as parent sites can contain site content types, these can be used in all subs sites of the site hierarchy -- Site Collections break this functionality.
You want to allow the Site Owners and Designers to manage all sites that get created without any overhead of having to log a support call for a new site collection.
You want to aggregate data throughout your site hierarchy using Web Parts like the Content Query Web Part, Data View Web Part and other data aggregation Web Parts.
You have a site template that you want to apply to the new site that creates a couple of lists and libraries as part of the template -- an example may be you want a Tasks Manager Site Template where a site can maintain and manage all your tasks using tasks lists and to have them integrate with Outlook.
If your site is going to be a short lived site and it's only going to be used in the process of creating some other content. An example might be a meeting site where you create a site that is created from a Meetings Templates. You can record and schedule meetings regarding the production of a catalog of products for your organization. This site is short lived and won't be in existence after the production of the catalog is completed.

When do I have crossover?

What about the times where I don't technically have any requirements like a dedicated URL and Content Database, tight security with very limited access, custom coded solutions deployed to a site collection, etc?

If you do not have any of the requirements listed above or indeed any technical requirement that might need a site collection then you should always be thinking of the Sub Site as the way forward. You can get most, if not all, of what you want by using sub sites and there are no extra overheads in using sub sites. Site Collections and all of the content created within its site hierarchy is accessible and can be aggregated using some of the Out-Of-The-Box web parts. This works well for intranet type sites and sub sites. News from the IT/Operations site can be easily aggregated to the root site without the need for extra authentication or custom code.

Building an Intranet Site Hierarchy

Let's take a walk-through of creating an Intranet for a medium sized company and see how we might decide on how the Information Architecture and the design of the site hierarchy may look.

OK, our CEO wants to use SharePoint as the single source of company information for the entire organization. We have limited hardware and the farm is going to be a SharePoint Server Farm with one SharePoint Server and one SQL database backend Server.

The agenda here is to create the organization's hierarchy using sites and lists in SharePoint so it is important to think about the way that the organization structures itself. So the first thing we might do is look at the organizational units within the company. From the Top to bottom:

Board of Directors (Site)
Departments (Site)

Human Resources (Site)
Finance (Site)
Marketing(Site)
Information Technology (Site)
Sales (Site)
Service and Support (Site)
Logistics (Site)
Research and Development (Site)
Manufacturing (Site)

Functions (Site)

Company Secretary (News, Announcements)
CEO (Blog)
Human Resources Manager (Blog)
CIO (Blog)
CFO (Blog)
Company News (Company Secretary)
Jobs and Careers (HR)

Taking the above hierarchy we need to decide on what type of content to use (Site or Page) for the different departments and functions. In this case we choose to use sites (Sub Sites) as they offer more functionality and also allow us to build out the department's internal hierarchy. We create a new sub site called Divisions that will parent all the department sites. This will allow us to create a landing area/site for all departments and we can aggregate news and announcements from all the departmental sub sites into one section. On the department's site home page we would like to offer a series of useful links to content in the specific department site, such as HR Documents, IT Support, Sales Team Contacts, R&D news, etc.

We need to engage with developers/web admin (and creative designers) to build a Department Site Template that will offer a consistent look and feel and consistent placeholders for content that should be commonly shown for each department eg: Department Contacts List, Announcements, Latest News, etc. These site templates are saved in the site collection's Site Template Gallery and will be available to all sites and sub sites in that site collection. All sites from the top-level portal down to the landing page for each department should have the publishing features enabled so new content can be approved before it is published and made live for all employees to see.

We need to be consistent with the news articles that we communicate to employees. Our web administrators will create a new content type in the site collection called Company News which is based off the Article Content Type. We will need a new Layout page created from this Content Type that will be designed to convey the company brand and special fields for news articles. The news articles will be Pages in a SharePoint document library.

Announcements will be housed in the Announcements List that we can create out of the box. This will not be used for news articles. There should be a distinction between the two drawn up. Example, where we have a new employee in department X an announcement would be made, but if our sales team had just secured a deal worth 1 million with a new client, the company will make a big news article out of that.

There are company documents that need to be set as read-only which need to be available on the intranet for all employees to read. These include documents like past and current strategy documents, support documents, employee handbooks and other static documents produced by the company. As these documents are global and don't belong to any particular organizational unit the correct place for these to be located is in a document library underneath the main portal. Alternatively we could setup a document center type site and store all of these types of documents in libraries in this site. Most of the documents in circulation in the organization are not static, so the volume of documents that would be saved to this location would not warrant a dedicated site as this point.

Contacts are a very important when needing to collaborate on projects throughout the organization. There can be project contacts, site contacts, document contacts, department contacts, partner contacts, etc. We would allow most of our sites decide and manage their own contacts list, but there would be general contacts that each employee should be aware of. These would include HR contacts, IT contacts and other relevant contacts that we would house in the main portal.

So where would we need to use a Site Collection?

There are no rules governing when and where to use a site collection over a sub site. Most often the reasons become more technical rather than business centric. We know that the effort spent branding, creating company content types, workflows, List and Site Templates are all relevant to a site collection, so if we want to use a separate site collection we need to take into consideration that already existing customizations will not be available in the new site collection without some re-working by both our SharePoint Developers and Administrators.

Taking that into account what we want to do now is open up a new site collection that is going to be dedicated to a new product that the company is going to develop. We need to include most of the departments but only few employees and project stakeholders from each. Loss of branding is not going to be a huge draw back -- we can get our developers to package our branding into a SharePoint Solution and that would take care of that -- but we want this site to be more secure than normal as there is some very sensitive data that we need to control. The content created in this site is going to contain 10's of project sites, management dashboards, and research and development outputs and, ultimately, will grow rapidly in size and usage. We want a dedicated content database because our administrators have advised us that it would be the best direction due to the rapid recovery process in the event of data loss and we can have it disjointed from our main portal.

We do not want the content to be searchable from our main portal so this separation fits perfect in this case. Also, in the future we might need to allow external access for partners and other external users. By using a site collection this would allow us to restore the content on to a newly provisioned dedicated Web Application and extend it to allow non-active directory users in.

So in summary using a site collection to store this content made perfect sense. It allowed us to be fully integrated with the company while still allowing the flexibility to allow external users access without having to reconfigure our original portal or be concerned about sensitive data. It gave us a potentially speedier response and recovery time in the event of a disaster and made the site collection more portable if the need arise.