name

power-platform-solution-builder

description

Plan, build, validate, package, and import complete Microsoft Power Platform solutions from user requirements, including solution-aware canvas apps, Power Automate cloud flows, connection references, environment variables, responsive Power Apps design, PAC CLI auth/import/export, and Docker-based validation fallback. Use when a user wants an import-ready Power Platform solution zip or .msapp, asks to fix Power Apps checker, formula, or layout issues, or needs end-to-end Power Platform implementation guidance.

Power Platform Solution Builder

Overview

Use this skill to turn a brief, PDF, or existing app into a validated Power Platform delivery: solution-aware canvas app, cloud flow, solution package, deployment settings, and environment import verification.

Prefer a solution-first workflow. Treat standalone .msapp files as intermediate artifacts unless the user explicitly wants only the app file.

Trigger Examples

"Create a full Microsoft Power Platform solution from this take-home PDF."
"Build the missing Power Automate flow and give me an import-ready solution zip."
"Fix the formula errors in this Power App and rerun the checker."
"Make this canvas app responsive and repack the solution."
"Import the updated solution into my environment without touching the others."

Start Here

If starting a new repo, scaffold it first:
- python3 scripts/scaffold_power_platform_project.py /path/to/new-project --project-name "My Project" --preset enterprise
- Then read references/project-scaffold.md
Read references/requirements-and-research.md and create a requirement matrix before building.
Read references/environment-and-tooling.md and run scripts/power_platform_preflight.sh.
If the host .NET or PAC installation is unreliable, use scripts/power_platform_docker.sh for PAC and PASopa instead of trusting the local runtime.
Read only the references needed for the current phase:
- Canvas app UX, formulas, or responsiveness: references/canvas-app-design.md
- Live imported-app screenshots, Dia browser capture, or image-based visual QA: references/live-visual-qa.md
- Flow design, connectors, or connection references: references/flow-and-connectors.md
- Packaging, checker, import/export, solution versioning: references/validation-and-alm.md
- Formula failures, packaging oddities, auth issues, or visual regressions: references/troubleshooting.md

Workflow

1. Isolate the target environment

Confirm the exact environment before any import or maker action.
Prefer a dedicated environment or, at minimum, a dedicated solution name and publisher prefix.
Avoid editing unrelated existing solutions unless the user explicitly approves it.
If the flow needs Teams, Planner, or mailbox targets, prefer dedicated project assets instead of reusing the user's live operational assets.

2. Map requirements before building

Extract every explicit requirement from the brief.
Add inferred technical requirements only when they are necessary to make the solution importable, supportable, or testable.
Record each requirement, implementation decision, validation method, and unresolved assumption.
Do not start building until every requirement has an owner and a verification path.

3. Research from primary sources

Use official Microsoft Learn pages and official Microsoft repositories first.
Re-check time-sensitive topics such as PAC CLI flags, solution settings, responsive-layout guidance, connection-reference behavior, and current source formats.
Prefer environment URL or environment ID over friendly names in CLI workflows when scripting auth and imports.

4. Design the solution architecture

Decide the solution name, publisher prefix, versioning scheme, data model, connectors, connection references, environment variables, and deployment settings strategy.
Choose whether to use Dataverse tables, standard tables, or external sources. If custom schema is required, include it in the solution instead of relying on manual post-import setup.
Keep the canvas app, flow, and supporting configuration solution-aware from the start.

5. Build the canvas app

Make the app look like a finished production app, not a walkthrough or submission guide.
Use responsive formulas, not desktop-only fixed geometry.
Keep labels, cards, forms, galleries, and action areas resilient to different widths.
Treat formula errors, clipped text, overlap, and broken navigation as ship blockers.

6. Build the flow and connectors

Create the flow inside the solution or move it into the solution immediately.
Use connection references and environment variables where appropriate.
Make the flow idempotent when duplicate triggers or replays would create bad side effects.
Separate business logic from environment-specific identifiers so the solution can be imported cleanly.

7. Validate aggressively

Rebuild the .msapp.
Run PASopa round-trip validation if the project uses extracted msapp sources.
Run pac canvas validate on official unpacked app source.
Run pac solution check on the packaged solution.
Capture live screenshots from the imported app when responsiveness or visual quality matters.
Fix every formula error, binding error, import-time dependency issue, and obvious design regression before handoff.

8. Package, import, and verify

Produce the standalone .msapp if the user asked for it or it is useful for review.
Produce the unmanaged solution zip, and a managed zip if explicitly requested.
Generate or update the deployment settings file for connection references and environment variables.
Import into the approved environment, publish changes, and verify the solution version and key components afterward.
Only declare delivery complete after import and post-import verification succeed, or state exactly what remains unverified.

Guardrails

Do not hand-author unsupported solution internals when the official tooling or maker portal must generate them.
Do not treat unstable generated .msapp JSON as the source of truth when Src files or solution source are available.
Do not assume the local PAC or .NET installation works; verify it. On macOS, Docker fallback is often safer.
Do not leave stale checker artifacts, sample files, or inherited placeholders in the final package.
Do not claim the app is responsive without testing multiple widths and checking for clipping, overlap, scroll traps, and truncated labels.
Do not treat source inspection as enough visual QA when you can attach to a live authenticated browser session and capture the real player.

Quick Commands

# Scaffold a new project
python3 scripts/scaffold_power_platform_project.py /path/to/new-project --project-name "My Project" --preset enterprise

# Preflight local machine and workspace
scripts/power_platform_preflight.sh /path/to/project

# Run PAC in Docker with persistent auth cache
scripts/power_platform_docker.sh pac auth create --deviceCode --environment <env-id-or-url>
scripts/power_platform_docker.sh pac solution import --environment <env-url> --path output/MySolution.zip --settings-file output/MySolution.settings.json --publish-changes

# Run PASopa in Docker
POWERAPPS_TOOLING_DIR=/path/to/PowerApps-Tooling \
scripts/power_platform_docker.sh pasopa -pack output/MyApp.msapp powerapps_app_src

Resources