Chapters: 
O365 Plumbing

 

 

Playbooks: Eight-Hour SPO Search Investigation

October 19, 2026

1. Objective

Determine whether native SharePoint Online search could be restricted to the existing Playbooks without introducing custom development, additional software, or ongoing maintenance dependencies.

The environment is highly restricted. The Playbooks already exist as standardized .aspx pages, and the team has limited development resources.

2. Investigation and Testing

The investigation involved navigating several overlapping environments and content structures:

  • Switching between PROD and DEV environments.
  • Identifying and distinguishing different Playbook styles and implementations.
  • Working with .aspx and .htm files in different locations.
  • Establishing the correct paths for each environment.
  • Troubleshooting persistent KQL syntax errors.
  • Determining the correct Path query syntax without a useful URL syntax guide.
  • Using Query Builder to resolve syntax problems and successfully execute queries.

Observed Search Results

Production

  • Initial search: approximately 1,100 results.
  • Folder/path filter: approximately 300 results.
  • .aspx file-type filter: approximately 70 results.

Sandbox

  • Contained both .aspx and .htm pages.
  • Query Builder clearly demonstrated working filters.
  • Searching for guppies returned 0 results, consistent with guppies existing only in lists.
  • Searching for htm returned 1 result.

These tests demonstrated that the search engine could distinguish the intended content using the specified query restrictions.

3. The Interface Limitation

Although the queries worked in the administrative testing interface, the restricted user-facing interface would not expose the required search filters or support the intended URL parameter approach.

The obstacle was not constructing a working query. It was making that functionality available to users.

4. Search Schema Investigation

Reviewed earlier findings concerning crawled properties, managed properties, and automatically generated properties for site columns.

  • SPO supports indexed metadata and managed properties.
  • These capabilities could improve structured searches.
  • Re-indexing has been sporadic in practice.
  • Additional Search Schema configuration does not overcome the restrictions of the available user-facing interface.

Conclusion: No compelling reason to pursue Search Schema changes for this particular search requirement.

5. Alternative: Dedicated Playbooks Site

A self-sufficient SharePoint site dedicated to Playbooks could provide:

  • Native site-scoped search.
  • A focused search experience without custom filters.
  • Access through a link from the existing environment.
  • Continued ownership by the current Playbooks developer.
  • No requirement for PnP, SPFx, or additional search components.

The existing publishing process apparently uses a CopyFiles operation. This may simplify placing Playbooks in a dedicated site, subject to confirming that the pages and their dependencies continue to work.

6. PnP Considerations

PnP PowerShell and PnP Modern Search were considered.

Both offer useful capabilities, but neither has a demonstrated business justification for this requirement if a dedicated site provides satisfactory search.

Introducing technology also raises questions of permissions, technical assistance, deployment, and long-term maintenance.

The team should not inherit a technical dependency simply because a more sophisticated solution is possible.

7. Conclusion

The eight-hour investigation tested the practical limits of SharePoint search within the client's permitted environment.

It established:

  • Working search queries and filters.
  • Successful resolution of syntax and path issues.
  • Differences between PROD, DEV, and Playbook implementations.
  • The capabilities of Query Builder.
  • The limitations of the available user interface.
  • A potentially simpler alternative using native SharePoint site search.

SharePoint can execute the required search. The restricted interface cannot expose it as intended.

A dedicated Playbooks site remains a reasonable alternative, without another major rebuild or an additional technology dependency.

Working Decision

No compelling reason currently exists to continue investigating custom Playbooks search or to introduce PnP for this purpose.

The dedicated-site approach is sufficient to pursue unless an actual requirement demonstrates otherwise.

The purpose of the eight hours was to test the limits, not to build a solution. Those limits are now considerably better understood.

 

ToDo: Make the dedicated-site decision more explicit

 

And that sporadic re-indexing is another good reason not to make Search Schema changes part of the Playbooks solution.

 

SPO Search Investigation: Observed Results

Production

  • Initial search: approximately 1,100 results.
  • Folder/path filter: reduced to approximately 300.
  • .aspx file-type filter: reduced to approximately 70.

Sandbox

  • Contains both .aspx and .htm pages.
  • Filters worked clearly in the administrative query-testing interface.
  • Search for guppies: 0 results. Guppies exist only in SharePoint lists.
  • Search for htm: 1 result.

Conclusion

The administrative interface demonstrated that the queries and filters work, including against the sandbox content.

The obstacle was exposing that functionality through the restricted user-facing interface, not constructing the queries.

Working alternative: A dedicated Playbooks site using native site-scoped search, avoiding the need for a custom search interface.

And importantly, these are your observed test results, not theoretical SharePoint capabilities

Additional Investigation: Search Schema and Managed Properties

Reviewed last week's notes concerning SharePoint Search Schema, crawled properties, and automatically generated managed properties.

