Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Our company wants to allows business units and departments to ask for Teamsites to be created for them in a special WebApp we've provisioned. Question is ... what is the recommended approach for creating the teamsite structure?

Do we go hierarchical (business unit => department). So create a sitecollection for the business unit then subsites within it for each department (or team). Or is it better to have each department to team to have their own site collection as a teamsite (flat structure)?

I can see that the hierarchical may require broken security inheritance between subsites to protect data which may become unmanageable over time... however the flat structure doesnt allow you to search over multiple sitecollections unless you provide special scopes for those teamsites which want it.

Any advice?

share|improve this question
add comment

2 Answers

I would recommend to incorporate the "Flat structure" that you have mentioned above,

Pros

  1. Handling security for each department would be rather easy, unless you say that each business unit should have different security features.

  2. Different site collections can be given unique branding, so master page or style modification of one department would not affect the other.

  3. Site quotas, site templates and all SharePoint functionalities can be maintained separately for each department.

Cons

  1. Maintanence can be looked upon as a difficult task as departments would be required to take separate backups. You can mitigate this by taking the whole web application backup at once.

  2. Certain level of complexity might arise while accessing data across site collections. But these all could be resolved using simple workarounds.

share|improve this answer
add comment

A couple of questions to ask yourself. Is there a requirement to control each dept site separately? For instance different site quotas, different features, recycle bin policies, different site collection admns permission policies etc. A yes to these questions might warrant site collections per dept. In addition think about growth of the site. If we use one site collection than backup's could take a while. For those site collections that our going to scale over time than perhaps separating into one collection makes sense for backup efficiency.

Lastly, rolling up content in one collection is pretty easy using Data View Web Parts and Content query web parts. So if rolling up content is important than one collection might be your answer.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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