Search Based Site Directory: Part 3
This is part 3 of a multi part series on how to use Content Types and SharePoint Search to build search solutions. In this series, I am using the case of a Site Directory as the example. If you are looking for the entire series, start with “Stop Using the Property Bag” to understand my point of view. Then read Search Based Site Directory: Part 1 and Search Based Site Directory: Part 2 to build your content type for this article.
!The Search Project Cycle(/images/wp-content/uploads/2017/07/071917_2120_SearchBased1.png)
Now that you have the data in your list, it is time to use the features of search to draw out the information into a format that your end users can work with. If you have read this far and are still wondering “Why go to all this trouble?” you have missed the larger picture. What if your business problem isn’t finding sites, but finding Invoices, Bills of Material, Customer Orders, etc.? You would use this exact same methodology to create a similar user experience. This is just one approach for one issue related to SharePoint “findability”.
OK, so we now have to implement a bunch of little mini items. I am going to do them in a different order from the diagram above because the “Create Display Template” task is the next article. Creating the Search Vertical is simple enough to do, I’ll do it now.
I have written at length about Managed Properties (and so have a LOT of other people). If you don’t know why you need a managed property you need to pay attention. I think that managed properties are the most misunderstood part of SharePoint Search. Managed Properties solve problems created by users and make working in search easier. In SharePoint 2013, they are actually created for you. In SharePoint 2016 and SharePoint Online Microsoft chose to disable this feature. I don’t know why. When do you need a Managed Property? You need a Managed Property any time you want to USE a property in search, in any way. For example:
Result Sources take the place of SharePoint 2010 search scopes. Think of a Result Source as a slice of the index that is identified by a query that I can easily reuse once I define it. The query can be dynamic, too. In our case we are going to define “SPContentType=SiteCatalogItem” as our query. If I also tracked a “Site Manager” property, I could create a Result Source for the current user as “SPContentType=SiteCatalogItem SiteManager={User.Name}” and that Result Source would return all of the Sites that the current user manages.
A Search Vertical is just a fancy name for a “tab” in the Search Center. The thing about these verticals is they point to a page and they can be audience targeted. This means that I can add custom refiners to the page and have a different user experience on each search page.
So, there you have it. Three key ingredients that will help you begin to pull this solution together. Here is how to do it.
Build the Solution: Refiners and Display Templates
Ready to start your next project with us? That’s great! Give us a call or send us an email and we will get back to you as soon as possible!
+1.512.539.0322