Individually the seven plugins (Part 3) each cover one slice of the Power Platform. The payoff comes when you use them together. This final post walks through one connected solution — Contoso Field Services, an equipment-maintenance company — and shows where each plugin fits, in the order you'd actually build it.
A note on how to read this: at the CLI, you don't call skills by name. You describe what you want in plain language and the agent matches your request to a skill (that's what those description fields in Part 2 are for). So the prompts below are the real input; the skill noted after each is what the agent loads to do the work. These prompts are identical in Copilot CLI and Claude Code — only the setup commands from Parts 1–2 differ between the two tools.
The scenario
Contoso sends technicians to fix industrial equipment. They need:
- customers to request service online,
- an incoming request to kick off automation (assign, notify),
- dispatchers to triage and schedule from their internal app,
- technicians to work jobs in the field, offline, from a phone,
- managers to see operations on a dashboard,
- and a couple of helper apps and widgets around the edges.
One Dataverse data model underneath, seven plugins on top.
Step 0: One shared foundation
Everything hangs off the same Dataverse tables and lives in one solution, so start there. Power Pages' setup-datamodel and setup-solution skills are a fine place to define the core schema, since it's the first surface we'll build:
> Set up a Dataverse solution called "ContosoFieldServices" with tables for
Customer, Asset, ServiceRequest, WorkOrder, and Technician, with the
relationships between them.
Skills: setup-solution, setup-datamodel (power-pages) → delegates to the data-model-architect agent
Defining the model once, in a named solution, is what lets every later app bind to the same tables and ship together. Keep that solution name handy — it threads through everything below.
Step 1: The customer portal — power-pages
The public front door. Customers land here to submit and track service requests.
> Create a Power Pages code site for customers to submit an equipment service
request and check its status. Use React. Bind the form to the ServiceRequest
table and require sign-in.
Skills: create-site, then integrate-webapi to bind the Dataverse Web API, setup-auth + create-webroles for identity, audit-permissions to check table access.
Because the Power Pages plugin ships the Playwright MCP, the agent opens the running site and verifies the form actually renders and submits before it calls the step done.
Step 2: Intake automation — power-automate
A new ServiceRequest row shouldn't sit there. A cloud flow triages it: assign a technician, set priority, notify the customer.
> Create a cloud flow that triggers when a ServiceRequest is created, finds the
nearest available Technician, creates a WorkOrder, and emails the customer a
confirmation.
Skills: create-flow / build-flow (power-automate) via the FlowAgent MCP server (az login required).
This is the connective tissue: the portal writes a row, the flow turns it into assigned work. Later, if you need to tweak the routing logic, the plugin's debug-flow and surgical-edit skills change that step without regenerating the whole flow.
Step 3: Dispatcher triage — model-apps
Dispatchers already work in a model-driven app. Give them a custom generative page there to see the incoming queue and schedule jobs, without leaving the app.
> Add a generative page to our model-driven app that shows open WorkOrders on a
map with a scheduling panel, reading from the WorkOrder and Technician tables.
Skill: genpage (model-apps) → planned and built in parallel by the genpage-planner, genpage-entity-builder, genpage-connector-builder, and genpage-page-builder agents. Needs pac ≥ 2.7.0 and az.
Step 4: A quick asset-lookup helper — canvas-apps
Not every internal need deserves a full app. Dispatchers and back-office staff want a fast way to look up an asset's service history. A small canvas app does it, and now it's versioned source (.pa.yaml) instead of a hand-built screen.
> Build a canvas app with a search box that looks up an Asset and shows its
past WorkOrders.
Skills: generate-canvas-app + add-data-source (canvas-apps) via the Canvas Authoring MCP server (needs the .NET 10 SDK).
Step 5: The field technician app — mobile-app
Technicians are on-site, often with no signal. They need a phone app that works offline and can use the device — camera for photos, GPS for check-in.
> Create a mobile app for technicians to view their assigned WorkOrders, update
status, and attach photos. It must work offline and sync when back online.
Skills: create-mobile-app, add-native (camera/GPS), and the offline stack — setup-offline-profile, enable-tables-offline, assign-offline-profile (mobile-app). Ships via Power Apps Wrap with deploy / open-wrap-url.
The offline profile is defined against the same WorkOrder and Asset tables the dispatcher app writes to — one schema, two very different clients.
Step 6: The operations dashboard — code-apps-preview
Managers want a real web dashboard — throughput, SLA breaches, technician load — as a pro-code app rather than a canvas screen.
> Create a Power Apps code app dashboard showing WorkOrder volume, average
time-to-close, and technician utilization. Connect it to Dataverse and Office 365.
Skills: create-code-app, add-dataverse, add-office365, then deploy (code-apps-preview). React + Vite, pac-deployed.
Step 7: A visualization widget — mcp-apps
Say Contoso wrote a small internal MCP tool that scores equipment failure risk. Its raw output is JSON. Wrap it in an interactive widget so it renders as a real UI wherever that tool is used.
> Generate an MCP App widget that renders our failure-risk tool's output as a
ranked list with severity colors.
Skill: generate-mcp-app-ui (mcp-apps) — a self-contained HTML widget using the MCP Apps protocol.
Step 8: Package and ship it — ALM with power-pages
Seven surfaces, one solution. The Power Pages plugin's ALM skills tie it together and move it from dev to test to prod. plan-alm even runs a solution-splitting decision tree — useful once you have this many components.
> Plan the ALM strategy for the ContosoFieldServices solution across dev, test,
and prod, then set up a deployment pipeline and export the solution.
Skills: plan-alm, setup-pipeline, ensure-pipelines-host, deploy-pipeline, export-solution (power-pages). Use diagnose-deployment if a stage fails.
The whole picture
┌─────────────────────────┐
Customer ──▶ power-pages portal ──▶ ServiceRequest ─┐
└─────────────────────────┘ │
▼
power-automate flow ──▶ WorkOrder created
│
┌───────────────────────────────────────────────┼───────────────────────┐
▼ ▼ ▼ ▼
model-apps canvas-apps mobile-app code-apps-preview
dispatcher page asset lookup field techs ops dashboard
(triage/schedule) (history) (offline) (analytics)
mcp-apps widget ──▶ visualizes the failure-risk MCP tool
── all of it lives in one Dataverse solution ──
── power-pages ALM skills package & deploy it ──
Every box above is the same Dataverse foundation from Step 0, viewed and edited through a different client — and every box was built by describing it in plain language to a CLI agent, with a plugin supplying the domain expertise.
Where to go next
- Read before you run. Open a skill's
SKILL.md(Part 2) to see its playbook and itsallowed-toolsboundary before invoking it. - Turn on auto-update (the installer does this) so the plugins stay current — several are actively versioned.
- Start with one surface. You don't need all seven; pick the plugin for the layer you're building and add others as the solution grows.
That's the series: what these agentic CLIs are, how to pull down every Power Platform plugin, how to understand what each one does, and how they combine into a single solution — all from the terminal, in Copilot CLI or Claude Code.
Sources: microsoft/power-platform-skills · Get started with the Power Pages plugin
