We all know that the SharePoint search engine is very powerful and Search has been a key feature for many years. SharePoint Search provides a fast and user-friendly way to retrieve information or documents. You just enter a keyword into the search box and click 'Search' – it's as easy as that. Almost instantly the results are displayed and can be improved by simply clicking on provided refiners. That provides a very convenient way to search your SharePoint content.
Sometimes users require a more streamlined way of finding content that would be less flexible, but provide a faster way to their results. This can be achieved by creating a specific Result Source. In one of my recent projects there has been a requirement to have an additional search box placed on the homepage of a site. This additional search box should retrieve documents of a specific type found in the current site and its sub-sites only.
In this blog post I will show you how to create and use a Result Source in SharePoint 2013 to achieve a more targeted search experience.
Let's assume there is a site collection that is used to save client related documents like letters, offers, contracts or client-specific presentations. For our example, the site collection will look like this:
There is a welcome page that provides access to the client workspace and there are three sub-sites for three fictitious clients named 'Client ABC', 'Client DEF' and 'Client XYZ'.
To ensure the same "look and feel" and the inclusion of a Presentations library, a custom site template was used to create each of these client sub-sites. Additionally, the Presentations library uses a content type for client-related documents and a managed metadata field called 'Document Type' that allows for easy tagging of documents. A document was added to each library called 'Company Presentation' and was tagged with the document type "Presentation" as shown below:
I wanted to provide a way to search through all client presentations that are saved to the sub-sites of the client workspaces. In SharePoint 2010 you could use a Search Scope to achieve this. In SharePoint 2013 Search Scopes are deprecated, but can still be used (but not created), so I used a new Result Source for this. SharePoint 2013 already provides 16 preconfigured result sources which are available in all sites, site collections and the web applications that use the Search service application. The main difference between a Search Scope in SharePoint 2010 and a Result Source in SharePoint 2013 is as follows:
- A Search Scope defines a subset in the search index and search results are retrieved by restricting the index.
- A SharePoint 2013 Result Source is a provider to get search results from. Also, search results can optionally be narrowed to a subset of the results provided by a Result Source.
- In SharePoint 2010 only two system search scopes are left: 'All sites' and 'People'.
To be able to create a new Result Source, a managed property needs to be created first. Because I created the 'Document Type' based on a managed metadata saved to the Term Store there will already be a managed property of the same name after an incremental run of the crawler.
I create a new Managed Property manually and give it the name 'Document Type'. Obviously it is of type 'Text'.
ensure that this new property can be used, it was also configured to be searchable,
queryable and retrievable. This ensures
that this new property can be used in search terms and as a search results
Finally, this new managed property needs to be linked to the crawled property.
to be sure, I did a full crawl now before continuing with creating the new
Result Source. Because my client sites are sub-sites to the client workspace, I
open the site-collection settings and click on ‘Search Result Sources’
Result Sources can be created for a single site, a site collection or even a Search Service Application. For my example, I'll stick to the site collection. I create a new Result Source and name it 'Presentations', I then select 'Local SharePoint' as the protocol and 'SharePoint Search Results' as a type. Now I scroll down and click on the button 'Launch Query Builder'.
One thing I love with SharePoint 2013 are the little embedded helpers, like this one. The following screenshot shows my query configuration which isn't too complex:
The only thing I need to do here is add a new filter based on the DocumentType property. As property filters leverage the search managed properties, I need to create a managed property called 'DocumentType' first. The search results preview displayed on the right is based on the current query. The preview looks fine and shows all of my demo documents so I click OK to save the current query settings.
One of the requirements are that the search results based on this result source should not be displayed in the global Search Center, they should only be displayed on a search results page that is local to the client workspace. To do that, I need to create a site collection specific results page and I continue with creating a new page in the client workspace, which will then become the new local search results page.
Once the new page is created, I add a Search Results web part to the page. This web part will be configured to display search results based on the newly created result source, it needs to be configured properly. I open the web part properties and click 'Change query'. In the 'Build Your Query' dialog I only need to change the query's result source to 'Presentations'. As you can see it is very easy to reuse a predefined Result Source.
The next step is to add an additional Search Box to the home page of the top level site. This additional search box is used to enable users to search specifically for presentations in the sub-sites of this client workspace. With this approach there will be 2 search boxes, which might be confusing at first glance, but this approach does not have any impact on the existing search environment as the additional search box is utilized by the members of the client workspace only.
This is how the home page of the top level site looks like now:
The additional search box only needs to know where the results page is located. So I just need to change the following setting for the web part to redirect the queries to the local results page that I had just created.
Let's assume a sales representative is looking for the slides he or she presented at client XYZ because these slides can be reused and updated to be presented to a new client. All that is needed to achieve this is to enter the original client's name "XYZ" in the local search box and click the search button. This is what the search results look like in my example:
The expected result is that the local search results page now only shows one single result as there is only one document that is tagged with 'Presentation' that is related to client 'XYZ'.
The global search is still working as expected because I did not change any settings here. If the sales representative had used the global search box, the results would be displayed in the global search center like this:
This is the standard search results page in my demo environment and it shows that there are more presentations (or even sites and pages) that somehow are related to 'XYZ'. In my simple example, I have added another document (basically a presentation with "This is my company" on the first slide) to a sub-site of another site-collection to show the difference to the local results page more clearly.
You can also use a custom result source as a new search vertical in the global Search center. You may have noticed the standard result sources of a search center in the above screenshot. The standard result sources used by a global search center are these:
To add a custom result source to the standard result sources of a global search center you would most likely choose a similar approach like I did. Navigate to the standard Search center and add a new page (just like I have done with the local search results page). You need to change the configuration of the search results web part on the new page just like I did before. Unfortunately this isn't enough to show the custom result source among the standard result sources of a SharePoint Search Center. The result sources in the screenshot shown above are nothing more than links to pages with search results web parts similar to the one I have created before. The link to the newly created page needs to be added to the existing links of the standard pages. To do this, open the site settings of the global Search Center and click on 'Search Settings' under 'Search'. If you scroll down to Search Navigation you should see the standard pages look like this:
To illustrate the addition of a new page to the global Search Center, I now add a custom search results page (created before and named "Custom") to the existing pages.
After I saved the changes and navigated back to the global Search Center, I enter "XYZ" again to the search box and this is what I see now:
newly created page (I named it “Custom”) has been added to the standard result
source pages of a global Search center just as expected. To get rid of ellipses
(“…”) that might appear in your environment, just open the web part properties
of the search navigation web part and increase ‘Maximum Links before Overflow’
If you enable 'Turn on the drop down' in the search box web part's properties, the result source pages are listed this way:
Result Sources introduced to SharePoint 2013 are a powerful new feature because they don't restrict the existing index to display search results. In fact, they add a new provider to SharePoint Search which is a far more powerful approach used to enhance the user's search experience in SharePoint greatly. Although this is just a simple example on how to use Result Sources it shows obvious benefits for the User Experience. To me, as a SharePoint consultant, a user experience that truly reflects the users' needs is as important as the functionality of a SharePoint farm. In this case of using custom result sources, simplicity of finding information on your SharePoint platform can even be achieved without a single line of code – and that's true for Office 365 as well.