none
Modifying the built-in site columns. How we need to manage this

    Question

  • Sometimes I face problems in SharePoint that I cannot find any direction about it. Here is my problem.

    Now we want to create an issue tracking list to store tracking items for our department. So I did the following steps:-

    1. I create new site content type named “My Custom Issues” which inherit from the built-in issue content type.
    2. I added some new custom site columns to the new content type.
    3. I reorder the columns and I hide some of the built-in site columns from the new content type which are defined inside the built-in issue content type.
    4. And I start testing the result.

    Now seems everything is working well, but I am now confused on how I should manage the following modifications:-

    1. The built-in Description field is of type “Rich Text” and it is set as “Optional”, but I want to modify it be of type “Enhanced Rich Text” and to be Required.
    2. Also the built-in Priority has a default value of “Medium”, while I want to remove this default value.

    So I search/read a lot about how I should manage modifying built-in site columns, but I could not find a clear answer, as each approach might break at certain point and also might break some built-in features. Here are the approaches I find:-

    1. I can go to the site setting and simply modify the built-in “Description” & “Priority” site columns from the site level and chose to update all the list columns.

    Now this approach is the easiest and most standard way. But I have read that modifying built-in site columns might be overridden in the future if we apply an update or we want to upgrade our site columns.so this approach is not recommended

     

    1. Other approach mentioned that modifying any built-in site columns should only be done at the list level. But I am not sure why this approach will prevent future updates from overriding my customizations. And also managing columns at the list level will complicate the maintainability of the site columns.. so I will lose the ability to manage the columns from the site level.
    2. Another approach suggest that if I want to modify the built-in site columns then I should create my own custom columns. but following this approach will mean that I will not be able to benefit from any built-in features .. Since built-in features will most probably rely on built-in columns…

    So can anyone advice how I need to manage modifying built-in site columns? And I do understand that future updates can override my modifications,, but not sure if usually SharePoint updates (such as installing a full CU) will also affect the column at the list level.. so let say to implement my current modifications I went to the site column and I modify the Description to be “enhanced rich text” & set it as optional, Also I remove the default value from the Priority column, and I chose to update all the list columns,, so this will modify the site column at the site level and also at the list level.. Then let say I install a full CU which override the Description to be optional + to be “rich text” again.. then will this update also apply these changes to the list columns??? It is really not clear to me…

    Friday, April 21, 2017 12:29 PM

