How To Customize SharePoint 2013 Search Results Using Query Rules and Result Sources

Artikel
02/01/2013

Summary: Brendan Griffin, Microsoft Certified Master (SharePoint 2010) and Senior Microsoft Premier Field Engineer based in the UK, provides us with details on working with SharePoint 2013 Search. As you may (or may not) know, SharePoint 2013 search has changed quite dramatically from previous versions both from a functionality and manageability perspective – as Brendan mentions: all for the better, of course! Enjoy!

SharePoint 2013 brings together the power of FAST Search with the simplicity and management of SharePoint 2010 search. SharePoint 2013 is the first release of SharePoint to fully integrate FAST Search into the core product, as a result of this search has changed quite dramatically both from a functionality and manageability perspective – all for the better, of course!

The aim of this post is to provide insight into Query Rules and Results sources. Some of the functionality provided by these features may sound familiar as previous releases of the product did include some of this functionality; however, as you will see, SharePoint 2013 takes this to the next level.

Query Rules

Let’s get started with Query Rules, in prior releases of the product it wasn’t really possible to do much with an end user search query. Sure, SharePoint found what it thought was relevant and provided search results to the user, but sometimes it would have been great to tune search results based upon the intent of the query that the user submitted, essentially providing the ability to influence search results. For example, when a user performs a query for “product ABC” it may be desirable to promote results for marketing material for the product.

Query Rules can be created at the Search Service Application, Tenant, Site Collection or Site level, as follows:

Site

Site Collection

Search Service Application

Tenant

Query rules are composed of three components:

Condition – When to apply the rule?
Action – What to do when the rule is matched?
Publishing – When should the rule be active?

Conditions

Conditions determine when the rule should apply; there are six different types of conditions that are available. Full details of all of the conditions can be found here – Managing Query Rules in SharePoint 2013.

Here are examples of how three of these conditions can be used:

Query Matches Keyword Exactly – If you need the query rule to apply when a specific query is performed, this is the condition to use. In the example below the query rule will apply when a query for “widget” is performed

Query Contains Action Term – An action term is basically a trigger word, this rule will apply when the query contains the action term specified, either at the beginning or the end of the query. In the example below the action term is “human resources,” therefore queries for either “human resources contacts” or “contacts for human resources” will cause the rule to apply however a query for “human resources” would not.

It’s also possible to configure this condition to use a term set rather than specifying each action term within the rule itself. This is really useful if you have a large number of action words, for example a list of products: instead manually typing in each product -- which wouldn’t be fun -- the rule could use a term set that contained product names. An added benefit of this is that when a new product is introduced you wouldn’t need to edit the query rule, as the action term is contained in a term set it’s a simple as updating the term set.

One thing to point out: search checks the dictionary every 30 minutes for updates so changes to the term set will not be reflected in the query rule straightaway.

Query Matches Dictionary Exactly

This is basically the same as Query Matches Keyword Exactly, however, instead of manually specifying one or more keywords this rule is configured to use a specific term set, any values within the specified term set will cause the rule to apply. In the example below, the Customers term set has been used, this contains three terms – Litware, Contoso and Adventure Works. Therefore a query for any of these customers would cause the rule to apply.

Actions

Once the condition has been configured the fun begins! The next step is to decide what to do when the query rule applies. Essentially there are three options here:

Add Promoted Result
Add Result Block
Change ranked results by changing the query

Here’s some drill-down on each of these options:

Add Promoted Result – A promoted result is a result that appears at the top of the search results, this is particularly useful way to promote a particular search result. For example, you may want a query for “human resources info” to promote a link to the human resources SharePoint Site.

For those of you familiar with previous versions of SharePoint this is a “Best Bet.” When a promoted result is added three pieces of information are required: a title, URL and description.

Here is an example of how this would look to an end user.

As you may have seen from the screenshots above it’s also possible to render the URL as a banner instead of presenting a link. This could be useful in an Intranet scenario, for example when a user searches for “London office” a banner is displayed that provides the address and telephone number of the London office. It’s a quick and easy way to present users with the information they are searching for. For those familiar with FAST this functionality was known as a Visual Best Bet.

Add Result Block – A result block is a selection of results that are integrated into the core search results. The interesting thing about a result block is that the results don’t necessarily need to come from the local search index! A result block uses a result source, which can be one of the following:

Local SharePoint farm

Remote SharePoint farm

OpenSearch

Exchange

As well as providing access to search results both inside and outside of SharePoint (for example Exchange), a result source can also be used to narrow down the content returned. For those of you who have worked with previous versions of SharePoint, search scopes and federated locations have evolved into result sources. A number of result sources are available out of the box, such as Documents, which returns all files which match the following file types from the local SharePoint index - DOC, DOCX, XLS, XLSX, PPT, PPTX or PDF.

A result source could be configured using OpenSearch to return results from Bing within the standard search results from the local SharePoint index. In the example below, the queries for “legislative codes” have been configured to add a result block that uses the Bing result source.

The result block itself can be shown at the top of search results (as above) or can be ranked within the core results – this may mean that the result block doesn’t display as it will be ranked like all other results. One thing to point out is that the result block is ranked as a whole rather than each link within the result block having a separate ranking.

Additional configuration options include the ability to select the number of links to show in the result block and also to display a “Show More” link to obtain further results from the source. In this example the more results link would open Bing and perform the same query.

MOSS 2007 and SharePoint 2010 did include similar functionality using the “Federated Results Web Part,” however this didn’t provide the ability to present results within the core search results, and results were presented in a separate Web Part which wasn’t aesthetically pleasing or user friendly.

Change ranked results by changing the query – This is where you have ultimate power to change the way in which a query is handled by SharePoint. The Query Builder tool provides the ability to supplement a query with additional keyword or managed property restrictions. For example, a query with the action word “contract” such as “sales contract” could be configured to only return Word documents using the action term “contract” as the keyword filter and the managed property filetype=DOCX. This is a fantastic way to tune search results, either based upon user feedback or analysis or the out of the box Search Usage Reports, more information on which can be found here - View search diagnostics in SharePoint Server 2013

Below are the subsequent search results for “sales contract”

As you can see this is a very powerful tool, but with great power comes great responsibility so caution is always advised when using this functionality.

Publishing

Last but not least, the final decision is when to make the rules active. The default setting will make the rule active until such a time that it is manually deactivated, however it’s also possible to control when a rule is active using a schedule.

This could be really useful when a query rule only needs to be active for a set period of time, for example an e-commerce site could have a query rule in place for the term “sales” that only needs to be active for a short period of time, such as the holiday period. From an Intranet perspective this could be a query rule for “performance review” that’s only active whilst a performance review cycle is in place – as with most things in SharePoint the possibilities are endless!

Summary

As mentioned earlier in the article query rules can be configured at multiple levels and are inherited by default, therefore a query rule created at the Search Service Application level will be inherited by all Site Collections, and rules created at the Site Collection level will be inherited by all Sites within the Site Collection. It’s possible to deactivate an inherited rule at any scope if required, for example when an inherited rule causes un-desired results due to a clash with a rule that has been created at the Site level.

One final point to be aware of - If multiple query rules are in place there is a chance that more than one will apply to a given query, this poses a potential challenge as there isn’t a prescribed order that the rules will execute unless a custom group is used to organise the query rules. The process is documented here – Section - To rank query rules for a site collection

Well that’s it for this short overview on Query Rules and Result Sources, I’m sure you will agree these two new features provide some great opportunities for tuning search to meet your specific requirements.

Posted by Frank Battiston , MSPFE Editor

Comments

Anonymous
January 01, 2003
l
Anonymous
January 01, 2003
Great posting. Thanks for putting it together.
Anonymous
July 08, 2013
I just want to do a title boost in my SharePoint 2013 Search. Best way? Sample code? Much appreciated Cheers, David
Anonymous
November 26, 2013
How can I deploy a custom result block; It seems the ResultBlockData class is internal?
Anonymous
March 03, 2014
it was good one and informative.http://staygreenacademy.com" >
Rozeena
Anonymous
April 17, 2014
Thanks Frank. A comprehensive tutorial.
Anonymous
June 05, 2014
Pingback from SharePoint 2013 Search : search list item only | SharePoint Q&A
Anonymous
June 09, 2014
The comment has been removed
Anonymous
July 10, 2014
Query Matches Dictionary Exactly does not work for terms composed of multiple words.
For example, Match never occurs with "Adventure Works". Is there any special syntax ?
Anonymous
November 01, 2016
thank you for your useful post,will this rule take effect directly or we need to run a crawl or any timer job?
Anonymous
January 12, 2017
HiI am trying to use the query rule with FQL and it's not working...Someone have a clue on the reason why. It seems that the steps was not made to evaluate if a query rule can be applied or not.Francis
Anonymous
March 07, 2017
My concern is, Is this possible to bring the people search results page in between the everything search results page?I ask this questions to Stackoverflow, no one answer this question, http://stackoverflow.com/questions/42631481/how-to-bring-local-people-results-in-between-local-sharepoint-results-in-sharepoPlease let me know anyone who aware of this?

Freigeben über