After having some pleasant discussions in the SharePoint Yammer SPYam community on this subject and finding almost no information online about this topic, I thought I’d put some fingers to  keys and do my part to share some information.  This post assumes you have basic concepts and knowledge of SharePoint taxonomies, but review TechNet if you need more info or to get up to speed on the basic concepts.

Have you seen these terms?

These first appeared in SharePoint 2013, but this functionality is possible with SharePoint 2010, just requires a little more effort.  In SharePoint 2013, Microsoft really pushed to further expand the capabilities of the Managed Metadata service, like now allowing it to be used for Navigation items.  Additionally, they also give you some default term groups in the metadata taxonomy store.  If you look in the default term store of SharePoint 2013, you will see taxonomy groups for People, Navigation, etc.  In this post I want to focus on the People term group.

There are 3 term sets by default:

• Department
• Job Title
• Location

Assuming you have setup the User Profile Service Application, a sync connection and ran an import, it’s very likely you might already have terms in at least Job Title.  Why is this, and what if it’s filled with junk?  Let’s see how these get here.

These 3 term sets get populated from corresponding User Profile properties, which in turn pull from your directory source (likely Active Directory).  To see this mapping, go to Central Administration –> Manage service applications –> click on the User Profile Service application, then click on Manage User Properties.  Let’s take a look at each one.

Department

There are actually 2 Department fields.  Both are fed from AD by default, but only one feeds into the taxonomy store. 

You have to look at their properties and look at the Name to see the difference:

I can’t say this for sure, but this is my opinion of the purpose of these fields. 

Department / Department Field
This field is meant as a read-only field sourced from AD that can never be user-changed, like name or email address.  This field cannot be set to work with a term set, even if you remove the AD field import mapping.

Department / SPS-Department
This field I believe is meant to be more used and populated either by the user, or to help with classification in the taxonomy store.  This field is set to use a Term Set for it’s values.  While users can’t see field when editing their profile, an admin can see it when editing a user profile via Central Admin.  This is how the user properties from AD get pushed to terms in this term set.

Job Title

This field also has 2 properties, but they are named differently.  There’s Title and Job Title, and we’re obviously interested in the Job Title user property.  Like Department, one field by default is shown read-only on the Profile page from AD, and the SPS- version field populates the term set but is hidden everywhere.

Location

This field is way down on the property page list, under the Contact Information heading.  It’s called Office Location.  This field by default does not pull from any AD field, and is wired to populate the Location term set.  One difference is that this field IS visible on the user’s profile page, under the Contact Information section.  Notice the taxonomy control.

Making Changes

What happens if you want or need to make changes, what happens to the terms?  If we look at the Departments group I have, I renamed the term from Solution Architects to Solution Experts.  I then run a quick incremental user profile sync, and let’s check the terms again.

No change.  Hmm, what happens if we set another user with the old department name Solution Architects and run another incremental sync? 

Ah ha!  So it only pushes terms if the profile sync detects a change for the user account.  To see both properties, we look back at the user profile via Central admin:

What happens if we delete Solution Experts?  I went back to the taxonomy store, and deleted the term Solution Experts then refreshed the user profile page:

It’s gone.  I think the takeaway here is that you should decide how you want to use this field, as the source of proper Departments / Job Titles, or let AD be the source and just use the terms with some cleanup?  Do you want to allow users to edit them?  If you would want to make the taxonomy group the source instead of AD, update the SPS-Department user profile property to Export to the department AD property.

For more information on C5 Insight or this blog entry, please Contact Us.