Modifying a site column at the list level versus creating new site columns

Question

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 ?

Answer 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.

Answer 2

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.