The image above lays out a potential situation that can be created in any SharePoint deployment. What happened was that a site column was created in a site, and that site was later saved as a template. At that point, it was available for use throughout the site collection in question, and some sites were created based on the template.
What happens is that the site column ends up in the gallery for each site using it – sites A and B (in magenta) in the graphic above.
The normal behavior for site columns is that they are available at the site in whose gallery they reside, as well as any subsites. From a subsite the column is not editable, and when you go back to the site where it exists changes can be pushed down to any list using that column. But what really happens?
Create the situation above, and use a choice column for the site column that is part of the template. Give it some choices, save the template, and then go make some sites based on the template. Make sure that they are not part of the same subtree (as in the image), just to really drive the point home.
Make some lists in both sites based on your choice site column.
Now, update the column in the gallery for site A by adding a new choice, and have it propagate changes to all subsites. Look at the lists using that column in site A. The list column based on that site column will have been updated, which is the expected behavior.
What comes next could be unexpected. Look at the list columns in Site B. Those based on the choice site column that you created will also have the new option available.
Next could be even more unexpected. Check the site column gallery for site B, which also has the same site column defined. That version of the site column will be unchanged.
You could continue the experiment by modifying the gallery version of the column in site B, telling it to propagate changes below, and watching the change also effect site A’s versions of the columns in its lists.
So what is going on here?
When a site column is defined, SharePoint creates a GUID to associate with it. You can see what I’m talking about by checking any feature in the SharePointRoot/Features folder on disk, and noting that there is a globally unique ID associated with it. When you modify a site column in a gallery and tell it to push down changes, it looks at every LIST column in that site collection, and based on that ID swaps out the definition. It does not, however – as our experiment showed, update anything defined in any gallery.
Now, this behavior is completely fine almost all of the time. If you have two disparate sites with different galleries and manage to give two distinct site columns the same name, they will still have different IDs. If there is a parent-child relationship, it will be disallowed and you’ll be forced to update only the parent version, as the child gallery will show the column as read-only. We defeated the use case by putting our column into a site template and using that instead, which preserves the ID.
Will this behavior happen across site collections? Not at all, even in the same content database. Try it to find out.
You may wonder if this behavior applies to site content types as well. Try it, and post your results.
The morals of the story are to be careful when putting site columns into site templates, and that you can learn a lot about how SharePoint operates by tinkering with your ideas and questions. Since behavior is subject to change across versions of the product (even minor patches), it is always best to try things out before assuming certain behavior.
In Summary: Define a site column in a site template, make sites based on that template in various locations in your site collection, use the site column in lists. Now updating any gallery version of the site column will update every list using it, regardless of the tree position of the list.