Power Platform Has Pro-Code Tooling. Agents Make It Useful.

Most Power Platform bugs do not announce which surface owns them.

A user clicks a button on a Power Pages site. The page runs JavaScript. The JavaScript calls /_api/cloudflow/v1.0/trigger/{flowId}. The cloud flow writes a Dataverse record. The write fails because a table permission, environment variable, or flow input is wrong.

If you start inside the nearest designer, that bug looks like a page problem. Then it looks like a flow problem. Then it looks like a Dataverse problem. You can lose an hour clicking through the right platform in the wrong order.

Power Platform already has enough pro-code tooling to make that loop less blind. The CLI, exported source formats, Dataverse Web API, Azure DevOps APIs, and git all exist. Agents make those surfaces more useful because they can read the work item, exported artifacts, schema, and diff in one pass.

The maker portal stays where most changes happen. The terminal becomes the agent’s interface into the context around the change.

The tooling is already there

The pro-code surface is broader than it looks from inside the portal.

The pac CLI (Power Platform CLI) handles authentication profiles, solution clone/export/unpack, solution check, and Power Pages download/upload. It’s the entry point for almost everything else in this list.

Exported source files turn solution components into something a text editor and a diff tool can work with. Canvas apps have .pa.yaml source files. Solution-aware Power Automate workflows export as JSON. Model-driven artifacts surface through customizations.xml, FormXml, and AppModule XML. Power Pages sites move through pac pages download. Some of these files are rough to edit by hand. Use them for inspection first.

The Dataverse Web API (overview) gives you table metadata, columns, relationships, and data. It answers the questions the portal makes you click through a half-dozen tabs to answer.

Azure Boards and the DevOps REST APIs (az boards, Work Items REST) let you pull the title, description, acceptance criteria, and comments for a work item from the command line.

Git wraps all of the above. Initializing a repo over an unpacked solution gives you a baseline, a diff, and a rollback that didn’t exist when the artifacts only lived in the environment.

This runs alongside the maker portal. The pro-code loop gives the portal context before the click and evidence after the publish.

Why it changes the work

Four things change once those surfaces are in the loop.

Context that lives outside the portal becomes legible in one place. The work item, the Dataverse schema, the exported artifacts, and the prior baseline can all sit in a single repo. Before the developer opens a designer, they can see what changed, why, and where the behavior lives. After the change, the diff explains what they did.

Misdiagnosis goes down. Power Platform bugs are easy to misplace. A “canvas issue” is sometimes a flow input problem. A “flow issue” is sometimes an environment variable or table permission problem. A “portal issue” is often JavaScript calling a cloud flow through /_api/cloudflow/v1.0/trigger/{flowId}, with the real failure in the exported workflow JSON or the Dataverse record it writes. Reading across the artifacts before touching a designer prevents an hour of clicking in the wrong surface.

The agent gets a real brief. A useful agent workflow needs more than “look at this app and fix it.” It needs context, intent, constraints, artifact pointers, examples, verification, and stop conditions. That shape is the difference between an agent guessing and an agent investigating.

Review gets evidence. The reviewer does not have to reverse-engineer a portal session from memory. They can read the surface map, the changed components, the checker output, the test notes, and the diff.

The workflow

The workflow runs in three passes. First, run the commands manually so you know what they do. Second, let the agent call read-only commands when the task needs fresh evidence. Third, turn the repeatable parts into a project script so the agent’s context window can be spent on judgment, not on rediscovering the export folder.

The steps below are the human-readable version.

1. Pull the task

Start with the work item. Pull the title, description, acceptance criteria, linked bugs, and the latest useful comments.

az boards work-item show --id 12345

Keep the output scoped. The work item title, acceptance criteria, linked bug, and the last few meaningful comments are usually enough. Dumping the whole backlog dilutes the context.

2. Write the agent brief

Before pulling every file in sight, write the small contract the agent should operate inside. The pattern is the same one I use for agent work elsewhere: context, intent, constraints, artifact pointers, expected output, and verification.

## Context
- Work item 12345: short title and acceptance criteria.
- Environment: dev tenant, solution MySolutionUniqueName.
- User path: Power Pages form submit triggers a cloud flow and writes Dataverse.

## Intent
- Find which surface owns the failing behavior before recommending a change.

## Constraints
- Read-only investigation until a human approves the implementation surface.
- Do not publish, import, delete, or modify environment data.
- Keep customer data, tokens, tenant IDs, and connection details out of the brief.

