3

We have a SharePoint 2013 Web Application, which contains two Site Collections:-

  1. Team Site.
  2. Enterprise Wiki.

And I have created 2 Site Collections because of the following differences:-

  1. Each Site Collection had different permissions.
  2. They are based on different template. Where inside the Enterprise Wiki we create Wiki Pages, etc. while for the Team Site we have a general Calendar, Document Library, Announcement List.

Now we want to create a new Customer Site, where we will have a Sub Site for each of our customers. This new customer Site will have different permission compared to the current 2 Site Collections, and each customer sub site will have 4 issue tracking lists. Now our current team site collection has an issue tracking list and there are columns that I can re-use inside our customer site’s issue tracking lists.

So which approach is better to follow:-

  1. To create a new site collection for the customer site, and for the shared columns I will be managing them from the two site collections.

  2. Or to create a new sub site under our current team site, this will enable me to re-use the already existing columns, but I will have to stop inheriting the site permission and define a new permission for the customer site.

Can anyone advice?

  • 1
    When you say "there are columns that I can re-use inside our customer site’s" what is that exactly? Are they lookups or fields that are the same name? – David Lozzi May 13 '15 at 12:19
  • 1
    How many customers we are talking about? – Waqas Sarwar MVP May 13 '15 at 12:40
  • @DavidLozzi they are drop-down lists such as areas, Priority, etc.. – john Gu May 13 '15 at 12:53
  • @WaqasSarwarMCSE we have 30+ cusotmers – john Gu May 13 '15 at 12:54
  • For re-use the columns you can create site columns and content types in the content hub and publish it then you can use it in the other site collections – yngrdyn May 13 '15 at 12:55
3

I depends on many factors. Some of the rules I follow are

  1. Create Site Collections - For not related entities (Ex - Departments)
  2. Create Site Collection if we are dealing with large amount of data. This will enable us to split Content Database per site collection

In all other cases I simply create site based on the organization structure.

  • so what do u think better suites my case ? i feel more comfortable about creating site collection since many dependencies and conflicts can be avoided – john Gu May 13 '15 at 12:02
  • I think sites suite your requirements. You can break inheritance and have unique permissions. – Amal Hashim May 13 '15 at 12:05
  • Agree with Amal, as long as you don't see this customer's site (or its parent) ballooning in size or ever needing to be migrated to another environment/database. – thanby May 13 '15 at 13:33
3

Similar to the other posts, I recommend a single site collection for customers, and a subsite per customer. As far as sharing columns and such, use the Content Type Hub and load up your content types and throw those in your issues lists. If you don't have a site provisioning process, get one ;) this can handle your CTs and lists for you.

Then using search you can roll up any data you need across your clients.

If your site collection content database reaches your governance limits, then you can spin up another site collection and move some of your customers, either based on size, archival policy, or even by industry or other indicators you use to group your customers.

  • so you mean it is better to create brand new site collection for the customer site, and then create a new sub-sites for each customer,, and i should not do any thing inside the current team site..?? – john Gu May 13 '15 at 13:33
  • +1 for the provisioning recommendation. Especially if this is meant to scale to a large number of customers, that can be a huge benefit. @johnG If you expect this to grow significantly (in number of sites or amount of content) and the only reason you'd make it a sub-site is to keep that issues list, it's definitely better to make a new collection and use the provisioning process so they're easy to roll out. – thanby May 13 '15 at 13:40
  • I would lean towards a separate site collection only because it gives you more control over that, you can separate the content databases now and to minimize your need to do it later. – David Lozzi May 13 '15 at 13:45
1

As per you requirement, what i understand, you want to create the a site for each customer. I would recommend to create a customer site collections, t

  • his will seprate the customer data from your team.
  • Your url lenght will be short for customer's sites

For issue tracking list, as you already have the issue tracking list in the team site then you can

  • save that list as a template( without content)
  • create the new customer's issue tracking list using that template.

EDIT:

30 Sites will not be a big issue, only thing i am thinking about the size of the site. As a best practice always keep the site collection size /content DB size less 200GB for smooth operation.

  • Now you have to make a calculation, in next 1 year or so if you create sites under team site then what will be size.
  • if less than 100 i would with the team site but if greater than 100 then i would go with separate site collection into own content DB.
  • but i think i did not clearly state this as the customer site will not be accessed by our customers it is used for our internal use only ... so will this make any differences ? – john Gu May 13 '15 at 12:53
  • how many sub-site you want to create? if number of customer is less than may be under the same site collection. – Waqas Sarwar MVP May 13 '15 at 12:54
  • at first we will have around 30 customers site, and n the future we will have more .. – john Gu May 13 '15 at 13:01
  • check the edited answer – Waqas Sarwar MVP May 13 '15 at 13:03
  • so you are basing your decision just on the DB size,, while i was thinking of it in a more business oriented way and in the best way to achieve maintainability – john Gu May 13 '15 at 13:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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