Senior Solution Engineer · Apps & Agents
Microsoft Power Platform · Copilot Studio · Dataverse · PCF
I build agents and applications on the Microsoft Power Platform, and the automation and governance that keeps them running once they are real.
This profile is a pattern library. Each repository demonstrates a reusable approach to a common problem, published so others can adapt it, and is labelled with how far it has been taken:
| Maturity | Meaning |
|---|---|
 |
Builds or imports, with tests or a repeatable check. Use as a starting point. |
 |
Scripts or skills you can run today, validated in CI. |
 |
Architecture, prompts and tested guard code. Not a deployable solution. |
Every repo states plainly what has been verified against a live environment, what is covered by tests, and what is not yet verified. Dated platform findings are included, because they save the next person days, and they are flagged when the platform moves on.
These are samples, not products. Provided as is, not production ready, and not affiliated with or endorsed by Microsoft. Review, test and harden before any real use.
|
Problem: the Copilot Studio VS Code extension targets the standard harness. Agents on the GitHub Copilot harness get no clone-edit-sync loop, so the harness built for the most capable agents has the least local tooling. Approach: a VS Code plugin whose skills scaffold, package, review and deploy those agents by
driving |
Problem: most multi-agent demos are one agent wearing several hats. Teams cannot tell when orchestration earns its complexity, so they over-engineer four agents that route badly. Approach: an orchestrator with four domain agents and cross-cutting skills, the decision framework for when not to split, an idempotent Dataverse schema script to build against, and the same shape mapped to four other industries. |
|
Problem: extraction is rebuilt every project because the schema is hardcoded, scanned documents silently return nothing, and model output is trusted as-is. Approach: user-defined capture fields, scan detection with a vision fallback, output validation that enforces the contract in code, a human validation gate, and dated AI Builder findings. |
Problem: safety tooling is retrospective. It records incidents well and prevents them poorly. The procedure that matters sits in a library nobody opens at the job site. Approach: a JSA sized for the two minutes a worker has, photo hazard identification, and deterministic guards so the emergency stop, procedure allow-list and escalation never depend on the model. |
|
Problem: "how do I put my agent inside my app?" has no good published answer. Users get bounced to a separate surface, and the SSO path can prompt them to sign in again. Approach: a PCF component embedding a Copilot Studio agent in canvas apps and model-driven forms, with OAuth card interception for silent SSO (unit tested; live tenant unverified), record context from the host form, untrusted-context handling and an offline demo mode. |
Problem: the Planner connector does not see Planner Premium. Premium plans live in Dataverse as
Approach: a read-only connectivity and permissions check, the table map from live metadata, an example flow you retrofit to any process, and six recipes from read-only digests to plan templates. Rehearse with mock tables without a Premium licence (a Dataverse environment is still needed). |
|
Problem: organisations deploy agents with no way to answer "what will this cost at scale, and where is it being consumed?" Cost becomes visible when capacity runs out. Approach: collects consumption from the supported Power Platform licensing API with a fallback to the admin centre endpoints, flags consumption in environments with no allocation, alerts before capacity runs out, and allocates every credit to a cost centre for chargeback. |
New patterns are published as they are generalised and tested. Contributions and corrections are welcome, particularly verification results from your own tenant. Each repo has an issue template for exactly that. |
| Principle | In practice |
|---|---|
| Generic, reusable patterns | Each repo stands alone. No customer data, branding or configuration. |
| Explicit about certainty | Maturity labels, verified versus unverified, and dated findings that are revisited when the platform changes. |
| Guardrails in code | Where a wrong model answer matters, the rule is enforced deterministically and tested, not only asked for in a prompt. |
| Built for handover | Configuration over customisation. Environment variables, not hardcoded IDs. Scripts that change an environment say so. |
| Documented for the reader who is stuck | Known gotchas, licensing traps and failure modes, not just the happy path. |
Every repository states what it does, how far it has been taken, and what is not yet verified.
Sample code. Provided as is, without warranty. Not production ready. Not an official Microsoft product, and not affiliated with or endorsed by Microsoft.