Want the book? Go get it!
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 descending 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/SharePoint Online (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 typically was 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.
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 a the default enterprise search center in SharePoint, then all the tabs/result pages are pre-configured to use different result sources.
- Everything = Local SharePoint Results
- People = Local People Results
- Conversations = Conversations
- Videos = Local Video Results
A result source may reside 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 sources created at one particular site, is only available on that one site.
As an example a result source which limit 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 re-used 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 which 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 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 with this.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 up information, then creating a result source on the site collection level which all sub-sites re-use 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 which renders blog posts a certain way. And you might also have a result source (Blog Posts) which 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 sourceIf 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 which 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