Editing Site Columns on Sub-Sites Doesn't modify the parent Site Column

Iron Contributor

When editing a site column on a document library or sub-site (by adding an additional choice for example) the change does not seem to get reflected up to the parent site column settings.

 

Is there a way to force the changes up to the parent?

 

If not, is there a way to limit editing of site columns to only on the top level?

16 Replies

To my knowledge, changes made to a site column at a sub-site or application level are not intended to be passed upstream so as to preserve the integrity of SharePoint's administrative structure.

 

As for limiting the editing of site columns to only top site/source level, I do not believe there to be a configuration item in SharePoint Online to restrict the editing of site columns downstream; SharePoint treats site columns brought downstream more as templates that can be changed, although it does allow for configuration changes made at the site column's source to be passed downstream to any site or application using that column.

Totally agree with Matt comments!

This is very disappointing.

 

I am worried about sub-site admins modifying site columns by adding or modifying "choices" to the list at a sub-site level. The system will quickly break down if every sub-site admin starts managing the company wide site columns at their sub-site levels.

 

The result will be every sub-site/document library having different choices on what are supposed to be company wide standard terms.

If you are concerned specifically about Choice columns, you might consider using a site column of type Lookup, instead. Place the lookup target list of choices at the top level and don't allow sub-site admins write access to it.

 

 

@Richard Sharp Thanks! 

That is a great idea..... I'll have to redo a bunch of my columns but this is probably the best solution.

 

In other news I found out why Microsoft is probably not implementing a solution for this. This blog from 2012 claims that column level permissions would be a major drain on performance of the database. 

@Richard Sharp So I have set up several columns this way but I'm noticing one serious missing problem. When you place the lookup site column on the document libraries you can't set the default value. I think the default value has to be set on the top site collection level.

Is there a way around this? Maybe a work flow? ..... would probably be too hardcore to set up for every doc library....

This has always been an issue in SP, the fact the site columns created at the top  of the collection are indistinguisable from those created at lower levels makes it very confusing. One thing you can do is create Content Types at the top level to bundle site columns together (or in the Content Type hub) and then train the subsite admins to use the CTs. 

First: if you're not using content types already, do so--that'll make your deployment of site columns a lot faster and easier to control from the top-site/source level.

 

Second: thinking about why lookup columns can't have a default value, I think Microsoft is anticipating that consequences could arise from allowing that. If you had a default value in place from your lookup list, then that value changed, your default value in the list/doc library using that list now has an invalid default value.

@Dean Gross yeah I keep running into the concept of Content Types everywhere I turn. I have read a lot about them but am struggling to figure out how to actually implement them in my situation.  Do you know of any good tutorials?

 

I probably just need to try poking at it until I fumble my way to some sort of understanding - like I am with Site Columns. I think I have remade some of these columns 4 times now..... which means any views I made or metadata I applied is all worthless.

Think of content types as a set/package of site columns that you can apply to a list or document library all in one go. While the columns can be changed downstream, any changes made at the top-site/source level can be passed down to anything using the content type. In that way, they're very similar to site columns. This saves a lot of time when changing column configurations.

Take a look at https://support.office.com/en-us/article/Introduction-to-content-types-and-content-type-publishing-E... and https://collab365.community/understanding-content-type-hub-cth-in-sharepoint-2013/. The 2nd article shows how to set up a Content Type hub in SP 2013, but that is done for you in SPOnline so you can just focus on the first few sections of the article. 

 

My strong recommendation is to start with something simple. Just create one CT and play around with it, it is very easy to get too elaborate too soon and this can cause a lot of pain and rework.

@Dean Gross just dipping my toes into content types. I've watched several tutorials and read several articles but haven't come across one thing in particular.

Is there a way to set default lookup metadata on a specific content type? 

I think that you may need to make the group of Content Types the Default Content Type Group for the List you're looking at

One heads up of using site column of type lookup I believe to still be the case, from previous testing, you can't use the values in SharePoint Designer workflows on the sub-sites (it will fail/error out because of cross-site stuff). I've had to do things like calculated columns, or in Nintex formula fields to duplicate the lookup value to be able to use in workflows. Maybe this has changed, but I had so many headaches with it I stopped messing with it.

@Dean Gross let me try to understand:

For example:

 

I have a list of all the models of widget my company makes and add site-columns to that list that are themselves looking up in other lists for the choice of project number and market code for example.

Model Number List.png

If I select the project number and market code in this list, does that mean the model number (title) is always associated with that project number and market code whenever that model number is selected as the metadata to apply to a file?

Model Number List - Annotated.pngThis would seem to be a way to force a default on specific metadata.....

The above proposed solution does not work.... how do other companies deal with default metadata? Surely there must be a way to force metadata on a file? Do I need to learn how to use work flows?