Most of the times, people will use SharePoint Search straight out of the box. And this might be fine. SharePoint Search is very powerful and can be all you need to get your work done. But when managed metadata and SharePoint Search are working together, you can really create some powerful solutions. And in this post, I want to show you one example.
When set-up and managed correctly, the SharePoint managed metadata service (MMS) is a must-have in enterprise content management environment. One of the functions the MMS offers is an out-of-the-box taxonomy. Granted, it isn’t perfect. But you do get a manageable and multilingual environment for managing metadata.
Generally, this taxonomy is set-up using term groups, term sets and the terms themselves. These terms can even have synonyms attached. Terms can be reused, deactivated or deleted all together.
Let’s take this taxonomy (or term group within a taxonomy) as an example. It’s very basic (and in Dutch!), but I want to show you some things regarding the “Projecten”(English: Projects) part of this tree.
Searching content using the taxonomy
Let’s just say that I have a document library. This document library is very simple. But I do have two custom columns. One column is called Projectfase and is used to denote the state of the document in relation to the project. The other is called Productsoort and details the type of document. Both columns are stored within the Projecten branch of my taxonomy, but are different branches themselves (see the previous picture).
These columns are, of course, of the managed metadata variety and are linked directly to the terms in the taxonomy. Let’s assume that I’m using this kind of library throughout a number of site(collections). For example, in specific site-templates I use for project management.
People from the Project Management Office come to my door regularly to ask if there are ways to aggregate all documents related to the Execution phase of all projects. Anticipating such a question, I have already added the Projectfase column as a managed property, connected to the crawled property.
So, the people from PMO can easily search using the column itself. And this works of course.
But wait one second!!
Ok, this will work. And this can be explained to our users. But what if we were to use such a query in a custom search webpage? For example, a specific search webpage intended for the PMO people, to aggregate documents based on Projectfase? That should work as well, right?
Yes, it will. But what if someone changes the value of the metadata? What if Execution is going to be changed to Executing? What if I want to search on one of the synonyms of the term? What if I want to have all content aggregated based on this column? For example: all documents that have a value from the Projectfase term in the taxonomy.
In these cases, you might want to create a query based on some unique value which identifies the term…… And this is the term-id.
You can create a query to show you all content connected to one term-id, or you can ask SharePoint to aggregate all content based on a certain starting point in your term hierarchy.
Term-ids and using them.
Every term in the managed metadata services has a unique id. And we can use this id to create specific search queries. These ids can be found using the term store administration page. On the detail page of a term, the unique id is found. For example:
In my example, these are the ids used:
|Term set “Generiek”||a3f71668-d910-4d5e-8390-20d7287d0b6e|
To create a query which will return content based on a term, you can use the following commands.
|GP0|#<term id>||Returns all items tagged with that term|
|GPP|#<term id>||Returns all items tagged with all childs of the term|
|GTSet|#<term set id>||Returns all items tagged with a term from the term set|
You can of course combine these commands.
And do please take note of the 0 (zero) in de GP0. It took me some time to realize that this wasn’t an O(scar).
Let’s look at some example. Let’s say, I want to retrieve all content which has been tagged with a term in the “Projecten” branch. So, that would mean five documents. I have one document which uses the Productsoorten term and four documents using the Projectfase term. Let’s see.
Well, there you have it. Works like a charm. I’ve added the Projectfase term-ids and terms as a refiner. Just for this demo. Which is also nice. You can query all content and have the terms added as refiners. Of course, you will only need to have the readable version there…
Let’s search again, but only on documents within the Projectfase part of our taxonomy. I should expect there to be four documents.
Now the ultimate test. Let’s find those documents related to the Execution phase of a project. I’ll use the term id for that value. And, voila.
In the end
SharePoint search is (in my opinion) sometime underrated and/or underestimated. It is however, very powerful. If set-up and maintained correctly, that is.