If you are anything like me, you were waiting as impatiently for Term Stores as most children wait to wake up on Christmas morning. Managed metadata terms that support synonyms, how much better could life get? Well, in our first use of this amazing feature, we realized that like SharePoint itself, Term Stores aren’t a panacea. Just like all the other ECM objectives that we are trying to achieve in SharePoint, implementing Term Stores requires careful thought and planning.
The issue referenced by the title of this post should really be “Synonyms v. Explicit Metadata Columns”, at least with respect to my current example. We are storing documents related to the facilities we insure, and we are trying to make the process easy and have the results be useful. On the surface, these two goals would not seem to be mutually exclusive, but just below the surface, well that’s a different story. For the sake of simplicity, let’s consider that we are talking about a facility called “Pepper Hill” and it is covered by policies: 101, 104, 218 and 247. 99% of the time, when we refer to Pepper Hill, we mean policy number 101.
Managed metadata allows me to create a list of facilities that include Pepper Hill and I have the ability to say that 101, 104, 218 and 247 are synonyms of Pepper Hill. If that’s the case, why would anyone ever need to assign a Policy Number in a column? If I am looking for the actual policy, I would go to the library of policies. If I just want policy related documents, I’ll find them if I search for the policy number. But if I want documents specifically prepared for policy 218, I am going to be swimming in a sea of documents related to policy 101. In light of that last fact, you have to start looking at the likelihood of those documents being created, and the likelihood that anyone will ever want to see just those documents. If I didn’t know better, I’d say that this is starting to look like analysis. In fact, we pushed this scenario around to a point where we found a valid reason to include the explicit metadata column in addition to having the synonyms. Having the separate column enables a user to filter the list on policy number 218 if he/she is so inclined. It turns out that we have just such a user; in fact, the “user” would be our customers.
Explicit metadata, such as a required column where I have to select a value from a list, represents work for the person adding a document to the library. It is tempting, when collecting documents in an ECM process, to collect as much metadata as possible, but that is a bad idea. If you make something painful enough, people will find a way to avoid it. It is also tempting to find creative ways to have workflows do the heavy lifting with respect to metadata. I thought I had a great idea on this list, but it didn’t pan out.
Since ‘Facility’ and ‘Policy’ are both Terms in our managed term store, I want both to be set from the managed lists. But, since each term includes synonyms from the other list, I was hoping I could use a workflow to synchronize one list from the value in the other. If I type ‘Pepper’ as Facility, the Managed Metadata Column “suggests” ‘Pepper Hill’. If I type ‘101’ in that column, it also suggests ‘Pepper Hill’. I tested to see if could let someone simply enter the policy and if the workflow could resolve ‘101’ to ‘Pepper Hill’ but an error occurred. If I am going to set the value in a workflow, it seems the value needs to be a valid choice, not a synonym.
I know I can create other lists that I can do the lookup against and set the values in the related columns. I know I can buy a product that will synchronize related lists. The problem is, we need the separate Term Sets for other reasons, and I don’t want to make people maintain multiple lists that contain the same data. Now my job is to explain to this group of users why they need to set three different metadata columns when it will appear to them that only one is required – “for the greater good” – I hate those conversations.