## Evidence to inspect
- Work item summary.
- Unpacked solution files.
- Power Pages source for the affected page.
- Flow JSON for the triggered cloud flow.
- Dataverse metadata for the target table.

## Expected output
- One-paragraph surface map.
- Likely owner of the change.
- Specific files or components to inspect next.
- Test checklist tied to the acceptance criteria.

## Verification
- Confirm active `pac` profile.
- Confirm which artifacts were pulled and when.
- Report any missing evidence instead of filling gaps with guesses.

This keeps the agent from treating Power Platform like one large blob. It also gives the human an audit trail. If the agent recommends a flow change, the brief should show why the issue is not a canvas formula, table permission, or page script problem.

3. Verify the environment

Confirm which tenant and environment the CLI is pointed at before pulling anything. pac auth list shows the profiles on this machine, and pac auth who prints the active one. Use pac auth select to switch.

pac auth list
pac auth who
pac auth select --index 2   # if you need to switch

When the agent is driving, have it report the active profile before any read that depends on environment context. A misrouted profile is the cheapest mistake to prevent and one of the most expensive to clean up.

This is also the first authority boundary. The agent can verify, export, unpack, diff, summarize, and produce a recommendation. A human should approve anything that publishes, imports, modifies data, changes permissions, rotates secrets, or changes which environment is being touched.

4. Pull the solution and put it under git

Use pac solution clone when you want a structured solution project locally.

pac solution clone --name MySolutionUniqueName --outputDirectory ./power-platform-src

Use pac solution export and pac solution unpack when you want a snapshot of the current environment state as files.

pac solution export --name MySolutionUniqueName --path ./exports/MySolution.zip
pac solution unpack --zipfile ./exports/MySolution.zip --folder ./power-platform-src

Then commit a baseline. Local git is fine if the project has no remote. The baseline is what makes the post-change diff meaningful.

cd ./power-platform-src
git init
git add .
git commit -m "baseline before work item 12345"

One caveat for Power Pages: the source files are accurate at the moment of pac pages download, but browser-based Visual Studio Code for the Web edits write directly to the environment without going through pac. Re-pull when behavior depends on the live page.

5. Add Dataverse context

The solution files describe the artifacts. Dataverse describes the data those artifacts read and write. Use the Web API to pull whatever schema or reference data the task depends on.

A typical call to confirm the shape of a table before recommending a schema change:

GET https://yourorg.crm.dynamics.com/api/data/v9.2/EntityDefinitions(LogicalName='account')?$select=LogicalName,SchemaName,PrimaryIdAttribute&$expand=Attributes($select=LogicalName,AttributeType,RequiredLevel)
Authorization: Bearer <token>
Accept: application/json
OData-MaxVersion: 4.0
OData-Version: 4.0

Authentication here is a separate boundary from pac. The Web API uses OAuth, an authenticated app context, or an authenticated runtime context. Do not assume a selected pac profile is also a bearer token for Web API calls.

Keep the queries narrow. Every file an agent reads costs tokens, and a 5,000-line canvas YAML or a raw cloud flow JSON eats context fast. Pull broad evidence once, then feed the agent only the files and queries that bear on the current task.

This is the second authority boundary. Schema metadata is usually enough for diagnosis. Actual row data should be narrow, masked when possible, and pulled only when the work item depends on it.

6. Map the implementation surface

Before changing anything, trace the feature outward from what the user does. What did they click? What page, screen, form, command, or flow did that touch? Which artifact defines it? What runs next, and where does the write land?

The diagnostic example from earlier is a typical chain: Power Pages JavaScript calls /_api/cloudflow/v1.0/trigger/{flowId}, which runs a cloud flow defined in JSON, which writes a Dataverse record bound by table permissions. Each link is owned by a different artifact in a different format. Naming the chain before touching a designer is how you avoid implementing the wrong fix in the right tool.

This is where the agent earns its keep. Given the work item, the portal JavaScript, the cloud flow JSON, the Dataverse schema, and the local diff, it can produce a one-paragraph surface map:

The failing path starts in the Power Pages submit handler, but the page only forwards the payload. The cloud flow owns the validation branch, and the write lands in the vendor request table. The next inspection target is the flow action that maps the submitted category to the Dataverse choice column. The page script and table permission are supporting evidence, not the likely fix surface.

The exact nouns will change by project. The shape should not.

7. Keep the designer change traceable

The designer is still the write surface for a lot of Power Platform work. That is fine. The mistake is treating the click path as the explanation.

Before changing anything, write down the component the surface map pointed to, the value you expect to change, and the user-facing behavior it should fix. If the issue is table permissions, the note should say which table and which web role. If the issue is a cloud flow call from Power Pages, the note should name the JavaScript entry point, the flow trigger, and the Dataverse write it feeds.

