top of page
  • Anthony Olisa

Leveraging Intranets as a Knowledge Management Tool within the legal sector Part III - Understanding SharePoint’s search schema


Hands typing on a laptop keyboard

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[1]. Access to your firm’s MS365 admin centre will be required for tenant-wide changes, whilst 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 (i.e. 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 (e.g., 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 list 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.


Graphic depicting the relationship between managed and crawled properties

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.


If you would like further information about 3Kites Consulting and how we can help you with your search solution, please get in touch.


[1] 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.

コメント


FEATURED
Tag search
bottom of page