Have you ever created a SharePoint site column of type “Person or Group“? Did you use this column in a content type used by Microsoft Word documents? Distributed from a content type hub? If so, you may be in trouble…
This type of site column was just what my client wanted. A smart lookup-field where they could select employees to tag their documents with. And it even comes with communicator presence information by default. Perfect for a HR department. One would even think that this field would work if an employee changes her name. In theory.
In practice however, the situation is rather different. In fact, this type of field can cause big trouble: The person added to this column may change to a different person!
Seriously? Yes, I’m afraid so. If you move a Word document from one site collection to another, you will probably see that another person shows up in that field/column. You may also see that the person is lost, or in rare cases, the correct person will still be there.
How can this happen? Well, in the document property promotion process values from the document metadata fields/columns are promoted to the SharePoint library (list). And similarly, in the document property demotion process, values from the columns in the library are demoted back to the document.
One should think that for a Person field, the DOMAIN\username would be written to the document, but this turns out not to be the case at all. This is what I found inside my test document:
<Company_Employee xmlns="264156cb-56b7-53fe-ad4d-c6818be5ec95"> <UserInfo> <DisplayName>Garnes, Øystein</DisplayName> <AccountId>10</AccountId> <AccountType/> </UserInfo> </Company_Employee>
It turns out that the display name and an account id is what is written to the document. This ID is the ID from the UserInfo table in the content database, which is local to each site collection! Hence, ID number 10 might be me in one site collection, but not in another. Use the following link to look at the users in your site collections:
When you upload a document to a new site collection (which also has the content type with the same person-field), the promotion process will read that ID number, and try to match it to a user is it’s own UserInfo table. This gives three possible outcomes:
- Another person has that ID (e.g. ID no. 10 might be John Smith). If so, SharePoint will exchange the current display name with the new one.
- No person has that ID number in the target site. If only 8 persons were referenced so far in site 2, ID 10 would not exist, and SharePoint would delete the current person from that field
- If you are lucky (I was once in my test environment), the ID number corresponds to the same person in both source and target site, and the information is kept unchanged.
I asked a question on the SharePoint MSDN forum in this thread, but I have had no replies yet. If you can prove me wrong, or have a workaround, please add a comment below!