Recently, I have been having some major problems with updating site columns and content types that have been used across 100s of sites. Ultimately, site columns and content types are very useful for re-using and sharing metadata. The problem is, that if you want to customise site columns or content types at lower level e.g. Add a few extra Document Topics at a library level, you then lose the ability to be able to update column values and content types at the site collection level. An update at this level will wipe out/override the changes you have made at lower levels including column defaults and ordering in library content types.
It would be so nice if SharePoint had a “Cascade Where Un-customised” setting on site columns and content types so that changes were filtered down, but only to “parts” of the column/ctype that had not already been customised. E.g If I have set a default value for a column at a library level, when I update the site column to let’s say- add an additional choice value, it would be nice if the default was not overridden on my library.
So why bother using Site Columns and Content Types at all if changes at lower levels are going to remove the ability to provide mass updates without breaking all your customisations below? Well, at the Site level, this problem is alleviated somewhat and therefore I would recommend implementing them at this level rather than at site collection level. This way, you are taking advantage of metadata “re-use and sharing” but you are also allowing flexibility in modifying site columns and content types specifically for the site. When you think about it, it is very likely that 50 sites will need to customise a generic content type to better suite thier needs, but a single site, generally shares the same function/information/users, so at that level, site columns and content types could be specifically designed and therefore would be less likely to need customisation at a library level. It’s not fool-proof that’s for sure. If you want to optimise and streamline the input of metadata you are bound to want to at least set some defaults at a library level. Just make sure you think about and plan for this stuff when designing your metadata model instead of afterwards.