All replies


  • Hi johnjohn123, 

    Per my research, modifying the built-in site column in the gallery isn't an good idea.  It may revert at some point in the future when you install an update or service pack.  These kinds of modifications can be made at the list level, but should never be made at the site collection level.

    You'd better do a test in your environment to see that whether modify built-in site columns will be overridden if you install an cu on your environment.

    Best Regards, 

    Lisa Chen 



    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Saturday, April 22, 2017 10:15 AM
    Moderator

  • Hi johnjohn123, 

    Per my research, modifying the built-in site column in the gallery isn't an good idea.  It may revert at some point in the future when you install an update or service pack.  These kinds of modifications can be made at the list level, but should never be made at the site collection level.

    You'd better do a test in your environment to see that whether modify built-in site columns will be overridden if you install an cu on your environment.

    Best Regards, 

    Lisa Chen 



    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    thanks for the reply. can you find my comments to your reply

    >> These kinds of modifications can be made at the list level, but should never be made at the >>site collection level.

    but i am not sure what do you mean by this.. let say i went to the site settings >> site columns >> Description column>>then i change its type from Rich Text to Enhanced Rich Text >> i chose to update all the list columns. now if i install a CU and this CU override my Description column settings,, then will the Description column at the list level get overridden also ?? or in most cases if a CU will override a site column,, then it will not propagate the changes to the list level.. or there is not any gurantee

    Second question. in all cases what is your recommendation, if i want to have my built-in Description field as Enhanced Rich Text and to be Required ??

    >>You'd better do a test in your environment to see that whether modify built-in site columns >>will be overridden if you install an cu on your environment.

    now this point can not be tested.. i mean not all CUs will override site columns....so i can not test this..
    • Edited by johnjohn11 Sunday, April 23, 2017 12:21 AM
    Sunday, April 23, 2017 12:20 AM
  • Hi johnjohn123, 

    I have done a test in my SharePoint 2013, no matter i modify the built-in site column at site level or list level, after i install an cu in SharePoint 2013, the cu will not override the changes. 

    I think you can change the built-in site column at both site level and list level.

    Best Regards, 

    Lisa Chen 




    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com


    Wednesday, April 26, 2017 5:37 AM
    Moderator
  • You can but you shouldn't.

    There is no reason you need to use the OOTB description column, you can clearly create a new field with a slightly different name. That gives you full control.

    By using the OOTB field that means that you are affecting all the other content types that use it elsewhere in the site. That means that you may have unforseable and unpredictable effects for lookups, search results, any more clever web parts that assume the column type etc.

    In short: Yes it can be done. No, doing it at the Site Collection level is almost always a bad idea and if you have to ask if it's a bad idea in your case it always is.

    • Proposed as answer by Jason Warren Wednesday, April 26, 2017 7:34 PM
    Wednesday, April 26, 2017 9:41 AM
  • Leave the OOB columns/fields alone. Create new columns/fields for data your system needs.

    Wednesday, April 26, 2017 7:35 PM
  • Hi johnjohn123, 

    I have done a test in my SharePoint 2013, no matter i modify the built-in site column at site level or list level, after i install an cu in SharePoint 2013, the cu will not override the changes. 

    I think you can change the built-in site column at both site level and list level.

    Best Regards, 

    Lisa Chen 




    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com



    But my point is that if you try installing a CU and this CU did not change any of the built-in site columns, then we can not guarantee 100% that future CUs will not override certain site columns.. so the question is could (rather than will) a CU override some built-in site columns?? seems the answer is Yes.. and even if we test installing CUs and those CUs did not override site columns ,, then we can not guarantee that this  will always be the case all the time... i hope that you got my point..
    Wednesday, April 26, 2017 11:05 PM
  • You can but you shouldn't.

    There is no reason you need to use the OOTB description column, you can clearly create a new field with a slightly different name. That gives you full control.

    By using the OOTB field that means that you are affecting all the other content types that use it elsewhere in the site. That means that you may have unforseable and unpredictable effects for lookups, search results, any more clever web parts that assume the column type etc.

    In short: Yes it can be done. No, doing it at the Site Collection level is almost always a bad idea and if you have to ask if it's a bad idea in your case it always is.

    Thanks for the reply... so you are not against modifying built-in columns.. but if i want to modify them then i should do this at the list level only ?

    second question. could installing a CU or upgrading our farm from 2013 to 2016, override my site columns settings at the site level and at the list level ?? for example let say i change the Description field type from being of type "Rich Text" to be of type "Enhanced Rich Text", at the site level and i define to update all the underlying list columns... then could in the future the Description field be reverted back to be of type "Rich Text" at the site level and at the list level???

    Third Question.. now when it comes to other fields such as Priority or Category and i wanted to have different choices for these drop-down lists, i always hide the built-in site columns and define my own custom Priority and custom category site columns...but in the Description field i find that the built-in search service rely on this column,,, for example when i search for  list item ,, the search service will show the following result (Item Title,Item Description, URL) as follow:-

    so now if i hide the built-in Desertion field and i define my own custom description,, will the search service still display the item description (now based on my test SharePoint service was clever enough to start showing the new custom description field inside the search result).. but to be honest i am not sure how SP chose my new custom description field to be displayed inside the search result automatically, without require me to do any modifications to the search service???

    Can you please advice on the above 3 question.. and apologies for the long reply...

    Wednesday, April 26, 2017 11:19 PM
  • Leave the OOB columns/fields alone. Create new columns/fields for data your system needs.

    but if i create a new custom description field ,, then will this affect built-in services such as the search service ??? as seems when searching list items, sharepoint will show the item description as part of the search result... so if i hide the built-in Description and  create a new custom description,, then will sharepoint start showing the new custom description.?? Now based on my test SharePoint service was clever enough to start showing the new custom description field inside the search result.. but to be honest i am not sure how SP chose my new custom description field to be displayed inside the search result automatically, without require me to do any modifications to the search service??? so this leaves me uncertain if sharepoint search service might be affected if i hide the built-in Description field ??

    • Edited by johnjohn11 Wednesday, April 26, 2017 11:23 PM
    Wednesday, April 26, 2017 11:23 PM
  • Search should pick up the new column, yes, but for best results you would want to create a managed property that has settings to meet your search requirements.
    Thursday, April 27, 2017 4:42 AM
  • Hi johnjohn123,

    Refer to the following article about what makes a SharePoint column searchable:

     http://www.techmikael.com/2014/07/what-makes-sharepoint-column-searchable.html

    Best Regards,

    Lisa Chen

    Please remember to mark the replies as answers if they help.
    If you have feedback for TechNet Subscriber Support, contact tnmff@microsoft.com

    Thursday, April 27, 2017 6:06 AM
    Moderator
  • Search should pick up the new column, yes, but for best results you would want to create a managed property that has settings to meet your search requirements.

    now i am using sharepoint 2013 and it will automatically create managed property for my site columns, when running a full crawl. and yes i got a managed property for my new CustomDescription site column.. this is not the problem... as the CustomDescription column is searable...

    But my question is about the built-in search results, which will by default show 3 main info about the list item ;Title + Description + URL. as follow:-

    So now if i hide the built-in Desertion field and i define my own custom description,, will the search service start displaying the new custom description??? Now based on my test SharePoint service was clever enough to start showing the new custom description field inside the search result.. but to be honest i am not sure how SP chose my new custom description field to be displayed inside the search result automatically, without require me to do any modifications to the search service??? could for example the reason be that search service will always show the first multiple line site column to be shown inside the search result ?? this can explain why search service start showing the new CustomDescription site column inside the search result when i hide the built-in description field... but i am not sure if this is the case or not ?? did you get my point ?

    Thursday, April 27, 2017 1:35 PM