What it does

Static analysis of an unmanaged solution against a set of best practice rules, run from the maker portal, PowerShell or a build pipeline. It returns issues by severity and category with a link to guidance for each one. App checker is the separate, in-Studio equivalent for a single canvas app.

Key facts

• It analyses custom workflow activities, web resources (HTML and JavaScript), Dataverse configuration such as SDK message steps, Power Automate flows via flow checker, and Power Fx expressions via app checker.
• Works on unmanaged solutions that can be exported. Microsoft-managed solutions show as Checked by Microsoft; other managed solutions as Checked by Publisher, and neither can be analysed.
• Severities are Critical, High, Medium, Low and Informational. Categories are Performance, Maintainability, Usage, Supportability, Design, Security, Accessibility and Upgrade readiness.
• In Managed Environments, enforcement has three levels. None turns it off. Warn checks every custom solution on import, lets the import proceed, and emails a summary. Block cancels the import before any change is made when critical issues are found.
• Only critical severity rules block an import. Everything else is reporting.
• Admins can exclude specific rules from enforcement, so one expensive-to-fix rule doesn't hold up everything else.
• Enforcement emails go to Power Platform administrators, Dynamics 365 service administrators and weekly digest recipients. They can be suppressed for medium-and-above severities, but critical blocks always send.
• A run typically takes about a minute and can run to five or more depending on solution size and complexity.
• Passing solution checker doesn't guarantee a successful import. The analysis has no knowledge of the target environment's configuration.
• Web resource rules cover ECMAScript 2015 globals up to ECMAScript 2018 syntax. Anything later reports as unsupported syntax.
• Rules can run locally against JavaScript and TypeScript through the @microsoft/eslint-plugin-power-apps npm package.
• Enforcement doesn't work while an environment is in administration mode.
• App checker in Studio is a separate tool. Its accessibility view classifies findings as errors, warnings and tips rather than the five-level severity scale.

When to use / skip

Run it before every promotion, and preferably as a pipeline gate so it isn't optional. It's cheap, it's fast, and the findings are specific enough to act on rather than the vague "consider best practices" output some analysis tools produce. Set enforcement to Warn across the estate as a matter of course — it costs nothing and gives the admin team visibility. Only move to Block once you've run in Warn long enough to know what the estate actually produces, because turning Block on cold will stop a release on day one and burn the client's goodwill for the tool.

Configuration decisions

• Warn or Block per environment, and whether production is stricter than test.
• Which rules to exclude from enforcement, and whether that exclusion is temporary with a remediation plan or a permanent decision someone has signed off.
• Whether the checker runs as a pipeline gate through Build Tools as well as at import, so issues surface in the build rather than at deployment.
• Whether the eslint plugin runs in the developer's editor, which catches web resource issues before they reach a solution at all.
• Whether email suppression is on, weighed against the admin team's appetite for notifications.
• Whether app checker and the accessibility view are part of the definition of done for canvas apps, since solution checker only covers Power Fx expressions rather than the whole app experience.

Gotchas

• Turning on Block without a Warn period is the classic mistake. The first blocked import is always urgent and always someone else's release.
• Results are stored in different places depending on how the check ran — maker portal runs store them in the source environment, enforcement runs may store them in the target. The link in the email can expire, and then you re-run to get results.
• Managed solutions can't be checked, so an ISV solution you've inherited gives you nothing.
• The service principal used for checker runs needs a role with the prvAppendmsdyn_analysisjob privilege. System Administrator has it; a trimmed-down custom role may not.
• A clean report is not a green light. Import can still fail on dependencies and target configuration the analysis never saw.
• Enforcement is unavailable in administration mode, which is exactly when someone tries a remedial import.

Consultant notes

• Run it on the inherited estate during discovery and put the severity counts in the assessment. It's the fastest way to turn "the system is a bit messy" into a number a sponsor can act on.
• Frame Block mode as protecting production rather than policing makers. The conversation goes differently if the client's team believes it's on their side.
• Don't promise to clear every finding. Agree a threshold — critical and high, say — and treat the rest as backlog, or you'll spend the budget on informational warnings nobody cares about.
• Accessibility findings from app checker are worth raising with public sector and regulated clients specifically. It's often a procurement requirement they haven't connected to their Power Apps estate.

---

Worth revisiting when the rule set changes, or if enforcement gains severity levels below critical.