What Is the Microsoft Solution Checker?

The Solution Checker is built into the Power Platform and, for now, costs nothing extra. It performs a static analysis of your solution and reports violations of a set of best-practice rules maintained by Microsoft.

Anyone who ships customizations regularly should know it. But it does not replace every kind of review, and it is worth understanding where its responsibility ends.

What it checks

The focus is on code and configuration.

• Web resources and JavaScript: outdated APIs from earlier versions, insecure patterns such as eval or direct assignments to innerHTML, calls to deprecated endpoints, forgotten debug statements.
• Plug-ins and workflow activities: duplicate registrations, steps without filtering attributes, registrations on messages where things can get expensive.
• Power Automate flows through the Flow Checker and Power Fx expressions through the app check.
• Canvas apps: among other things accessibility, such as missing labels for screen readers.

Every finding comes with a category, a severity and a link to the documentation that explains how to fix it.

How to run it

In Power Apps under Solutions, next to the unmanaged solution via the context menu. The analysis runs for a few minutes, then a notification arrives. The results can be viewed in the portal or downloaded as an Excel file (be careful: checking a very large solution can take a very long time).

Alternatively, there is a PowerShell module that lets you build the check into a build pipeline. For teams that ship regularly, that is the more sensible variant, because the check then runs automatically with every change as part of the pipeline.

For JavaScript there is also an ESLint plugin that applies the same rules already in the development environment. That is the earliest point at which an error can be found, and therefore the cheapest.

Where the limits are

Three limitations matter.

It only runs on unmanaged solutions. Anyone who wants to assess someone else's solution delivered as managed cannot use it. This applies, for example, when an external service provider brings its own solution or when functionality from a third-party tool is deployed as a managed solution. What managed and unmanaged mean in detail is explained in managed vs. unmanaged solutions.

It only runs inside the environment. You need access to the environment where the solution lives. Assessing a solution in advance, before taking it over, is not possible with it. It also requires access to administrative accounts.

It checks code, not structure. Whether your fields are documented, whether naming is consistent, how many third-party solutions yours depends on, or whether environment values are wrongly shipped along: it simply was not built for that. In a takeover or migration, however, these are often the questions that everything hinges on.

Microsoft itself also points out that a clean result does not guarantee a successful import. Static analysis does not know the state of the target environment.

Used sensibly

What it combines well with is shown in the overview of free analysis tools. For the state of the environment rather than the solution, a different tool is responsible, by the way: the Solution Health Hub.

The Solution Checker belongs in the delivery chain, ideally automated. It reliably finds code patterns that are overlooked by hand, and the references to the documentation make fixes traceable.

For the questions beside it, meaning condition, maintainability and readiness for handover, a different kind of review is needed. That is not a shortcoming of the checker. It does not set out to answer these questions at all.