Using a context to represent the current user in search was something that we first introduced in FAST Search for SharePoint 2010. If you're interested in how it worked back then you can take a look at this post: http://blogs.technet.com/b/speschka/archive/2009/12/09/using-custom-properties-to-create-a-fast-search-for-sharepoint-2010-user-context.aspx. In SharePoint 2013, we don't have the same exact feature, but we have to replace it is called User Segmentation. Now rather than me trying to explain User Segments, what they are, and how they work, someone on the search team has already done a bang up job of that here: http://blogs.msdn.com/b/adaptive_experiences_in_sharepoint_2013/archive/2012/11/14/set-up-user-segmentation-to-drive-adaptive-experiences-in-a-product-catalog-in-sharepoint-2013.aspx. I really encourage you to go read this blog entry, he does a great job of explaining what it is and an example of how to use it.
I'm not here to steal his thunder or take credit for it, but here's what I have done. When you read that post you'll see that it mentions having to write a custom web part to figure out any user segmentations that should be applied to the current query and then it adds them to it. In the blog it describes adding a user segmentation based on a property of the browser. What I decided to do is to write a web part that adds a user segmentation based on the current user's department. For those of you who have not heard, when you do a profile import from Active Directory in SharePoint 2013, we automatically import all of the unique Department values into a special term store. This makes it a great choice to do some customization based on the current user's department.
One question that may come up is "if I am going to present content based on a user's department, why not just use audiences?" That's a fair question, and here's the difference. With audience targeting, it's a simple on / off switch – you either show a web part or not. With user segmentation I can take that info out of the profile or anywhere else, and I can customize the content that's shown. Since I'm using a query rule, I can execute one or more additional queries for a user, I can add a promoted result, or I can even change the ranking of a query – for example if I want to target certain content to be shown higher in the search results based on the department you work in. These are just some fantastically cool features that you get with search in SharePoint 2013.
So, to help you along in using this feature, I'm just attaching my entire Visual Studio project – the compiled web part assembly, solution, and source code – for the web part that adds the current user's department to the user segmentation. After that you can do with it what you will – use it as is, or use it as the basis to refine or write your own web part for managing user segmentation. There are a couple of points I wanted to highlight about the use of user segmentation and this web part when you read the post I linked to above:
- When you create the query rule, by default it's configured to query the catalog for the publishing site. If you go with this option then you won't get any search results. Instead, choose the option to query "All Sources". The picture of the query rule configuration in the post shows this but does not call it out. Since you need to change the default behavior for this to work, I am just calling it out.
- In the post it talks about using a different web part to display the results of whatever content you are highlighting when using the user segmentation. In this case (as the post alludes to), my web part inherits from the ContentBySearchWebPart, so you can use the control both to set the user segmentation as well as to display the highlighted content. The only thing that's a little different from what's described in the post, is that when you add the web part to the page you will have one different value in the Settings property for the web part. In the Settings, just set the "Query results provided by" property to "This web part".
That's it – you are ready to go now. Hopefully you will all find some interesting scenarios for user segmentation in your searches. For my particluar scenario when I was writing this I was targeting some special training for employees that belonged to an "Executive" department. As a result when they hit the page where my web part is being used, they see this banner and link for special insider trading training that they will all have to take: