SharePoint Result Sources

Scope it out!

Mikael Svenson

by Mikael Svenson on 5/27/2014

Share this:
Print

Article Details

Date Revised:
10/22/2014


This is the fourth episode in the series “SharePoint Search Queries Explained - The Series”. See the intro post for links to all episodes.

Result sources are one of the key concepts when it comes to SharePoint search, and they are key to determining where and how a search query is to be executed. If you have previously worked with SharePoint 2010 search, start thinking about scopes and you should be on the right track. But result sources are so much more.

Result sources are used to target specific search indexes that be the local SharePoint index, an external 2013 farm or SharePoint Online instance (in hybrid scenarios), or an external source via OpenSearch. Result sources may also be used for query transformations, for example to limit results to a particular content type, which is what scopes in 2010 was typically used for.

Result sources are also used to execute searches against Exchange in eDiscovery scenarios.

Limiting a query is not all it can do; a result source can also expand the query using any KQL syntax or query variable, and you can specify how you want results to be sorted or ranked as well.

query-builder

In addition to all of the above, a result source can be used to specify a different set of credentials to use when querying that particular result source (mostly used for OpenSearch as it’s limited to basic authentication).

If you start off with the default enterprise search center in SharePoint, then all the tabs/result pages are preconfigured to use different result sources.

search-tabs

  • Everything = Local SharePoint Results
  • People = Local People Results
  • Conversations = Conversations
  • Videos = Local Video Results

The above four result sources are defined at the Search Service Application (SSA) or tenant level, and they are all limiting the results coming from the SharePoint index to display a subset.

A result source may reside in or be scoped to three different levels: the SSA, per site collection, or per site. Where you decide to create your result source depends largely on the re-use of it. A result source created at a higher level, is always accessible at a lower level. This means a result source created at the SSA level is available on any site, but a result source created at one particular site is only available on that one site.

As an example, a result source that limits the results to documents you have authored on the current site you are viewing is suitable as an SSA result source, as it can use a query variable to pick up the current site and then be reused all over the place.

SharePoint already provides such a result source named Items related to current user, which also includes list items in addition to documents.

{?path:{Scope}} {?owstaxIdMetadataAllTagsInfo:{Tag}} {?ContentTypeId:{ContentTypeId}} People:{User} (IsDocument:"True" OR contentclass:"STS_ListItem")

You should always use Result Sources

The two web parts that you will be using the most with result sources are the Content Search Web Part and the Search Result Web Part. Both of these allow you to specify a query transformation directly; so unless you are targeting an OpenSearch source, you probably have done this already. You edit the page, edit the web part, kick off the Query Builder, make your adjustments, click OK, save the web part changes, save the page, check it in, and maybe even publish and approve a new version. Then you figure out if you need to make a change, edit the page, edit the web part, kick off the Query Builder, make your adjustments once more, click OK, save the web part changes, save the page, check it in… phew! A few more iterations of this, and you see where I’m heading.

If you instead create a result source and hook your web part up to that source, you only need to save the web part and the page once! All further changes are achieved at the result source instead. Edit result source, kick off Query Builder, click OK, click Save. Wait 5-10 seconds, refresh your page and you can see your changes live and clear!

If you create web templates which you use search to surface information, then creating a result source on the site collection level which all subsites reuse is an excellent use case.

A use case for a site scoped result source could be a user creating a new page and wanting to administer what is displayed without having to do the page edit dance (provided the user has site administrative rights).

All the samples from earlier in this series are suitable to be used in a Result Source, and remember to name your result sources with meaningful names!

Query rules

Result sources also closely relates to query rules, where a particular rule will change a query. You can, as with the web parts, change the query in the query rule itself, but hooking them up with well-named result sources might work just as well and allows you to separate rule logic from what is displayed. The usage of query rules will be covered later in this series.

Off track – Display Templates

This is a bit outside the scope of this series, but important to mention. If you create custom display templates, you often hook them up to custom Result Types. For example, you might create a display template that renders blog posts a certain way. And you might also have a result source (Blog Posts) that limits results to blog posts only. In the Result Type, you may then set a matching condition to use this result type/display template for items coming from that particular result source

result-type

If you are mixing up results and are using custom managed properties in your Display Templates, this is the only sure way I've come across that will make sure all properties are working for all display usages of a result type that be in the main results or in a result block.

References


Topic: Search

Sign in with

Or register