Customizing and extending search

SharePoint Search has been available for quite some time and can be managed by a variety of flexible tools. On the opposite end of the spectrum, Microsoft Search tends to be more rigid as it’s not as mature. Although Microsoft is constantly adding capabilities to Microsoft Search, we are focusing primarily on SharePoint Search for this article.

Building columns

In SharePoint, a common use is to build a list or library with columns to organize information. Those columns are called list columns and they are local to that specific list or library. As you start advancing up the Maturity Model of your information architecture, we suggest you start making columns as site columns instead of list/library columns. The benefit of this adjustment is that the columns are not defined by the list or library but instead defined at the site level and therefore reusable across the site. For example, you might have a column titled “Country” with a managed metadata term set. If that column is defined at the site level, it can be used in multiple lists and libraries. Even better, if it’s defined in the content type hub, it can be used in multiple lists and libraries across multiple sites. We also suggest using an ambiguous enough name for these site columns so that they can be used in multiple places but are also specific enough, so users understand what they are. A name like “Country” isn’t particularly specific but still obvious what you are referring to. In short, you want everything to bubble up to the level at which you think it’s going to have value. A lot of individuals don’t use content types and instead just dump documents into lists and/or libraries. Instead, we like to look at site columns as building blocks for content types and highly suggest focusing on reusability.

Another benefit to building columns at the site level is that if you create them with the same internal name in multiple places, they all become the same crawled property in SharePoint search. You can even change the display name in the various locations if you want them to be a little more specific or defined but that doesn’t change the internal name. Warning however, Microsoft unfortunately does not use site columns or content types in their templates. Therefore, to do this correctly, you do need some SharePoint knowledge on how to access lists settings and site settings. The barrier to entry is slightly higher due to the way they built the modern user interface to add columns but, it’s an effort worth making. You will never lose out on anything by building columns at the site or content hub type levels.

Crawled properties to managed properties

Once you’ve set up site columns, you can add the data into your list or library. However, nothing can actually happen with search until you access the search schema in SharePoint site settings or the SharePoint admin center. If you create a site column that contains values, somewhere a crawled property will be created that manages the values in the search index for you, as site columns are crawled by the search indexer. Once these crawled properties have been established, they can be used to map to a managed property and/or to map multiple crawled properties to the same managed property. For example, you might have three crawled properties titled Benefits Country, Policy Country, and Country. They technically all provide the same values. You can map all three to the same managed property. However, this is really a band-aid type of option if necessary. Ideally, you’re building site columns and reusing them instead.

Here we can see the classic UI for the search schema. It’s showing a mapped crawled property, titled Site Name, to RefinableString00. This allows you to filter by the name of the source site. For example, if we have a crawled property for Country it will list as OWS_COUNTRY, OWS standard for office web server. You can then map that column to a refinable string and use that refinable string (00 in this case) to filter content in your search queries. Therefore, in the top SharePoint search bar, one could type “RefinableString00: Angola” and it will return any content containing Angola. This is key for the information architect. One thing to keep in mind, you must have content somewhere that contains that value, in this case Angola, before the crawled property will show up. If you don’t have any content, you will be stuck in the frustrating cycle of refreshing the page and not eliciting any results.

Search queries in KQL

KQL, which stands for Keyword Query Language and is used to query the Azure log databases, can be more powerful than you’d think! It is worth reminding yourself, or learning, about some of the cool features of this language. You can filter for different property names or property operators. There are also options for grouping, synonyms, wild cards, exclusion/inclusion queries, and different ways of ranking. Parentheses are also key in this language and can be used in a range of different ways. Be sure to check out this reference from Microsoft as there is a lot of magic available with KQL.

Result sources

Essentially result sources are a way for the user to limit search results to a specific set of content or a subset of the search results. You can enter your search query into this result source, and it’ll get indexed at the time specific to your query. This is incredibly helpful when you have a large volume of items to search to improve the load time of content. For example, you may have a million items in your SharePoint search index, but you need to find all documents that use one content type. If you search through the web part, you’re going to have to search through those million records. Instead, if you set a result source, those million records will get indexed, and the search results will be limited to the subset of documents you want. Result sources are really about the speed and efficiency of your queries.

Modern PnP Search web parts

These are used to make custom built search experiences. As long as you’ve built good information architecture and set up managed properties, you can add a search results web part onto a page that will pull information from multiple sites. You can refine the search even further by adding in filters. In the screenshot you’ll see “(searchTerms) SPContentType:Policy” meaning only items with the SharePoint content type set to policy will be returned. Also, the little box underneath search results can be filtered further by any KQL name, operator, etc. On the left side you see “RefinableString00” is also checked meaning we extend search and create customized context-specific pages without fully customizing search across your environment. Also, if you’re crafty with front-end client-side HTML and CSS, you can customize the appearance of this with your own handlebar templates.

As with nearly any solution, there are a couple “gotchas” to keep in mind. The one we’ve come across the most is that if you create these site columns and/or content types but have not yet created any content using them, none of this magic happens. You must have content that uses these structures before anything will work. If you have any questions on these “gotchas” or the other content in this session, please reach out to our team.

All Resources

• Building Metadata in SharePoint Online - Emily Mancini
• How Do Site Columns Become Managed Properties - Thus Available for Search? | Microsoft Learn
• Keyword Query Language (KQL) syntax reference

Use the “share this” buttons below to post on socials and let us know how you use SharePoint search in your environment!

Do you have any questions for us? Continue the conversation on Twitter with the hashtag #AskSympraxis and mention @SympraxisC.