I’ve done programming in a variety of environments over the years. Case sensitivity was one of the things that was the most difficult for me to get used to when I moved from VB to C# a number of years ago. In fact if it weren’t for Intellisense I would probably still be swearing at C# on a regular basis. I’ve learned to live with, and even make use of, case sensitivity in my C# programs over the years. But it doesn’t come naturally. I still tend to think in a case insensitive fashion.
As a result I was somewhat surprised to run into someone having an issue recently when trying to add SharePoint Managed Metadata terms to a user profile programmatically. They reported that SharePoint wasn’t consistent when adding terms to the Ask me About profile field programmatically. It turns out that the real problem was that they had duplicate fields where the only difference was the case of the first character of the abbreviation. After some investigation here’s what I discovered.
- SharePoint won’t let you add two metadata terms under the same parent if the only thing that differs is the case sensitivity of the term. The image below shows what happens if you try to add “ABC” as a term when “Abc” already exists under the same parent term.
- You can add (but probably shouldn’t) a term that differs only based on case sensitivity if you also change the hierarchy that the term inherits from. The image below shows the same “ABC” term added to a different parent. This time the addition is successful.
- When you try to add any combination that starts with abc to a managed metadata column you get both terms. You can of course choose the one you actually want, but that’s based on the hierarchy of the term, not its case sensitivity.
The lesson here is that unlike some things like C#, the Managed Metadata service is NOT case sensitive. You should try to avoid adding terms to the service that differ only based on case sensitivity. This is particularly true if you intend to add managed metadata to fields programmatically.