Then make the smallest designer change that matches that note. The agent does not need to click for you. It needs to keep the chain intact while the designer hides the real artifact behind panels and property sheets.

8. Export again and inspect the diff

Once the designer change is published, pull the solution state again and compare it to the baseline.

pac solution export --name MySolutionUniqueName --path ./exports/MySolution-after.zip
pac solution unpack --zipfile ./exports/MySolution-after.zip --folder ./power-platform-src
git diff

The diff is where the workflow pays for itself. The agent can read it and explain what changed: which screen, which Power Automate JSON, which environment variable, which FormXml node. It can also flag changes that look unrelated to the work item, which is how scope creep usually gets caught.

Treat the diff as evidence with noise. Some Power Platform exports include metadata movement. The agent should separate expected change, incidental platform churn, and suspicious unrelated change.

9. Validate and hand off

Run solution checker, then the browser test, Playwright test, or manual test plan for the work item.

pac solution check --path ./exports/MySolution-after.zip

After validation, the agent can assemble the reviewer artifact. Keep it short enough to read:

## Review brief

Work item: 12345

Surface map:
- User path: Power Pages form submit -> cloud flow -> Dataverse vendor request row.
- Change owner: Power Automate flow validation branch.
- Supporting surfaces: page JavaScript payload shape, Dataverse choice metadata.

Changed components:
- Cloud flow: Vendor Request Submit
- Environment variable: none
- Dataverse schema: none
- Power Pages files: none

Acceptance criteria:
- Category value maps to the target choice column.
- Failed submit shows the existing page error state.

Validation:
- `pac auth who` checked active dev environment.
- Solution exported and unpacked after publish.
- Solution checker run against post-change zip.
- Manual submit tested with valid and invalid category values.

Open decisions:
- None.

Unrelated diff:
- Export timestamp metadata only.

The implementation guide becomes one piece of a larger evidence package instead of a verbal walkthrough.

10. Script the repeatable parts

Once the project shape is clear, fold the repeatable steps into a project script. A simple bash version looks like this:

#!/usr/bin/env bash
set -euo pipefail

SOLUTION="${1:-MySolutionUniqueName}"
STAMP="$(date -u +%Y%m%dT%H%M%SZ)"
OUT_DIR="./exports"
SRC_DIR="./power-platform-src"
SUMMARY="$OUT_DIR/$SOLUTION-$STAMP-summary.md"

mkdir -p "$OUT_DIR"

echo "Active pac profile:"
pac auth who | tee "$OUT_DIR/$SOLUTION-$STAMP-auth.txt"

pac solution export --name "$SOLUTION" --path "$OUT_DIR/$SOLUTION-$STAMP.zip"
pac solution unpack --zipfile "$OUT_DIR/$SOLUTION-$STAMP.zip" --folder "$SRC_DIR"
pac solution check --path "$OUT_DIR/$SOLUTION-$STAMP.zip" | tee "$OUT_DIR/$SOLUTION-$STAMP-check.log"

{
  echo "# Power Platform evidence packet"
  echo
  echo "- Solution: $SOLUTION"
  echo "- Export: $OUT_DIR/$SOLUTION-$STAMP.zip"
  echo "- Sources: $SRC_DIR"
  echo "- Auth: $OUT_DIR/$SOLUTION-$STAMP-auth.txt"
  echo "- Checker log: $OUT_DIR/$SOLUTION-$STAMP-check.log"
  echo
  echo "## Git status"
  git -C "$SRC_DIR" status --short || true
  echo
  echo "## Changed files"
  git -C "$SRC_DIR" diff --name-only || true
} > "$SUMMARY"

echo "Summary: $SUMMARY"

Wire in az boards work-item show and a scoped Dataverse query as the project requires. The developer runs the script before a task. The agent runs it when evidence is stale. The summary gives the agent a small first read. It can open specific files only when the summary points there.

Closing

The immediate win is less blind churn: better task orientation before the first change, a cleaner diff after the last change, and a handoff that explains the work instead of asking a reviewer to reverse-engineer it from a portal and a zip file.

The longer-term win is a reusable project trail. Pulled artifacts in a known repo layout. One script that can run again. The surface map, review brief, and test plan beside the artifacts they explain. When a project produces a useful pattern, save it where the next task can use it.

Power Platform already has enough engineering surface for this. Wiring those tools together is what turns the maker portal from a black box into a system you and your agent can actually drive.