Following on from my recent article on knowledge search, I wanted to share some handy information about SharePoint’s search schema.

For those who are either planning to use SharePoint or already using it as their intranet platform, this article aims to provide insight into the workings of the platform’s search solution and offer some useful knowledge to enhance your firm’s search experience.

Search schema – what is it?

SharePoint’s search schema is the central control point for managing the data your users can search against. Within the schema, administrators can find a list of all the content metadata that SharePoint’s search engine has found during its crawl of the platform (crawled properties) and identify which of these metadata items are within the search index (managed properties – more on crawled and managed properties later).

Configuring your search schema can be done at a site or tenant level*. Access to your firm’s MS365 admin centre will be required for tenant-wide changes, while site administrators can make modifications at a site level.

Why do I need to know about it?

The configurations within the search schema will heavily influence users’ search experience. As I mentioned above, through the schema, you can add metadata items to your index (e.g. make them a managed property) and, in effect, make them searchable. So, for example, if you wanted your users to be able to search for content by practice group tags, you would configure this within the schema. Of course, you also have the ability to remove metadata from your index if ever needed. However, it’s worth bearing in mind that SharePoint comes bundled with a few default managed properties, which cannot be edited as they support features core to SharePoint.

Aside from controlling what users can search by, the schema plays a number of other crucial roles. For example, configuring what metadata can be filtered against is done within the schema. Similarly, any metadata you wish to display on your search results pages (for example, key contacts for documents) will need to be set up as a managed property and configured accordingly.

So, what are managed properties and crawled properties

Managed and crawled properties make up your search schema. They are the metadata available for you to configure within your schema. Although they work closely together, crawled properties play very different roles to managed properties. In short, crawled properties are the collection of metadata SharePoint finds every time it crawls your SharePoint tenant. They are created automatically as a result of changes within your sites (including lists and libraries), and they can very easily accumulate into the tens of thousands as more and more content is added and edited. 

However, not all crawled properties are useful for search (e.g. background system codes/identifiers), and this is where managed properties come into play. Managed properties are what crawled properties are mapped to in order to be added to your search index. As mentioned earlier, there are many default/fixed managed properties (e.g. author, last modified date, last modified by, etc), however, admin users are able to add and edit managed properties as needed.

Figure 1 Graphic depicting the relationship between managed and crawled properties

Refinable strings

If you intend to use any sort of filtering capabilities within your SharePoint search experience, then you will need a refinable string. They are essentially preset managed properties which you can map crawled properties to that you may wish to filter against.

Say, for example, you want users to be able to filter people results by office(s). To achieve this you will need the relevant crawled property for office location mapped to one of the predefined refinable strings.

It’s worth noting that SharePoint has a limited number of refinable strings – 199 to be exact. So that means, you can have a maximum of 199 filterable properties across your whole search solution. Personally, I’ve not seen a use case where anyone is getting close to that number. However, it’s one to keep an eye on as your intranet grows over time.

Conclusion

Hopefully, you have gathered from this short piece the importance of SharePoint’s search schema to your users search experience. As a result, it is important that time is taken to fully document the schema set-up, showing the managed properties and refinable strings used, why they are used, where they are used and data sources. Having this crucial information documented will pay dividends when troubleshooting or looking to make any changes in the future.

*In SharePoint, a ‘site’ serves as a container for an array of information in pages and libraries, much like a regular website. Typically, each site caters to a specific audience or purpose, and has a landing page with navigational aids to other areas of the site. On the other hand, a ‘tenant’ refers to the entire SharePoint instance and corresponds to the business entity that is using the application.

If you would like further information about 3Kites Consulting and how we can help you with your search solution, please get in touch by email [email protected] or call +44 (0)7583 973196. Alternatively get in touch via https://www.3kites.com/contact-us. 

Anthony Olisa is a consultant at 3Kites. This is the 38th article in the series Navigating Legaltech. 

--------------------

About 3Kites and Kemp IT Law  
3Kites is an independent consultancy, which is to say that we have no ties or arrangements with any suppliers so that we can provide our clients with unfettered advice. We have been operating since 2006 and our consultants include former law firm partners (one a managing partner), a GC, two law firm IT directors and an owner of a practice management company. This blend of skills and experience puts us in a unique position when providing advice on IT strategy, fractional IT management, knowledge management, product selections, process review (including the legal process) and more besides. 3Kites often works closely with Kemp IT Law (KITL), a boutique law firm offering its clients advice on IT services and related areas such as GDPR. Where relevant (eg when discussing cloud computing in a future article) this column may include content from the team at KITL to provide readers with a broader perspective including any regulatory considerations.