You love the SharePoint Framework, so you build stuff with it. It’s the accepted development model, and it’s been around for years now. There’s no risk of falling behind or getting out of sync with the rest of the Microsoft 365 development world. You’re playing by the rules!
Scenario One
You’ve created some fantastic Web Parts and made them available across your tenant. Time passes, and there’s a regime change in your organization. Someone new in power wants an inventory of where those Web Parts are in use to understand how valuable they really are – some measure of ROI for the original investment.
Scenario Two
You use some community maintained Web Parts and they provide fantastic capabilities. Because of some business changes, you decide to build your own versions of the Web Parts, which will function quite differently. So you need to know how many places you’ll need to reconfigure when you have the new Web Parts ready.
Scenario Three
Because of attrition and some truly colossal budgeting mistakes, the team who originally built your Intranet is long gone. you know they did some less than ordinary things, but you’re not sure what. Web Parts are starting to break and you need to do some triage. (Or it’s possible the consultants who built things and didn’t communicate well left you with a mess – but that rarely happens. 
)
The examples above are basically unsolvable. Deploying Web Parts tenant-wide seems like a fantastic idea, but there is no tooling you can use to identify completely where those solutions and their Web Parts are in use. Even if you were cautious and you only deployed the solutions with the Web Parts to sites where they were requested or it seemed like they would be useful, you can’t figure out where they are actually used – or whether they are in use at all.
Why is this? Because there is no pages API. We can write PowerShell to loop through all the sites in the tenant to see where a solution is deployed. That looks something like this (code based on a @ToddKlindt example):
# Get all the sites
$sites = Get-PnPTenantSite
# Loop through the sites
foreach ($site in $sites) {
$app = Get-PnPApp | Where-Object -Property title -Like -Value $appToFind
if ($app) {
Write-Host "$($site.Url) has $($appToFind)"
# Loop through the pages - Oh, No!
}
}
Great, we know where the solution is deployed. All we need to do is loop through the pages to see where the Web Parts are in use. Damn, no. No pages API. We could try to load the pages into memory and try to do some sort of jQuery selector like stuff to see if the Web Parts are there, but the page assembly pipeline and progressive loading means you may not even have a real view of the page.
Wait! App Insights! We can just run through that data and see where the Web Parts are used. Oh, dang. We weren’t told to use App Insights or it was deemed to complex or expensive to bother with. No joy there.
What we really need is a solutions dashboard that shows us where solutions are used, how many times Web Parts are installed, how often they load, where there are performance issues, etc. But the only way that dashboard could realistically be built is – you guessed it! – if there were a pages API.
My search hero, Mikael Svenson (@mikaelsvenson) suggested a way to find the Web Parts with search in his post Locate pages where a particular web part is being using on modern SharePoint sites which is based on a post by Beau Cameron (@beau__cameron) called Experiment – Find out where SPFx Web Parts are being used in Modern SharePoint sites. So you can get at this info via search, but it’s a bit of a kludge.
I’m going to try to devise something with this approach, but my disgruntlement stands. See my follow up post: Upgrading the PnP Modern Search Web Parts from v3 to v4: Where are they?
When Microsoft builds new functionality like modern pages and doesn’t provide an API, they are blocking all sorts of scenarios. Those blocked scenarios are important to them as well as us. Remember that modern pages have been around for years now. It’s inexcusable that there isn’t an API for them. I’ve been involved in many discussions that have ended with…but there isn’t a pages API, so we can’t do that. Some of those discussions have been with people who work at Microsoft.
Modern solution management is going to become ever more important as organizations continue to use the excellent capabilities arriving regularly to the Microsoft 365 platform. But for every shiny new capability that rolls out, there are a dozen unfulfilled needs or broken promises. Understanding solution usage in our tenants shouldn’t require a PhD in PowerShell, a live chicken, divinity lessons, and 12 garter (not Gartner) snakes.
Connexion
