I have a team site collection inside SharePoint server 2013. Now I added a new issue tracking list, where the build-in site columns such as priority, status, description,comments,assigned to etc satisfy most of my needs. But I want to have these two modifications to the build-in site columns:-

• The build-in site column named priority came with a default value = (2) Normal While in my case I want to remove the default value of the priority. I know I can do this at the list level, but I do not want to have the site column and its list copy not in sync. So my question is it a bad practice to remove the default value of the built-in Priority site column ? and it is better to create a new site column similar to the built-in Priority but without default value ?

• Another modification I want to do it that the built-in Description field is set as optional with Rich Text editor, while I want to make it a Required with Enhanced rich text editor. So I am asking the same question is it bad to modify the built-in Description site column and do these 2 modifications ? or it is better to create a new site column similar to the Description that is defined as required with Enhanced rich text ? Thanks

Hi

a general advise

Isn't a good practice to modify default settings, site columns, master pages... and the list could continue.

The principal cause is that  in a possible future upgrade for Sharepoint product, it's possible that your customizations will be modified

For instance , if you need to apply your customizations how your site looks like, you will not customize existing css files, you will use custom css file/files, and load them where is necessary.

Modifying the built-in site column in the gallery is always a bad idea and unsupported.  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 collect

Hi

a general advise

Isn't a good practice to modify default settings, site columns, master pages... and the list could continue.

The principal cause is that  in a possible future upgrade for Sharepoint product, it's possible that your customizations will be modified

For instance , if you need to apply your customizations how your site looks like, you will not customize existing css files, you will use custom css file/files, and load them where is nece

yes, if you want a custom default it needs to be managed at the list level for a default column.  You could also create your own column with your own default.  But that column might not work with any built-in code, like workflows.

If you modify it at the list level then future updates will not be applied to it.  You modify it at the list level because you want it to be a unique instance of the column.  At that point it is unique and won't be affected by future updates.

yes, if you want a custom default it needs to be managed at the list level for a default column.  You could also create your own column with your own default.  But that column might not work with any built-in code, like workflows.

If you modify it at the list level then future updates will not be applied to it.  You modify it at the list level because you want it to be a unique instance of the column.  At that point it is unique and won't be affected by future up

The bottom line is that it doesn't work the way you want it to and cant be made to work that way.  If a built-in column has a default then the only provision for changing it that is supported is to change it at the list level.  I know you don't want it to work that way, but that's the way its designed to work and you can't change it.

I meant that creating your own Priority column may break other functionality built-in to SharePoint.  Creating custom columns is fine.  Creating custom columns as a replacement for built-in columns may not work because there is additional functionality that is built to work with the Built-in columns and that functionality isn't normally designed to work based on Display Name.  Since your custom column will not match the Guid and internal name of the built-in column it may not work with built-in functionality.  That's not the same as building a custom column to extend the metadata stored on an item.  Building new custom columns is fine.  Building custom columns as a replacement for built-in columns may not work.

The bottom line is that it doesn't work the way you want it to and cant be made to work that way.  If a built-in column has a default then the only provision for changing it that is supported is to change it at the list level.  I know you don't want it to work that way, but that's the way its designed to work and you can't change it.

I meant that creating your own Priority column may break other functionality built-in to SharePoint.  Creating custom columns is fine.  Creating custom columns as a replacement for built-in columns may not work because there is additional functionality that is built to work with the Built-in columns and that functionality isn't normally designed to work based on Display Name.  Since your custom column will not match the Guid and internal name of the built-in column it may not work with built-in functionality.  That's not the same as building a custom column to extend the metadata stored on an item.  Building new custom columns is fine.  Building custom columns as a replacement for built-in columns may not

As I've explained several times.  If you want to have custom values for a column that is used like a built-in column then you should change the values at the list level.  All the other schemes you are suggesting will result in issues.  I've tried to explain to you how it works, but you keep insisting that you don't want it to work that way and want it to do what you want to do.  I'm sorry but it isn't built to work that way.  I don't know any other way to explain it.

I'm sorry you don't like the way it is designed to work.  I didn't design it, I'm just trying to explain what is possible and what is not possible.  I will not be responding to this or the other thread any more.

As I've explained several times.  If you want to have custom values for a column that is used like a built-in column then you should change the values at the list level.  All the other schemes you are suggesting will result in issues.  I've tried to explain to you how it works, but you keep insisting that you don't want it to work that way and want it to do what you want to do.  I'm sorry but it isn't built to work that way.  I don't know any other way to explain it.

I'm sorry you don't like the way it is designed to work.  I didn't design it, I'm just trying to explain what is possible and what is not possible.  I will not be responding to this or the other thread any

Hi John,

We're looking forward for the exact answer meanwhile go through the below forum.

http://sharepoint.stackexchange.com/questions/117359/creating-new-site-columns-or-renaming-existing-ones-which-approach-i-should-fo

Your option may work with a few provisos: You must use something other than 'Priority' as the name when you create the column, that way it will have a different internal name. For example you could create your column as 'JJ123Priority', which will be used as the internal name.

You can then re-name the column to have a display name of 'Priority' and you can configure it as you'd like. Although i'd recomend you keep some tag on it to make it obvious where it applies.