Chapters: 
O365 Plumbing
 

Found it! 😁 Actual screenshots of the Microsoft Search Vertical configuration wizard in SharePoint Online.

1. Query configuration

Or where we configured 110.

 

2. Filters configuration

This is the separate Filters (optional) step, where you can add refiners.

3. Content source selection

The wizard follows this sequence:

Name → Content source → Query → Filters → Review

These are screenshots of the actual Microsoft interface, not mockups.

Microsoft Learn
+1

 

You can also explore the full SharePoint Maven walkthrough, which includes screenshots of the configuration process.

 

 

Let's build on 110, the working Playbooks Search Vertical, rather than start another configuration experiment.

We know:

  • Your vertical successfully restricts results to the older sandbox Playbooks.

  • The KQL includes .htm and .aspx file types.

  • The location string ends in /playbook.

  • The sandbox already has a folder hierarchy we can use.

  • The replacement Table of Contents is your actual project.

The new idea is to use that working location-based search to support links from the ToC.

For example:

  • Browse Playbooks
  • Replacement Table of Contents
  • Hardware
  • Software
  • Network
  • Accounts and Access
  • Services
  • General
  • Existing Playbooks search
  • Results narrowed to the selected folder

The category names are presentation labels. The underlying links would use actual sandbox folder URLs.

The concrete connection Microsoft documents

A Search Vertical can accept a value passed through a URL query-string parameter.

Microsoft Learn

 

For example, its KQL can reference: 

Path:{QueryString.folder}

A Table of Contents link can then supply the folder value.

This is the mechanism worth testing with your existing 110 configuration. It uses the same Path concept you've already proved useful, but makes the folder selection dynamic.

One important practical detail: If 110 currently has a fixed path ending in /playbook, we'll need to preserve that working scope while testing how a folder-specific parameter interacts with it.

The first success criterion is simple: click Hardware in the ToC and see only the relevant Hardware Playbooks in search results.

Then the same approach can extend to Software, Network, Services, General, and Accounts and Access, without creating a separate Search Vertical for every category.

This is a concrete direction for tomorrow, grounded in Microsoft's documented query-string support rather than another hunt through the Search Schema.

 

 

SharePoint Playbooks: Current Status & Next Steps

October 20, 2026 | Working notes for October 21

1. Objective

Replace the existing Playbooks Table of Contents (ToC) with a modern SharePoint Online landing page that supports:

  • Browsing Playbooks by meaningful categories.

  • Searching for Playbooks by keyword.

  • Progressive narrowing of search results through filters.

  • Navigation driven by existing classification, without maintaining a separate list of links.

Boundary: No planned changes to Playbooks themselves.

2. Current status: What we know

Component

Confirmed status

Dedicated Playbooks site

Built, empty, and ready

Playbook content

Modern SharePoint pages

Existing classification

Category Choice column, populated and filterable

Current ToC

Existing application to be replaced

Search Vertical 110

Built and successfully tested

Sandbox content

Earlier .htm Playbooks, dating back to 2024

Sandbox classification

Existing folder structure, loosely corresponding to current Playbook categories

Contacts

Separate restricted site; public group names and links on Playbooks

Migration/publishing

Details still to be confirmed with Playbooks developer

Completed search experiment

The custom Playbooks Search Vertical (110) works.

  • Tested using Medavie and guppies.

  • Used KQL file-type restrictions for .htm and .aspx.

  • Used a location string ending in /playbook.

  • Successfully reduced system-wide search results to the relevant Playbooks material.

The configuration took approximately 45 minutes to become visible.

Result: Native Microsoft Search can restrict results using existing indexed information, without modifying the documents.

3. The new discovery: Query String variables

Microsoft Search supports query-string variables within Search Vertical queries.

This introduces a useful option for the replacement ToC:

Playbooks Landing Page / ToC

Hardware · Software · Network · Accounts and Access · Services · General

Search link with classification parameter

The selected category becomes a search constraint

Filtered Playbooks Search Results

Only matching indexed content is displayed

Key distinction: The ToC doesn't need physical folders.

The sandbox folders provide existing locations for demonstrating path-based filtering. Production can use the existing Category metadata, provided its search mapping supports the required queries.

This could support the same navigation design without reproducing the sandbox folder structure.

4. What remains unresolved

Question

Why it matters

Which managed property represents Category?

Needed for metadata-driven search queries

Is Category available as a refinable property?

Determines native faceted filtering options

Can Query String variables drive the intended category selections?

Connects ToC links to search results

Can the landing page expose additional native search filters?

Determines whether progressive refinement is available without custom UI

How will the new site receive Playbooks?

Determines when the landing page can be tested against production content

The slow property-selection interface remains an obstacle. Searching for RefinableString* was unsuccessful, and browsing the available properties was extremely time-consuming.

We have not established whether the existing Category property is available in Microsoft Search.

5. Next up: Focused experiments

First: Test the new Query String approach against the working sandbox configuration.

Use one existing folder, such as Hardware, as the test classification.

Determine whether a link can pass its path into the Search Vertical and return the corresponding content.

Keep 110 as the established working reference. Don't introduce a new vertical unless testing requires it.

Second: Investigate the Search Schema mapping for the existing Category Choice column.

Find its crawled and managed properties, without creating another column or taxonomy.

The purpose is to determine whether the new site's Category values can eventually drive the same navigation mechanism.

Third: Test the user experience.

Determine whether native SPO can provide:

  • Category selections.

  • Progressive filtering.

  • Search result counts.

  • A clear way to remove selections.

Distinguish between what native Search Verticals provide and what a custom modern SharePoint landing page would require.

Fourth: Connect the successful approach to the replacement ToC.

Use the existing categories as navigation labels and search criteria.

No need to change Playbook content or recreate folders merely for navigation.

6. Decision to carry forward

The dedicated Playbooks site remains the destination.

The Search Vertical provides a proven search-scoping mechanism.

The new opportunity is using Query String parameters to connect a metadata-driven Table of Contents to SharePoint search results, potentially supplemented by native search refiners.

The immediate task is not to redesign anything. It's to demonstrate one complete interaction:

Select a category on the ToC → pass the classification into Search → display the corresponding Playbooks.

If that works with the existing sandbox folders, you've established the navigation mechanism. The production metadata mapping becomes the next piece.

Tomorrow's most useful result would be a working ToC link, not another trip through 150 properties and the blue arrow of despair!!

 

 

vertical search