Integrating People Metadata In Content Searches Using Query Rules in SharePoint 2013
Okay, that’s admittedly kind of a long goofy title, so what is Steve talking about here? Well, let me phrase it this way – a few days ago I saw a question flying around that went something like this: I have folks that work for different departments in my organization, like Sales, Finance, etc. When someone types in a query for something like “sales management pitch” then I would like to be able to also have it show people that work in the Sales department. Okay, sounds like a pretty cool use of the new Query Rules feature in SharePoint 2013.
To start with, let’s take a step back and look at a related enabling feature we’re going to use here. In SharePoint 2013, when you do a profile import from Active Directory it automatically populates a special termset in the Managed Metadata Service. In fact, it actually creates a master group called “People” and populates three termsets: Department, Job Title and Location (NOTE: I can’t guarantee that all three of these will still be there when the product ships, it may only end up being two of these). During the profile import process each term set will be populated with the unique values across all users for each of those properties. This really helps out a lot for this problem, because when I look at my MMS, I see that in my list of Departments it includes “Sales”, since I have users with that value in their Department attribute in AD:
Okay, that’s great, so now let’s go and create a query rule. As I mentioned in my first post on query rules (https://blogs.technet.com/b/speschka/archive/2012/07/23/using-query-rules-result-types-and-display-templates-for-a-custom-search-sales-report-in-sharepoint-2013.aspx), the first thing we’re going to do is set the condition when my rule should fire. In this case we’re going to use the Advanced Query Text Match option, and choose the last selection, which is Query contains an entry in this dictionary: . Now it has a drop down selector, which is unfortunate because it’s a little misleading. Really what we want to do here is click the Import from taxonomy link that’s directly below it. When we do that we’ll see a standard MMS picker, and so I just expand my local MMS instance and click the Department termset, because I want my rule to fire when the query text contains a word that is a Department in my organization.
For the next part of my rule, I check all three checkboxes for looking at the query terms. So if an entire query equals a Department name, or if the query starts with or ends with the name of a Department, then I want my rule to fire. Finally, for the last part of the rule configuration, if there is a match then I want to assign the match to {subjectTerms}, and the remaining terms to {actionTerms}. So if we use the example above of searching for “sales management pitch”, then since the query terms starts with “sales”, which is a valid Department value in MMS, my query rule should match - "sales" will be the {subjectTerms} and "management pitch" will be the {actionTerms}. Here’s what that configuration looks like:
Now when my rule fires, I want to add some folks from the Sales Department to the top of the query results. So I start working on the next part of my query rule, which is the action I’m going to take. I click on the Add Result Block link and open up that dialog. In this case I want to add a Result Block that will display people results, so the first thing I do is click on the Search this Source drop down and change it from Query’s orginal source to Local People Results (System) . I do this first so the query builder will use that source when I modify and test the query. With that done, based on my matching rule I know that whatever Department has been found will be in the special term “{subjectTerms}”. In order to use that, I click the Launch Query Builder button so that I can modify the query. I delete any existing text that’s in the Query text edit area, and then click on the Property filter drop down and click on the --Show All Managed Properties—option. That repopulates the drop down with all the managed properties, and from that list I select Department. In the qualifier drop down I change it from “Contains” to “Equals”, and then in the Select value drop down I choose {subjectTerms} – the matched dictionary entry from Department and then click the Add property filter button. This is what it looks like:
This is shaping up pretty nicely. Now I want to add a more personal touch to it, and to do that I click on the Sorting tab in the query builder. In this case instead of just using the default sorting model, since I’m going to be showing people I’m going to sort by social distance. So not only will I show people in the results, but the list of people will be ordered based on which ones are closest to me in social distance. To do that I just use the Ranking Model drop down and select People Search Social Distance Model, like this:
Now I can click on the Test tab and try out my new query. By default you should see zero results, and that’s because it doesn’t have a value for the {subjectTerms} variable. To test it out with real query criteria click on the Show More link and then type in sales in the {subjectTerms}*: edit box and then click on the Test query button. I try this with different ranking models to make sure that it’s all working as desired – it is – so I click the OK button to save my query changes.
Now the last thing I want to do for my query rule is display a link at the bottom of my block that someone can click on to find all people that work whatever Department was found. Before I go any further on that I’m going to tell you something in the interest of full disclosure – I have a picture that I will show in a bit of the final results, and you will see a SHOW MORE link. For this particular post, I actually combined two pictures – one that had the “SHOW MORE” link and one that did not. The reason for that is because the “SHOW MORE” link functionality is working inconsistently in beta 2. All the kinks should be worked out by RTM but for now sometimes it shows up for me, but more often it does not. I just happened to grab a screenshot on an early set of results I was working on that included it. I mention that here so that you don’t become overly frustrated if you are working on beta 2 bits and find that sometimes it shows up and sometimes it doesn’t.
That being said…in order to implement this functionality that I described in the previous paragraph, I select the option of “More” link goes to the following URL and typed in the following: peopleresults.aspx?k=Department:{subjectTerms} . I also decide to show three matches, and as described above, have them show up at the top of all the search results. So now my complete Result Block dialog looks like this:
Now that it’s done I can go test it out. So I do a query for “sales management pitch” and here’s what my results look like:
(Note that this is where you see the “SHOW MORE” link I had to paste in at this point). What is kind of cool is that Rocky shows up in the top of the search results because in my organization I am his Manager, so we see the social distance ranking algorithm at work. If I hover over any of the people in the results then I can see a list of documents that they’ve recently published:
Finally, when I do click on the SHOW MORE link it takes me to the people search results page, and I’ll see all people that work in the Sales department; when I hover over any one of them I can see what they’ve done, see their profile page, etc.
So that concludes our exercise. We took a very real customer requirement, and we used the new query rules and profile import features in SharePoint 2013 to create a solution that required no coding at all, and provides a LOT of functionality. I hope you’ll continue to look at and work with query rules.
Integrating People Metadata In Content Searches Using Query Rules in SharePoint 2013.docx
Comments
- Anonymous
January 01, 2003
The comment has been removed - Anonymous
May 15, 2014
Pingback from Integrating People Metadata In Content Searches... - Anonymous
May 21, 2014
Pingback from Integrating People Metadata In Content Searches... - Anonymous
September 18, 2014
The comment has been removed