Findings:

  • SPO can index custom site columns and expose their values through managed properties.
  • Managed properties could support more precise searches and metadata-based filtering.
  • However, these capabilities are of limited practical value when the restricted user interface does not permit custom search queries or filters.
  • Additional search-schema configuration would not, by itself, overcome that restriction.

Conclusion: Search Schema offers additional technical capabilities but does not resolve the current Playbooks search problem.

No compelling reason to pursue this path further.

And that sporadic re-indexing is another good reason not to make Search Schema changes part of the Playbooks solution.

And that sporadic re-indexing is another good reason not to make Search Schema changes part of the Playbooks solution.

The dedicated Playbooks site remains the preferred workaround, using native site-scoped search without requiring custom search functionality.

The distinction worth retaining: Making information searchable is not the same as making that search functionality available to users.

October 19, 2026

1. The Starting Point

  • Approximately 300 Playbooks, published as .aspx pages.
  • Existing standardized templates containing free-text procedures.
  • An established developer who maintains the Playbooks and understands HTML/CSS.
  • The Playbooks have already been rebuilt three times.
  • The current Power Apps implementation is unsatisfactory.
  • On-premises SharePoint is becoming read-only.
  • The SPO environment is highly restricted, with native SharePoint functionality preferred.

Objective: Improve the ability to find Playbooks without rebuilding them or creating another maintenance burden.

2. What Today's Investigation Proved

Eight hours exploring available SPO search functionality produced two working query filters:

  1. Path: Restricted search to the relevant folder, reducing results to approximately 2,000.
  2. File type (.aspx): Further reduced results to approximately 300.

Both filters worked in the administrative query-testing interface.

The problem: The restricted user-facing interface would not expose the working filters or support the desired URL parameter approach.

Finding: The search engine can identify the Playbooks. The approved interface cannot provide the desired search experience.

Further investigation of that interface is unlikely to be productive without assistance or changes to the restrictions.

3. The Simplest Workaround: Dedicated Playbooks Site

Create a separate SharePoint Online site containing the Playbooks.

Advantages:

  • Native site-scoped search.
  • Search results naturally limited to that site.
  • No custom search components.
  • No PnP dependency.
  • No additional software to maintain.
  • Existing Playbook development practices can potentially continue.
  • Users access the dedicated site through a link from the current environment.

Important: Verify that the existing .aspx pages, links, assets and publishing process work at the new location. A new site is not necessarily a complicated migration.

The current process apparently uses a CopyFiles command. Understanding that process may reveal a relatively straightforward publishing or copying solution.

4. What About PnP?

Two distinct technologies were considered:

PnP PowerShell

  • Useful for SharePoint administration, inspection, bulk operations and automation.
  • Requires an approved execution environment and Entra application authentication.
  • Does not necessarily require a dedicated server.
  • Can be used temporarily without creating a permanent dependency.

PnP Modern Search

  • Provides configurable search interfaces through SPFx web parts.
  • Could expose more sophisticated search functionality.
  • Requires organizational deployment approval and ongoing technical ownership.

Neither is currently justified by the Playbooks search requirement.

A dedicated site may achieve the required outcome using native SPO functionality.

Conclusion: Don't introduce PnP simply because it can solve a problem that SharePoint already solves adequately.

5. Maintenance and Ownership

The existing developer is capable, interested in technology, and already responsible for the Playbooks.

The goal is not to replace his work, redesign his templates, or introduce technology he must subsequently maintain.

There is an important distinction between:

  • Using technical tools temporarily to establish or improve a SharePoint environment.
  • Building a permanent solution that depends on those tools.

The first does not necessarily require somebody to take over the tooling. The second does.

Any proposed improvement should respect the team's limited development resources.

6. Remaining Questions

Before proceeding with a dedicated site:

  • Can the existing Playbook publishing/copying process target another SPO site?
  • Are the .aspx pages modern Site Pages or another page type?
  • Will links, supporting assets and navigation survive relocation?
  • Can the team create and maintain a dedicated site under existing restrictions?
  • Does native site search provide a satisfactory experience once the Playbooks are isolated?

These are validation questions, not reasons to begin another major investigation.

7. Working Conclusion

A self-sufficient Playbooks site, linked from the existing environment, is currently the preferred solution.

It provides a reasonable answer to the search problem while preserving the existing content, developer ownership and organizational constraints.

There is no demonstrated need for PnP, SPFx, RoboHelp, or another Playbook rebuild.

Further technical exploration should be driven by a specific unmet requirement, not by the availability of more sophisticated tools.

Bottom line: The search queries work. The interface is the obstacle. A dedicated site may eliminate that obstacle without introducing another one.

Decision for tomorrow: Stop investigating Playbooks unless the dedicated-site approach reveals a genuine limitation. Move on to work with a clearer business justification.

PlayBook