SharePoint search is awesome. It gives you the ability to search content inside of SharePoint, as well as outside of it. Plus, it gives you the ability to search for other employees in your organization. And quite easily!
Though, what it also gives you is a window into your organization’s disorganization. How many times have you taken a look into Active Directory only to find that users have job titles like “Mgr”, “Manager”, “Senior Manager”, etc.? One person’s naming convention is rarely ever exactly like someone else’s.
Now what happens if users actually want to refine these results. Say they want to pull back a list of all managers. They’d need to create a query similar to this:
Not very intuitive, is it?
Another option is to go back to your IT department and ask them to standardize this naming convention. Which wouldn’t be that difficult of a task for them, except they are already over worked and don’t really have time for another non-mission critical task.
So what does that leave? How about trying out a custom entity extractor? What is that you say? A custom entity extractor is a keyword mapping for a managed property, allowing you to customize the search refiner. In laymen’s terms, it’s a way for us to map our unstructured data (Mgr, Manager, Senior Manager) into a single term (Manager). Which allows you to add it as a search refiner so you can easily filter on just the “Managers”.
For our tutorial, I’m going to use baseball as an example. Our people search returns the following players.
Each player has a unique job title, “Designated Hitter”, “Right Field”, and “Second Base”. We want to search for these players by “Infield” or “Outfield”. This would be akin to having “Mgr” / “Manager” / “Senior Manager” as job titles and wanting to filter by just “Manager” or “Partner”.
Create the Custom Extraction Dictionary
First we need to create our Custom Extraction Dictionary. This a comma separated (CSV) file which will define our mappings. I’m going to name this PositionsDictionary.csv and have all the infield positions map to “Infield” and all the outfield positions map to “Outfield”.
Import the Dictionary
Next we will need import the dictionary into our search application. Here is where we need to decided what type of extract it is. Should “First Base” match exactly to our values in AD, or should it just match part of it, and is it case sensitive? You can view the different types over on TechNet. For this example we will be using the Word Extraction type which is case-insensitive and matches the full word exactly. Run the following PowerShell cmdlet as an administrator on your SharePoint box:
|$searchApp = Get-SPEnterpriseSearchServiceApplication
Import-SPEnterpriseSearchCustomExtractionDictionary -SearchApplication $searchApp
The FileName argument needs to be a UNC path. The DictionaryName argument needs to be exactly whats defined on TechNet (if you follow the link above). And if done correctly you will see a “Dictionary imported successfully”.
Map the Property
We now have to link our dictionary / mappings to the Job Title managed property. To do this, head over to the Search Service Application in Central Administration. Click on “Search Schema” link in the left navigation, which is found under “Queries and Results”, and search for the managed property “JobTitle”, and click on it to edit it. Then scroll down to the “Custom Entity Extraction” section.
This is where we need to link our managed property to the dictionary. Since we used the first Word Extraction dictionary, we need to check it off. If you used a different one, you will need to choose that one instead. Click “Ok”, and run a full crawl.
Add the refiner
Since we cannot change the default People Search page, I’ve created an exact replica of the People Search page in my Search Center, and changed the “People” link to that new page. The only difference, is that in my refinement webpart, I used “WordCustomRefiner1” instead of “JobTitle”, which I also gave it Display Name of “Job Title” just like the actual JobTitle managed property.
Click “Ok” and Save / Check In / Publish the People Search page.
Now to test it out. If we do our search again, you can see that we just have two different job titles, “Infield” and “Outfield”. Which we can refine our results based on that.
And just like that, we’ve managed to filter our employees exactly as we desired without updating Active Directory or bothering IT.