Although SharePoint Online (which is an integral part of Office 365) and SharePoint on-premises (SharePoint 2013) provide a very similar -almost identical- user interface, there are key differences that one should be aware of when executing configuration tasks. Most of these differences exist because SharePoint Online resides in a hosted environment beside other SharePoint online tenants and each of these tenants needs to be protected against any kind of interference from other tenants. The classic example to illustrate this is timer jobs. For both SharePoint Online and SharePoint on-premises, timer jobs are acting on a farm-wide (global) scope. There is currently no way to restrict them on a single site collection nor on a single tenant. Which is why Microsoft has removed access to timer jobs and their configuration from every administration page in SharePoint Online.
Another restriction applies to the configuration of search refiners, but before I deep dive into that, I would like to provide a short introduction to the benefits of search refiners. If you look at a standard SharePoint search center in SharePoint Online, it will most likely look like this:
In the search results (the large column on the right in the screenshot shown above) you currently see that there are two search results based on my simple query. In the above screenshot, I’m looking for documents with the name ‘Demo’ and SharePoint Online returns the documents I created only minutes before. But when you have a look on the left column you’ll notice the standard search refiners ‘Result type’, ‘Author’ and ‘Modified date’. These refiners allow to quickly filter the search results. Let’s have a closer look at these refiners now. If you look at the refiner ‘Result type’ it shows that there are a Word document and an Excel spreadsheet. If I was interested in Word documents, I could click on the refiner ‘Word’ and the search results would only show Word documents that match my current query.
With standard refiners, a user is able to perform a basic filtering, but wouldn’t it be a signification increase in user-experience to provide more refiners? Maybe even refiners based on custom properties? In this post, I’d like to show you how one can configure additional refiners in a search center SharePoint Online – a considerable difference on how you would configure custom search refiners in SharePoint on-premises.
To be able to provide additional custom search refiners in a Search Center, you’ll first need to create them – done exactly the same way you would in SharePoint on-premises, but with one major difference! I’ll cover the difference soon, but first let’s start with creating a content type, adding at least one managed property based on a term set to the content type and configuring a SharePoint library to leverage this content type. In my demo, I’ve done it exactly like this. I created a content type named ‘Demo Document’ and added a managed property ‘Document Type’ to it.
After I created the content type, I added this content type to a library and added two documents to that library as well – the Word document and the Excel spreadsheet you just saw in the first screenshot. I used different values for ‘Document Type’ respectively because I’d like to use ‘Document Type’ as an additional search refiner. The next screenshot shows the library with the two documents:
Just like in SharePoint on-premises, the next step is to create a crawled property from the content type property, ‘Document Type’. This is usually done by the SharePoint indexer upon its next crawl. Unfortunately, you can’t trigger a crawl manually in SharePoint Online like you can with SharePoint on-premises, but you can instruct SharePoint Online to trigger a crawl. To do so, look for ‘Search’ settings and click on ‘Search and offline availability’. A new page should show up now and you should see a button labeled ‘Reindex site’. Similar to re-indexing a site you can also trigger SharePoint Online to re-index a library or a list.
After a few minutes, SharePoint Online has probably updated its index. To verify that there is a new crawled property, I navigate to the SharePoint Online Admin Center and click on ‘Search’. In the search administration, I now click on ‘Manage Search Schema’. Next, I click on ‘Crawled Properties’ and search for a crawled property with the name ‘Document Type’.
SharePoint usually creates three crawled properties, if the crawler becomes aware of a new property. In my demo, these are the crawled properties that SharePoint Online created:
- Document Type
- ows_Document_x0020_Type
- ows_taxId_Document_x0020_Type
The second crawled property (ows_Document_x0020_Type) holds all property values that the crawler found. In my demo, these are ‘Draft’ and ‘Confidential’. This is the crawled property you would most likely use for custom search refiners. The crawled property beginning with ‘ows_taxId’ shows that the corresponding values are read from the term store. It holds their internal values and will usually look like this: GTSet|#fe2f50b0-8ca7-4ee4-9e3c-7f3b08dc16e4.
Looks like the crawler has created some crawled properties, but it has not assigned them to a managed property yet. In SharePoint on-premises you would now start to create a new managed property and map it to the crawled property. If you tried this with SharePoint Online, you would fail. I will show you why…
First, I create a new managed property manually – just like you probably would for SharePoint on-premises. Obviously, this property is of type ‘Text’.
To be able to use this new managed property as an additional custom search refiner, I need to switch the ‘Refinable:’ setting to ‘True’. Unfortunately, this setting is read-only and this is true for ‘Sortable:’ and ‘Allow multiple values:’ as well. There is no way to enable these settings!
In SharePoint on-premises these properties are editable, but there is a workaround to create refinable managed properties in SharePoint Online – a key difference for SharePoint on-premises. Let’s forget about creating a managed property manually and navigate back to the list of existing managed properties. If you look at the list closely, you will notice there are a lot of predefined managed properties of different types with names beginning with ‘Refinable???’. The following screenshots show some of the predefined ‘string’ typed properties. As you can see these managed properties are not mapped to any crawled property, which means they are ‘unused’.
Out-of-the-box there should be these predefined refinable managed properties available in SharePoint online:
As these predefined managed properties are not mapped to crawled properties, we can use it for our own purposes. I choose the first property ‘RefinableString00’ and map it to the newly created crawled property (remember to use the one beginning with ‘ows_???’) like this:
I also added an alias before I finally click on ‘OK’. Let me just recap this important step: Unlike SharePoint on-premises you can’t create refinable managed properties in SharePoint Online manually. Instead, you need to take one of the predefined managed properties and add the mapping to the corresponding crawled property manually!
Let’s have a look at how to create a new custom search refiner based on the managed property that I have just created. To do this I navigate back to the search results page of my search center and turn the search results page named ‘Everything’ into ‘Edit’ mode. On the left of the page, I click on the refiner web part to show its web part properties. In the web part properties, I click on ‘Choose Refiners…’
Although my edited managed property ‘RefinableString00’ shows up in the list of managed properties, it may take some time until real values are shown. To my knowledge there is no way to speed up that process – you just have to be patient and wait for SharePoint Online to be able to provide the refiner values.
If after some time refiner values finally show up, I can add the new refiner above the standard refiner ‘Modified date’. Because I don’t want my new custom search refiner to show up as ‘RefinableString00’ as that’s its name, I’ll give it the displayname ‘Document Type’.
And this is how my new custom search refiner looks now:
In this example, I showed you the main difference in creating custom search refiners in SharePoint Online compared to SharePoint on-premises. Besides this, using custom search refiners will dramatically increase user experience, but you should not exaggerate the use of custom search refiners. “Quality over Quantity” is the guiding principle. Our recommended best practice is to first create a plan on how to use company metadata and content types. Based on the approved content types, custom search refiners should be created with user experience in mind.
You can even enhance the user experience concerning custom search refiners a bit further. As custom search refiners are typed properties, you are not limited to string-based search refiners only. As you can see in the table above, there are five different data types that can be used as custom search refiners (the out-of-the-box ‘Modified date’ is based on the type ‘Date’). With different data types, the additional options that are available differ as well.
If you are using ‘Date’, ‘Decimal’ or ‘Int’ as the underlying data type for a custom search refiner, you can choose among additional display templates – like the display template that is usually used for the out-of-the-box ‘Modified date’ refiner.
You can see the additional display templates in the following screenshot.
As display templates are based on HTML files that embed some JavaScript code, you can even create custom display templates that can be used to display search refiners. Let’s assume a company has different branches and there is a managed metadata used to tag documents with the name of a branch. Instead of using a string-based search refiner to display the branch names, you can create a custom display template which displays the branches by their logos instead of their names. Because JavaScript code is embedded into the HTML that is used as a custom refiner display template, there are numerous options on how to display search refiners. If you would like to deep-dive into custom display templates for search refiners, I encourage you to have look at Elio Struyf‘s posts.
As I stated in my previous blog post as well, you can enhance the user acceptance of a corporate intranet drastically by providing a well-designed Search Center that enables employees to quickly and easily retrieve information. A corporate intranet should enable employees to work and to collaborate more efficiently. To make a corporate intranet successful, it needs to extend past terms of efficiency and cost-reduction as taken company benefits. User acceptance is just as important as cost-reduction and efficiency. Each outstanding benefit provided to the users will increase user acceptance and a well-designed Search Center that truly meets the needs of the users will ultimately improve user acceptance.
Written By:
softlanding
Softlanding is a long-established IT services provider of transformation, professional services and managed IT services that helps organizations boost innovation and drive business value. We are a multi-award-winning Microsoft Gold Partner with 13 Gold Competencies and we use our experience and expertise to be a trusted advisor to our clients. Headquartered in Vancouver, BC, we have staff and offices in Toronto, Montreal and Calgary to serve clients across Canada.
More By This Author
