which API can Register the application

I do appreciate the end goal. And Azure Functions makes considerably more sense in that context.

You're not simply trying to eliminate Power Apps. You're trying to deliver a Base Release that doesn't leave the Knowledge Management team responsible for maintaining another application.

That's a stronger deployment argument.

Your eventual architecture could be:

SharePoint Online
  |
  +-- Native Search Analytics
  +-- Plays Document Library
  |
  v
Azure Function (Python)
  |
  v
SPO Metrics List
  |
  v
Python Reporting Modules
  |
  v
HTML Management Reports
  |
  v
SPO Documents Library

The Python collection and reporting modules could eventually run together under a scheduled Azure Function, with the necessary adjustments for its execution environment.

Why this may be easier to approve

• Centralized deployment: IT owns the execution environment rather than individual product users.

• No desktop dependency: Nobody needs to install Python, PowerShell or maintain local scripts.

• Controlled permissions: An Entra ID application identity can be granted narrowly scoped SharePoint access.

• Scheduled execution: Azure Functions can run unattended using timer triggers.

• Operational visibility: Execution logs and failures can be monitored centrally.

• Modular maintenance: Collection, normalization and reporting remain separate Python components.

There are still operational responsibilities, including Azure costs, application permissions, monitoring and support ownership. But those belong in an infrastructure deployment discussion rather than the daily Playbook workflow.

The approval argument

The business owns the Plays and their metadata. IT owns the collection and reporting service. Management consumes the reports.

Nobody using the Playbook needs to understand or maintain the machinery behind it.

And importantly, you don't need Azure approval to continue developing the prototype. Your existing Python modules can remain local until there's a deployment environment.

One architectural principle I'd preserve: keep the Azure-specific code at the edges. Your Python modules should work locally or in Azure with minimal changes.

That gives you a credible path from tomorrow's manual Base Release to an approved, unattended service without throwing away the work you've already done.

That's the architectural principle I've been missing!

You're not building a prototype and then replacing it with a production system.

You're building a working end-to-end product from day one, progressively replacing individual components.

Working Product A
       |
       | Replace one component
       v
Working Product B
       |
       | Replace one component
       v
Working Product C

Each version must remain functional, demonstrable, and independently useful.

The rules are straightforward:

• One component changes at a time.

• Interfaces between components remain stable, or are adapted deliberately.

• The replacement must prove itself before the original is retired.

• A failed experiment never takes down the working product.

• Azure Functions is a deployment destination, not a prerequisite.

That also explains why your Python data layer and HTML presentation layer are separate.

Continuous functionality, incremental replacement, reversible changes.

You're not asking for a migration plan. You're establishing an engineering discipline.

And now the entire approach to Base Release makes sense.

The metrics are already being collected and stored by Microsoft Search. The interesting question is whether we can access that data before it becomes a report.

There are three possibilities, and they aren't equivalent.

1. Where does Microsoft store the metrics?

SharePoint Online sends search activity into Microsoft's search analytics infrastructure.

Conceptually:

User performs search
         |
         v
Microsoft Search
         |
         +--> Search results
         |
         +--> Usage telemetry
                   |
                   v
             Microsoft Analytics
                   |
                   v
             Search Insights

The telemetry is processed and aggregated by Microsoft. It isn't stored as ordinary columns in your Plays document library or in a SharePoint list.

Microsoft manages the underlying storage. You don't have direct access to its analytics database.

2. Can we get at it?

Microsoft documents the Search Insights export and Microsoft Graph Search API separately.

Microsoft Learn

+1

3. What changes when we move to Azure Functions?

Azure Functions gives us a place to run Python automatically, but being hosted in Azure doesn't grant access to Microsoft's internal telemetry streams.

There are two viable architectures.

4. There's another useful API

Microsoft Graph exposes SharePoint site usage reports, including activity and file statistics.

For example:

GET https://graph.microsoft.com/v1.0/reports/getSharePointSiteUsageDetail(period='D7')

This is a supported API, returning report data suitable for processing. It requires Reports.Read.All and appropriate authorization.

Microsoft Learn

It won't provide the individual search terms you're after, but it demonstrates that some Microsoft 365 analytics are already accessible programmatically.

Where this leaves our modular design

I would keep the collection layer independent of the source:

Microsoft Search Insights
          |
          v
    Metrics Adapter
          |
          v
     SPO Metrics List
          |
          v
   Existing HTML Reports

Today, the adapter can consume Microsoft's exported analytics. Later, if we establish an approved API or another supported collection mechanism, we replace only that adapter.

The key finding: Microsoft exposes aggregated search analytics through reports, but I haven't found a documented API or event stream that exposes the same complete dataset directly.

That means Azure Functions is a sensible eventual host, but it doesn't eliminate the need to establish how the search metrics enter our collection module.