By Cathy Dew
In our previous blog post, we went through the basics of how to turn the standard SharePoint search function into a veritable “SharePoint power search.” That blog focused on how you can use metadata columns, content types, managed properties, crawled properties, and aliases to make the documents hosted on your SharePoint intranet more searchable and more easily discoverable. This time around, we are going to look at some of the more complex components of SharePoint search, such as the interrelationships between SharePoint managed properties, assignments, and the term store.
Managed Properties: Strings, Refiners, and Aliases
One of the topics we covered in the first blog post about SharePoint power search was aliases. In SharePoint’s search schema, you can create new managed properties and map them to existing crawled properties to make new metadata columns searchable. The catch is that SharePoint only lets you create new managed properties if the property “Type” is a text field or a yes/no field. You cannot turn numbers, dates, dollar values, and other numerical properties into managed properties in the standard way.
Instead, to make these types of metadata searchable in your SharePoint library (or libraries), you need to find the appropriate default unused managed property—an existing managed property—and “change its name”. This action gives the property a new alias and allows you to use the property as you see fit. Depending on the default unused managed property you use, you should be able to use these aliased properties as queryable properties or refiners for other searches.
Most managed properties in SharePoint are strings, which means they are built around text-based metadata fields. That’s because SharePoint automatically creates managed properties for all metadata columns based on the Text data type. In turn, most searches in SharePoint also tend to be text-based. However, there are of course situations where you might wish to refine a search with different types of data—such as numbers, integers, decimals, currency amounts, dates, or times. All these values which use a different data type in SharePoint search.
Luckily, SharePoint’s search schema includes the aforementioned default unused managed properties—many of which are preconfigured as refiners and preconfigured to use different data types. The RefinableDate managed property allows you to refine searches using dates. RefinableDecimal lets you search for numbers “with maximum three decimals.” RefinableDouble properties let you search for numbers “with more than three decimals.” RefinableInt properties allow you to search for metadata values that are integers (or whole numbers).
RefinableString, finally, is the only type of refiner that doesn’t use numbers. Instead, this default unused managed property lets you refine searches with strings, or “values that are the data type Text, Person or Group, Managed Metadata, Choice, and Yes/No.” In other words, it lets you refine searches with anything that isn’t numerically-based.
If you are using multiple refiners in each category, using aliases will help you keep track of which managed property is which. However, bear in mind that Microsoft places limits on how many aliases you can establish for each default unused managed property. Below, we’ve listed the number of slots you have for each refiner:
- RefinableDate: 20
- RefinableDecimal: 10
- RefinableDouble: 10
- RefinableInt: 50
- RefinableString: 100
When you run out of slots, you will need to delete old aliases to make way for new ones. Each time you create an alias and use a slot, you are mapping a managed property to a specific crawled property to make it usable by the search schema. If you only need some of these refiners temporarily, or if some are more important than others, consider deleting the older, less-used ones to keep space open for future aliases.
Using Refiners in Search
Okay, so now you’ve configured refiners in the search schema. The next step is figuring out how to use them to power your SharePoint search function. Say you want to find a specific SharePoint document. You don’t know the exact title of the file. You know a few associated keywords, but those keywords are common among the documents in your SharePoint library. You do, however, know the general creation date of the file. You want to use a date refiner to find what you need.
The first thing you should do is go about searching your SharePoint intranet or site as you would under any other circumstances. Enter the keywords you want to find and initiate the search. On the search results page, though, instead of going digging through all the documents the search returns, click on the Settings menu and then click “Edit Page.”
You should now see a Refinement Web Part on the left-hand side of the screen. If you open the Web Part Menu and click “Edit Web Part,” you will see a button that says, “Choose Refiners.” Clicking that button will launch a new menu, where you will see two lists. The first list is all the refiners that are available to you. The second list is your “Selected refiners,” which you have chosen to use for search purposes.
In the first list, you should be able to find any refinable managed property. Say you configured RefinableDate01 so that you would be able to refine searches based on the date information you need. Simply find RefinableDate01 in the “Available refiners” list and click “Add” to move it to the “Selected refiners” list. After that step, the date refiner will be visible and usable on the left-hand side of your search page.
You can also do some configuring for your refiners right there in the Web Part Menu. For instance, you might just want the refiner to show you date ranges for files (e.g., Friday, July 16, 2017 - Friday, September 1, 2017), or you might want it to function as a bar graph with a slider. Maybe try out a few different configurations to see what looks and feels best to you and your team.
Tenant Wide Assignments versus Site Collection Assignments
As with so many other SharePoint features, you can choose to set up refinable properties at either the SharePoint Admin (tenant) level or at the site collection level. Which one is best for usability and overall search power?
When you configure managed or refinable properties at the site collection level, they end up “locked” to that particular site collection. You can only use them on the sites in that collection. When you configure at the tenant level, you will be able to use those properties for all site collections in your SharePoint environment.
The issue with either of these options is that SharePoint lacks any administrative tool to track managed properties and refiners from within SharePoint itself. There is no way to know where a managed or refinable property was originally created. As a result, if you start building managed properties and refiners at both the tenant level and the site collection level, you are going to have clashes and collisions.
In most cases, the best thing to do is configure managed properties and refinable properties at the site collection level. That way, you can set up preferred properties and appropriate aliases based on what is most relevant for specific site collection levels. While the tenant level is inherently larger and more overarching than the tenant level, that doesn’t mean you get more slots to build custom search attributes with your default unused managed properties. If you try to build aliases and properties to suit every site collection in your SharePoint environment, you are probably going to run out of vacant slots sooner and end up with a search setup that isn’t as well-suited to the end users of each site collection.
Managed and refinable properties aren’t the only search properties best configured at the site collection level rather than the tenant level. On the contrary, the same best practice applies to managed metadata columns. Trying to configure columns at the tenant level often creates issues where the columns cannot be indexed properly. If you are using indexing to improve the searchability of your libraries—as you should be—then managing them at a lower level will help avoid common errors or problems.
Speaking of column indexes, using them correctly can be a huge boon for your SharePoint power search. Microsoft added indexed columns to SharePoint back in 2010, as a means of simplifying the viewing experience for lists or libraries with a lot of documents. If your SharePoint library or list contains more than 5,000 items, then SharePoint will often use data throttling to preserve resources and maintain good performance. The downside, of course, is that finding data in these large lists or libraries becomes extremely difficult.
In most cases, SharePoint administrators either try to keep libraries and lists smaller or use columns to filter and sort results. For instance, you might have a date column that you want to use to find a file created around a certain time. The issue is that if you frequently use the date column to display a sorted view, SharePoint repeatedly must loop through all the documents in the library or list to sort them by date. Indexing the date column essentially means that SharePoint already knows how to sort the library or list documents by date. As a result, indexing commonly used columns typically saves a lot of time.
You can index 20 columns for every large library or list. You can also index columns in “Simple” or “Compound” fashion. Simple index columns have just one primary column indexed, while Compound index columns have a primary and secondary column in the same index. In the example above, where we indexed the date column, we would have used a Simple index column.
Do note that indexing columns uses resources. To maintain the best performance, you should only index the columns that you frequently use to sort large SharePoint libraries or lists.
Get Help with SharePoint Power Search
Do you need help implementing any of the strategies discussed above? At 2 Plus 2, we are happy to help you attain SharePoint power search for your SharePoint intranet. Go online to schedule a free consultation with our team or call 510-652-7700 today.