SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have recently had a couple of clients that are adopting SharePoint that for various reasons want as flat of a structure as possible.

Instead of building a site that mirrors the organization structure, or different knowledge domains or anything else really they prefer to use big lists (page, document, announcements) and tag the content and use web parts to display relevant data to users, partially backed by term store.

Often this is driven by frequent organizational changes so they feel an actual structure would be too restrictive.

On most prior projects discovering the basic structure has been part of the early phase of the project. Now this still has to be done for the term store.

So I am curious what your views and experiences are like.

Is the new trend as flat as possible?

share|improve this question

'It depends'[tm]

One project I've had periphery work on did go with a hybrid, where some structures wouldn't change that often (such as regions of a country), but managed metadata within a huge flag list for things that could be fluid with changes (like organisations and logical groups of organisations within a region).

I think you need to capture as early on as possible what the requirements are for the data stored, and also get requirements for end of life of that data, as well as operational requirements for day to day tasks.

If things change often, use a flatter hierarchy. For more rigid things, use a site hierarchy perhaps, but allow for provision for the hierarchy may changing, and find out what/how that might happen and what the best way would be to implement those changes (Workflow, Item Receiver code, simple re-parenting of sites, etc.).

share|improve this answer

I had a similar request also fairly recently. I advocated for a more traditional approach using sites and sub-sites, but they wanted to go with a more flat approach. As it turns out they ended up having to with my original suggestion due to various permission requirements.

If you have to restrict permissions then these types of configurations become more complex and messy where applying permissions at the site (or site collection level even) is a much cleaner approach. It also lends itself to future growth and scalability.

share|improve this answer
Great point. Thank you. – Development 4.0 Feb 28 '13 at 12:28

Your Answer


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.