1

I have the following questions on when/why to use these approaches:-

  1. To create a new site column

  2. Or to use the same site column, but modify it at the list level.

I have these business case scenarios:-

  • Inside my team site I have 4 issue tracking lists. Each list have a column named “Category” of type drop down, when I first created the team site all the lists had the same choices for the “Category”. But now end users start asking that they need some lists to have different choices. So now I am thinking of allowing end users to modify the Category choices at the list level, but in this case I will no longer be able to manage the category field from the site collection level, because I cannot be sure that the Category field has not been modified at the list level.

So I have the following questions:

  • What is the formal or recommended approach for managing my above case? Should I from the beginning created 4 different site columns for the Category ?

  • Is it a bad decision to allow end users to modify the site columns at the list level, and to prevent system admins from doing any modifications to the columns at the site collection level ?

  • Let say I will save the tem site (which have 4 lists) as a site template. Where end users can start creating sub sites based on the template. In this case all the sub sites will be sharing the same columns at the site collection level,, but what if users need their sub sites to have unique setting for their columns ?? ,, The only approach I can think of is to modify the site columns at the list level ? or are there other approaches I am unaware of ?

1

It really depends on the type of content we’re discussing. If this is a project web where team members only have access, and company guidelines don’t restrict the use of task list in a way that it should be retrievable in reports you could let go and allow users to build their own task statuses. But if you have project webs that are managed in the same way where reports could be implemented further on – then I would think twice before allowing users to manipulate task status. When you allow the Wild West approach – it’s very hard to manage, especially when the number of project webs increase.

I’d go with a different approach and use one site column with all the task statuses that users find they need. Initiate a workshop and discuss the type of content you need in these different statuses. Maybe there is a real need for four different sets of task statuses. If so I would go with four different site columns having descriptive names so you can manage them from the back end. But if it’s only a matter of taste, then you could probably unite all the different opinions into one consolidated list of statuses. Those who don’t need all of them could filter the list in different views and hide statuses they don’t need.

Update

That said, I’d answer your questions as follows:

What is the formal or recommended approach for managing my above case? Should I from the beginning created 4 different site columns for the Category?

Create four different Site columns for category, inheritating from the original Category that should be shared across all different lists. It’ll improve search results.

Is it a bad decision to allow end users to modify the site columns at the list level, and to prevent system admins from doing any modifications to the columns at the site collection level?

No, not if they have appropriate training.

Let say I will save the tem site (which have 4 lists) as a site template. Where end users can start creating sub sites based on the template. In this case all the sub sites will be sharing the same columns at the site collection level, but what if users need their sub sites to have unique setting for their columns? The only approach I can think of is to modify the site columns at the list level? Or are there other approaches I am unaware of?

As long as these unique settings are unique and shouldn’t be used elsewhere and you don’t need these site columns in the search center or in any content search web part, then it’s OK to let go. Just be aware that there is substantial management to be performed if these different unique settings needs to be consolidated in the future.

0

The above case will not arise if the initial analysis (Which normally gathers during Governance & Information Architecture Planning) was done properly.

If you are planning to manage the Categories centrally then you should get all information which can go into that field and insert it into the Top Level. This approach will only work in case everyone agrees upon using the same set of data.

When users want different values, it will not be generic and the scope of using a global Category List becomes out of question.

To deal with your situation, I believe you can take the subset of Categories that are valid for all users. And once the user creates Site, they can use it as a starting point and enhance the list on the go.

The thing you need to remember is, once a user customize this at List level then you to apply changes from Top to Bottom you need to select option to Apply all content types inheriting from Parent.

  • you said "The thing you need to remember is, once a user customize this at List level you will not be able to push new Categories from Top to Bottom." but this is not valid in my case. i am using SP 2013 with SP1 and i have a team site with issue tracking list. now i have created a site column named "Area" at the site collection level, then i added it to the list content type named "Issue", so now i have the "Area" column copied at the list level. now inside the list level i add a new choices named "from List" – john Gu May 15 '15 at 12:37
  • so now the Area have additional choice at the list level compared to the site collection level. but when i go to the site collection and i edit the "Area" by adding a new choice named "from Site level" , this update affected the list where the "from list " choice was removed and the "from site level" was added ,, so i am not sure if in any mean changing the column at the list level will stop inheriting future modifications... – john Gu May 15 '15 at 12:37
  • I think there is an option checkbox which says apply this change to all Content Type inheriting from this.. Have you checked that? – Amal Hashim May 15 '15 at 12:39
  • yes i check that when i modify the column at the site collection level,,, but this is different from what i am asking ,, you mentioned that customizing the list will stop the inheritance .... – john Gu May 15 '15 at 12:41
  • Sorry I meant it stop inheritance only if you don't force it using that checkbox. I will edit my answer – Amal Hashim May 15 '15 at 12:42

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.