Decommissioning a SharePoint site or a Power BI report? Search every app first.
Before you retire a SharePoint site, a Power BI report or a SQL server, you need every app and flow that references it. The references are inside the apps, not in any admin API. Here is how to find them.
Somebody is about to turn something off. A SharePoint site that has not been touched in two years. A Power BI workspace nobody can name an owner for. A SQL server being retired with the rest of a datacentre.
The question before the switch is always the same — what still points at this? — and for the Power Platform estate it is genuinely difficult to answer, for a reason that has nothing to do with how well the estate is run.
The reference is inside the app, not beside it
Microsoft’s admin APIs describe what an app is bound to: its connectors, its connections, the environment it lives in. They do not describe what it contains. A canvas app ships as a .msapp package, and every formula a maker wrote is inside it.
So a reference typed into a formula — a site URL in a Patch(), a report link behind a button, a server name in a comment that somebody later turned into working code — is invisible to every surface that lists apps. It only exists in the package.
This is not a gap in the APIs. Apps are opaque to the platform by design; the platform does not read your formulas any more than it reads your Excel sheets. But it means the impact-analysis question has to be answered by reading the source, app by app, which at estate scale is nobody’s afternoon.
Five things worth searching for
These come up in almost every tenant, and each one answers a different decommissioning question.
SharePoint references
Site URLs, list paths and the SharePoint connector, wherever they appear — including a URL typed straight into a formula rather than picked through the connector. This is the one that matters most for a site retirement, because the bound version will show up in a dependency check and the typed version will not.
Power BI
Report and dashboard links, embedded tiles, and the Power BI connector. Workspaces get consolidated far more often than SharePoint sites do, and a report URL inside an app is a dependency nobody records in the Power BI lineage view.
SQL servers and databases
The connection names a server. The app’s own data sources name it again, and a flow step may name a specific database and a specific stored procedure. For a server migration you need all three, and the flow definitions are where the surprises are.
Hard-coded URLs, generally
Any absolute link. Most are harmless, some point at the tenant you are leaving, and a handful point at things that no longer exist and have been failing quietly for months.
Environment and object ids
A deep link to another app carries an environment id and an app id. These are the references that break on a tenant move and never break otherwise, so nobody finds them until the move.
Do it across environments, in one pass
The thing that makes this tractable is scoping it to a set of objects rather than to an environment. The real question is almost never “which apps in Production Finance reference this site?” — it is “which apps anywhere reference this site?”, and the answer has to cross the default environment, the developer environments and the one somebody spun up for a proof of concept in 2024.
A saved selection that spans environments is the right unit: name it once, search it repeatedly, and let it re-evaluate against the current assessment each time rather than describing an estate that has since changed.
One practical note: each app is a package download, so a search across a large selection takes a few minutes rather than being instant. That is a property of the problem, not of the tool — there is no index of app contents to query, so somebody has to open every package. Better that it is a job you start and come back to than a job you do by hand.
What a usable answer looks like
A list of app names is not enough to act on. The answer needs to carry:
- Which app, in which environment, owned by whom. The owner is who you contact.
- Where in the app the match was. One occurrence in one formula is a different job from forty across a dozen screens.
- Whether it was typed or bound. A bound data source is reconfigured; a typed string is edited. Different work, different person, different risk.
- An export. The people who have to act on this are app owners across several teams, and they will each want their own rows.
Then turn the answer into a standing check
The reason to build this once properly is that the question recurs. Every site retirement, every report consolidation, every server migration, every tenant move asks the same thing about a different string.
If the answer takes two weeks the question stops being asked, and things get switched off hopefully. If it takes an afternoon it becomes a normal step in a decommissioning checklist, which is where it belongs.
Power Insights searches inside every canvas app package in a selection — across any number of environments — for SharePoint references, hardcoded URLs, SQL servers, Power BI and any string you type, and exports every answer.
