Solution Checker and App Checker in Power Platform

Power Platform's static analysis tools — Solution Checker for Dataverse solutions and App Checker for canvas apps — surface issues before they bite in production. Performance traps, deprecated APIs, security warnings, accessibility issues, plugin best-practice violations. Used systematically, they catch issues that would otherwise emerge as user-facing problems.

Solution Checker scope. Analyses Dataverse solution content:

• Plug-in code (.NET DLLs).
• Web resources (JavaScript, HTML, CSS).
• Workflow definitions.
• Power Automate flows.
• Forms, ribbons, sitemaps.
• Custom connectors.
• Metadata (tables, columns, relationships).

Findings categories.

• Performance — patterns that slow operations (RetrieveMultiple without paging, excessive plug-in cascading).
• Reliability — patterns that cause runtime failures (null reference risks, missing exception handling).
• Security — patterns risking unauthorised access (plug-in running as system without checks, hardcoded credentials).
• Usability and accessibility — forms missing labels, poor keyboard navigation.
• Best practices — deprecated APIs, outdated patterns.

Findings have severity (Critical, High, Medium, Low) and category. Each links to documentation explaining the issue.

Running Solution Checker.

• From the maker portal — Solution → Run Solution Checker.
• From Power Platform admin centre — at scale across environments.
• From CI/CD pipelines — via pac CLI or Build Tools.
• Automatic on import — when Managed Environments + enforcement enabled.

Per run, a report lists findings with file/object/line references.

Managed Environments enforcement. With Managed Environments, Solution Checker can be enforced:

• Solutions must pass before import to production.
• Critical/High findings block; lower severities warn.
• Bypass requires admin justification (audit logged).

This is the lever that turns Solution Checker from optional to load-bearing in the ALM pipeline.

App Checker — canvas apps. Built into Power Apps Studio:

• Live findings as the maker designs.
• Performance warnings (slow data sources, large galleries).
• Accessibility violations.
• Formula errors.
• Connector usage patterns.

App Checker runs continuously in the studio; serious issues block save / publish.

Performance findings (canvas apps).

• OnStart load patterns — heavy logic blocks app start.
• Filter / Search not delegating — performance collapses on large data.
• Excessive use of Set() — variables proliferating.
• Image controls referencing large blobs — load slow.

Accessibility findings.

• Color contrast — text too light against background.
• Missing AccessibleLabel on controls.
• Tab order chaotic.
• No keyboard navigation path.

For organisations subject to accessibility regulations (US Section 508, European EN 301 549), App Checker is the first-line tool.

Delegation warnings. Specific to Power Fx on data sources:

• Some functions delegate (server executes); others don't (client downloads all rows).
• Non-delegating function on a large data source = performance bomb.
• App Checker flags non-delegating patterns with yellow warning.

Makers can ignore the warning (often without consequence on small data); large-data scenarios must respect it.

False positives. Both tools produce some false positives:

• A plug-in genuinely needs to run as system; finding flagged but is correct.
• A canvas app uses a function intentionally despite delegation warning.

Annotations on the codebase mark explicit acknowledgments — "I read this finding, this is intentional."

Custom rules. Limited but growing:

• Organisations can author custom rules for Solution Checker.
• Specific to internal coding standards.
• Less mature than for traditional linters.

Reporting and dashboards.

• Per-solution finding count over time.
• Most common finding categories — coaching theme for makers.
• Trend — are we getting cleaner or accumulating debt?

Common pitfalls.

• Findings ignored. Run Solution Checker, look at output, dismiss; the findings reappear in production as incidents.
• No baseline. New project has 500 findings; team disheartened; sets unrealistic expectations.
• All-or-nothing enforcement. Critical findings block; team has to fix 50 critical findings before any deployment; frustration.
• Outdated rule sets. Tools update; new patterns flagged; baseline shifts.
• Solution Checker only at deployment. Should run continuously during development, not gate-keep at the end.

Integration with development.

• Local checker — run during development.
• Pre-commit hooks — run on every commit.
• Pull request gates — must pass to merge.
• Deployment gates — must pass to promote to production.

Each layer catches issues earlier; left-shift saves time.

Operational rhythm.

• Continuous in development — App Checker runs live.
• Per commit — Solution Checker via CI.
• Pre-deployment — required for production import.
• Periodic audit — re-scan existing solutions; track debt.

Strategic positioning. Solution Checker and App Checker turn intuition-driven quality into data-driven quality. They don't catch everything — domain-specific bugs, business logic errors, integration issues escape — but they catch a meaningful fraction of common issues at low cost. Mature Power Platform programmes treat them as essential development tools, not optional reports. The investment in addressing findings systematically pays back in fewer production incidents and easier maintenance.