DEV Community: david wyatt

Creating a Custom Agent in 5 Minutes

david wyatt — Mon, 14 Sep 2026 10:27:27 +0000

Agents are cool, we know that, but making them can seem daunting. But actually it can be super easy, with the right tools and approach, let me show you how.

Call out here, this is not going to be the most powerful, game changing agent in the world, but its going to be useful, and the ROI is fantastic.

Pre-work
Design
Build
Example

1. Pre-work

First things we need to select a platform, as we want this to be minimum effort, and minimum cost, we are going to use M365 Agent Builder. This does require a M365 Copilot License (so not actually minium cost), but there will be no per use cost, which is the most important thing you need to consider when building your agent.

The next most important thing is a usecase. I see this to often, a solution looking for a problem. If you build an agent without a genuine usecase its always going to fail, find a problem first, and then if an agent (big if) can solve it then build.

Another callout, before AI the build investment meant you had to pick the right solution, App/Agent/Dashboard/etc, before building. But now I would recommend spinning up a PoC per solution, and then you can find out which is best

My usecase is reports, I spend a lot of time researching and then creating short technical reports on them. Before I would spin up Power Point presentations with help from the Research agent. But I found researcher wasnt the right level, and Power Points were either overkill or not interesting enough. Ive spoke recently about how much I now use single page HTML files, so my agent is going to create me a HTML report for whatever I need.

Before we start we still need requirements, and for this small project mine are:

Include my own context first
Optional to include external data (websites etc)
Varied UI (I could go with a standard template but I want to mix it up)

2. Design

We know what we want and the platform, so now the design. Agent Builder has:

Instruction file - system prompt
Skills - dynamic content
External Sources - SharePoint, Teams, Outlook, etc

Instruction File

This needs to cover
Logic/Branching - in this case does the user want to use external resources, themes, mockups
Process - steps to take, decide on external resources, then theme, then if mockup, create mockups if needed, refine mockup, create end report
Error Handling - what to do if cant find valid resources, size constraints, file access, etc
Gotchas - callouts, NFR's, things to avoid, like in this case don't use separate CSS/JS files, no external sources, and no local/sessionStorage

Skills

Skills had capability to your agent, either context (.md file), scripts (.py file), or template files (.pptx/.docx/.xlsx/etc). To keep things simple I'm just going to use a context skill, and that is the frontedn-design skill from Anthropic. This is still one of my favourite skills and it can massively improve the UI of your app/report.

Skills can also be branching, so you can have 2 skills with contradictory information, and either the instruction or upstream skill can decide which to use. They are super powerful and something you should leverage.

Skills are everywhere, and it can feel safe just to copy paste them into your agent, but be careful. Skills are a prime surface for prompt injection, make sure you read them fully, and not in a markdown viewer, as they can have hidden html comments in them.

External Sources

There are 4 external sources:

Knowledge - this is specific external data, like OneDrive files, SharePoint sites, and even Teams chats/meetings. The key thing about these is they are live, so they are constantly updated. This brings benefits of being up to date, with the risk of performance impact by incorrect data/context overload

Work content - this is pretty much Work IQ, it brings in the logged in users data from the same external data as Knowledge, but this is not targeted, its the users data. It good if you need to tailor responses to the logged in user, like their chats or their emails (e.g you could have an agent that helps organise your week, that would need access to just logged in users accounts). There is also Copilot Connectors which are external systems linked to your graph, they currently are only read only in Agent Builder.

All of Agent Builder is 'on-behalf of' connections, so that means not just Work Content, but Knowledge sources as well require the agent user to have access to the data. This is checked at runtime, so if a user loses access the agent does as well.

Web search - does exactly what it says on the tin, allows the agent to search for external content

Attachments - these are documents that you want all users to be able to access for context (example if you had a word doc as a knowledge source then the user would need access to it, if you attach it then every user has access to it).

As my agent is relatively simple and I want tight control Im only using Web search functionality, with the instruction deciding if the agent should use it.

3. Build

Once you have your design and resources the key build is the instruction file. This is what makes your agent do what you want it to do.

My workflow is normally:

Get Copilot to create me a instruction file
Go over the result, removing unnecessary parts and trying to make the language more deterministic/consistent. The first line describing what the agent does is really important, I generally write that myself
Test, learn, update, repeat

And that's it, you can now publish and share your agent.

4. Example

If you want to see my Report Builder agent, this is the instruction:

You are a report builder that creates interactive and powerful HTML files to share information provided by the user.

## Purpose
Create polished, single-page HTML reports from user-provided information.

## General Guidelines
- Always return a single-page HTML file with CSS and JavaScript embedded in the same file, do not create a power point or word document.
- Do not use localStorage or sessionStorage
- Check whether the user has uploaded a file before deciding how to handle external research.
- When a file is attached, use external sources or APIs only after the user explicitly approves internet research.
- When no file is attached, presume the user wants external internet research and treat permission as approved.
- Keep the report accessible, responsive, and easy to share.
- Mockups need to be varied, unique, and importantly different; use genuinely different layouts and styles, including one strong alternative that intentionally departs from the user's requested theme.
- **Whenever the user approves mockups, deliver one downloadable HTML file containing all five fully rendered mockups. Never return mockups as prose, Markdown, ASCII wireframes, or design descriptions.**
- The mockup HTML must begin with a clear introduction that explains the design-selection purpose and any important context.
- Place persistent or sticky navigation at the top, with links that jump to each of the five mockups.
- Present each mockup as a substantial, visually complete page section with its own layout, typography, colour treatment, representative content, and responsive styling.
- Keep all five mockups, the introduction, navigation, CSS, and JavaScript together in the same self-contained `.html` file.
- After attaching the mockup HTML file, briefly ask the user which numbered direction should be used for the final report.


## Required Preflight
Before researching or creating the HTML, check whether the user uploaded a file.

If a file is attached, ask all three questions together:
1. May I search the internet for supporting information? If approved, review no more than two sites and include them in a Sources section at the bottom of the report.
2. What colour theme and visual style should I use?
3. Would you like five design mockups before I build the final report?

If no file is attached, presume internet research is approved and ask only:
1. What colour theme and visual style should I use?
2. Would you like five design mockups before I build the final report?

Wait for the user's response to any required questions before continuing. Do not infer internet approval when a file is attached.

Use defaults or proceed directly to the final HTML only when the user explicitly says “choose for me,” explicitly declines internet research when a file is attached, or explicitly declines mockups. If the user answers only some required questions, ask only for the missing choices.

## Step-by-Step Instructions
1. Read the provided documentation and identify the report's purpose, audience, and required content.
2. Check for an uploaded file and run the appropriate preflight questions.
3. If a file is attached, search the internet only after explicit approval. If no file is attached, treat internet research as approved. In either case, review no more than two relevant sites and retain their links for the Sources section.
4. If mockups are approved, run the `frontend-design` skill and create one self-contained HTML selection page with an introduction, top navigation, and five fully rendered, distinctly styled mockups.
5. Attach that HTML file and ask the user to select a numbered direction before producing the final report.
6. Apply the selected or explicitly delegated colour theme and style.
7. Create the final single-page HTML file.
8. Check that all content, styling, scripts, navigation, and approved sources are included in the file.

## Skills
- When the user approves design mockups, run the `frontend-design` skill to create the single HTML selection page containing all five visual options, the results need to be unique and varied, be creative, don't just follow the skill, be inspired by the skill.

## Error Handling
- If required source material is missing, ask for it before building the report.
- If approved web research does not yield useful sources, say so and continue using the user's content.
- If a requested design cannot be represented accessibly, provide the closest accessible alternative and explain the adjustment briefly.
- If the five mockups cannot be packaged into one HTML file, do not substitute text descriptions; explain that the file could not be produced and ask the user to retry.

Mockups:

Final report: https://github.com/wyattdave/Power-Platform/blob/main/HTML Reports/gpt6_astra_report 1.htm

And that's it, within an hour (yep the 5 minutes was total click bait) you can have an agent that helps you, I use the HTML Report Agent most days, and it saves me so much time.

😎 Subscribe to David Wyatt

Copilot Studio and the 5 Different Agent Builders

david wyatt — Mon, 07 Sep 2026 07:47:42 +0000

We all know Microsoft has been moving at full speed when it comes to AI and agents, and with pace comes changes (and re-naming 😎), but it also brings duplication and overlap. And thats how we have some how arrived at 5 different agent builders available in M365/Power Platform. Note I havent included Foundry/Azure builders because they are more in proc-code world, and the M365/Power Platform have so much overlap with governance, admin, and infra it made sense to group them.

So what are the 5 different agent builders, well they are:

Agent Files (SharePoint)
Agent Builder
Microsoft Copilots
Copilot Studio
Copilot Studio GitHub Harness

Lets take a look at each, and then give a big picture on when to use what

Agent File / SharePoint

This was the first agent builder that was available with the M365 Copilot licesne (or whatever is called now). These agents were really just a manifest file, containing a json object, that would be executed by a central engine.

They were stored locally as .agent files, and were most prevelent in SharePoint. When you open Copilot in a SharePoint site you would see a list of agents in that site (they were simply .agent files in Documents/Site Assets/Agents, and were published by simply moving the file to the published sub folder), and you could also create a new agent from that screen.

They were limited to just SharePoint knowledge sources, had an upgrate to Copilot Studio button (that was always coming soon).

The actual .agent files could do more though, with external websites as knowledge sources and a proposed way to call autonamous agents/flows, but I never saw if that came to fruiation. They were planned as they way to create custom agents for M365 Copilot, with the idea you could spin them up for projects and other focused activities.

The agent files could be ran from 3 locations:

SharePoint
Teams (simply add to a chat)
M365 Copilot (open the .agent file while in OneDrive)

Callouts

As of now it looks like they have been deprecated, you can no longer make them in SharePoint, and I haven't see any updates for a while. Though the .agent file still works in Teams and M365 Copilot.

Governance is interesting as its just a file, so there is little control you can do through MAC (Microsoft Admin Center), its not impacted by PPAC (Power Platform Admin Center).

Cost - free with M365 Copilot
Location - SharePoint/OneDrive

Agent Builder

This is what replace .agent files, they are no longer stored locally (I believe in a Cosmo DB database somewhere).

Until recently they were similar to .agent files, with knowledge sources only, but they just got updated to enable skills.

Skills are awesome tools that enable:

Branching logic - as the skill contains custom context that the agent can chose to use
Compute - has Python interpreter so can run Python scripts
Reference/templates - like Power Point templates or layouts

Microsoft also calls these plug-ins, so if you see that name know its the same.

To create a Skill/plugin you just need to have a folder with your skill name, a file names Skill.md (which contains your context/prompt/knowledge/etc), and optional script.py file and/or template file (.pptx/.docx/.xlsx/txt/etc).You then zip the folder and you have your plug-in.

Callouts

The model being used its definitely not the best (Im 99% certain its a GPT model, probably Tera), I found it can be a little inconsistent, though that can be fixed with a good instruction.

There are also some attachment limits - max 20 files, no zip files.

These are fully governed in MAC and Agent 365, I haven't seen how to limit sharing but you can control publishing to M365 Copilot for others to find.

Cost - free with M365 Copilot
Location - Cosmo DB under M365

Copilot Studio Light

This is the hidden agent I found that motivated this blog, I've named it Copilot Studio Light, which has been used before but feels right for me (it could also be called Copilots for Microsoft 365).

To get to them you have 2 routes, first in Copilot Studio scroll to the bottom and click on Copilot for Microsoft 365 (now you know where I got the name from 😏).

Here you will see a list of the hidden Copilots. You can also get there by using this link: https://copilotstudio.microsoft.com/environments/{{environmentID}}/bots/fp/msft_Microsoft365Copilot/agents, just add in your environmentID.

When you click create add/create agent you see the normal looking Agent Builder inputs.

But that's just a trick, as once its completed you can now add tools.

So in the Copilot Studio light you have full tools, you can call connectors, MCP, and Agent Flows.

Its pretty much Copilot Studio but with out Topics.

Callouts

There are a few features like evaluation, sub agents, monitor, activity missing, and you are limited to publishing just with Teams and M365 Copilot.

It is fully governed by PPAC, with DLP controlling it, though they do not appear in all reports. It is also consumption based if you don't have a M365 Copilot license, so will need Copilot Studio credits for some users (though not for development).

I haven't been able to add them to a solution either, so it doesn't appear to be solution aware.

Cost - free with M365 Copilot or Copilot Studio Tokens without
Location - selected Power Platform environment

Copilot Studio

The OG, everyone knows this agent builder, so I wont go into too much detail.

It is still possible to turn off all of the AI capabilities and make this a "Classic" agent, purely using the topic workflows. But the mix of deterministic topics and generative answers gives it its real power.

Add in the ability to call child agents and run them as autonomous agents (triggered by non-chat interactions like emails) means it has significant advantages over Copilot Studio Light.

Callouts

The pricing is a lot more complex, with costs depending on specific combination of AI events.

Topic creation, although LowCode, still requires development time compared to all previous (and the next) builders.

Its fully within the Power Platform, so under DLP and managed environment sharing controls. It is also solution aware (in fact it can only be unlike Flows and Apps), meaning it is fully ALM compliant.

Cost - free with M365 Copilot or Copilot Studio Tokens without
Location - selected Power Platform environment

Copilot Studio GitHub Harness

The Copilot Studio GitHub Harness is the latest and most modern agent builder. It follows other agentic tooling like Claude Code, Codex, and of course GitHub Copilot. This means all of the legacy bot builder design is removed, so no topics, instead it is all about skills. I went into more detail about skills/plug-ins in Agent Builder, so this is the same only more powerful (more skill uploads, accepts zip files, and can run longer more complex sessions).

In my experience I have also found generally better results/user experience when compared to other agents:

more accurate,
more consistent
more natural language

It also has memory (which allows the agent to store key information between chats) and deep WorkIQ integration. WorkIQ is Microsoft's "Intelligence Layer", which means it can quickly pull all of your Microsoft information (emails, teams chats, etc), and can use that "big data" to answer/predict more accurately.

Callouts

The big callout here is costs, unlike in all other builders you are charged while developing. So all tests runs, skill building, etc costs real tokens. I suspect this is because its using GitHub Copilots infra, and they are charging the Power Platform team full price.

That also means there is no free access to M365 Copilot license holders, and because the models are better/reason more, I have also seen slightly per interaction costs. Yep this version will cost you more.

Cost - Copilot Studio Tokens
Location - selected Power Platform environment

So with that in mind which agent builder should you use, well I would say nearly all have a particular main use case:

Agent files - don't use them

Agent Builder - for projects I think this is ideal, as it can only pull data its great for research and project updates. It can also be used for team/department information, but that really should be a SharePoint site with sharepoint.md/skill files.

Copilot Studio Light - again for projects, but where the use case is beyond just reading. So if you need to create tickets, update trackers, etc, then the this version maybe right

All of the above are in my opinion driven to be more tactical, i.e. they have a specific use case which has a fixed lifespan. The short use time is why you wouldn't invest development time in full Copilot Studio

Copilot Studio - for now this should be your default choice when builder scaled, business imported agents. Its a great choice for a new UI for different software, and can be an awesome orchestrator for complex workflows.

Copilot Studio GitHub Harness - this is the future, it delivers the best results and quickest development, but with costs this should be used for high value, business critical solutions. There is a lot of overlap with Copilot Studio, you just have to look at the users (if they M365 Copilot License) and the ROI on each user interaction.

😎 Subscribe to David Wyatt

AI, Fairy's, and Agile

david wyatt — Mon, 24 Aug 2026 06:07:45 +0000

Now hose 3 words don't generally go together, but trust me its not just clickbait (well just a little).

I had an epiphany recently, and I want to take you on that journey.

Vibe coding has become a key part of nearly all my workflows for a while now, and most of the time its not to create an end product, but to enable me to do something else.

Converting SharePoint pages to markdown, create an app to do that
Transforming data, chuck it into GitHub Copilot and ask it to create an interactive HTML file with the data

But now its even starting to part of my personal life (not like that 😉), and that's why I'm writing this blog.

One Sunday morning my 6 year daughter was showing me the Rainbow Magic Fairy Books she had read. She was super proud of the books she had read and also took great pleasure in telling me her favourite and the ones she wanted to read next. As there are over 300 books to read she was asking me to search for them so she could write a list, and that's when I thought how cool it would be if she could have an app to do it.

A great place to start when vibe coding is Chrome Extensions or Progressive Web Apps. They have some key benefits:

Chrome Ext can be shared as zip files or published for free in Edge store (and a small one off fee in Chrome Store),
PWA's can be hosted for free in GitHub and other hosting sites
Both can get away without a server/backend
Chrome Ext can get around cors for external api'
Both can be tested easily locally (no build steps)
Both use standard web tech so LLM's are very good with them
PWA can also be installed, so they can act just like a full application on a laptop, Android and IOS (with no need to deal with different versions and the painful App/Play stores).

So the idea was to create her a PWA with all of the books that she could review and track. I could then install it on her tablet for her to use.

I sat down with her for a couple of minutes to discuss what she wanted.

She wanted to be able to see all the books, track the ones she had read, and have her favourite list.

I also thought of a couple of NFR's:

A way to export/import saved data, so she can move between devices, and avoid complexity of a backend and api
To fully work offline, including all book covers etc

And thought about a little gamification, adding in badges for milestones.

This was my initial prompt:

i want to create a mobile/tablet app to track my daughters reading. I want to use a progressive web abb (simple html/css/js) that saves locally what she has read, but that data can be exported/imported between devices. the web app should be themed like the rainbow princess books. it should have every book (ideally every book cover) and if possible grab a small bio on each book. my daughter should be able to search for books, add to favourites and mark as read. When she reads certain mile stones she would get a badge/fairy achievement. these achievements should be shown in a screen/section. the books can be stored local or grabbed from api. some references are: https://rainbowmagic.fandom.com/wiki/List_of_Fairies https://en.wikipedia.org/wiki/List_of_books_written_by_Daisy_Meadows https://rainbowmagic.fandom.com/wiki/Princess_Fairies though you may need more data

The prompt took a few mins to run and it crashed and burned with the book covers, all of theme were just emoji's, so I did a bit of research and found an api with all of the bio's and covers.

i need all of the book covers for this web app (the generated ones are not very good). i found this site with them https://openlibrary.org/authors/OL1452170A/Daisy_Meadows

After that it was pretty much perfect. I sat down with my daughter and she had a quick go on it, she quickly told me she wanted to order the favourites, and wanted a way to track what she owned.

A quick update and now the favourites could be ordered.

Next she spotted that she wanted the read books in order she read them.

After that she realised that scrolling down 300 books could take a long time to scroll back up. So a scroll to top was added.

Finally she spotted that some of the book covers were missing, so I prompted to load in chunks, with the first 20 on load, and then each next block of 20 until all cached locally. This stopped the images from only loading when scrolled to and api throttling when she swiped like crazy down to book 300!

Chuck in some small updates around misaligned elements and poor UX (the close popup icon would scroll out off screen when reading bio) that I added and it was done.

So what was my epiphany, was in under and hour I had managed to create exactly what a very picky 6 year old wanted:

It had feature creep
Poor testing
Changing requirements
Tight high pressure delivery time (she gets angry 😉)

Sound familiar, sound like every software delivery you had done. And this was easy, and the simple reason is I didn't follow agile:

No detailed requirements
No product demos

With AI we now are able to pivot so quickly, that the effort that use to go into making sure we get it right first time isn't necessary. We can just do it again. We simply get in a feedback loop, of build, test, build, test.

It is so much easier for a end user to tell you "What they don't like" rather then "What they do like", because 9 times out of 10 they simply don't know.

So I'm now thinking that my process should be:

Get the Simple Design Goal, i.e. what problem are they trying to solve and why.
Get the first description of what they expect, for a change the vaguer the better
Design NFR's
Build
Put it in the users hands and get feedback
Build, feedback, Loop until complete

If there is a complex backend, mock this up so that the user can use it to give feedback, once happy then do everything off client.

If possible you want the developer with the user when they are testing, you can even do hot updates with them in one session.

I know this goes against Agile, but the simple truth is Agile was built for a world where development was expensive and a bottle neck. With AI that's not the case, code is cheap and quick. Add in technology moves so much quicker, for example planning more then 3 months in advanced to create a PI on the Power Platform is impossible, new features hit with zero warning. 2 week sprints can feel like a long time when you can build in hours instead of days. Processes need to adapt to the pace of AI development, and if you still:

Cant do that as wasn't in PI planning
Need to get that approved by everyone before you can start
Have Enabler SLA's that run in the days not hours

you wont be able to benefit from the AI fully. Think about it, how can it be right to:

wait weeks for requirements
wait weeks for security & arch reviews
wait days for UAT sign off
wait days for change requests and go live approvals

when the actual building of the solution takes hours.

If you have children who love Rainbow Fairy Books check out https://wyattdave.github.io/Lottie-the-Fairy/, and if they don't like them what do they like, what could you cool thing could you make just for them.

As always the code is open source and can be found on GitHub

😎 Subscribe to David Wyatt

What Went Wrong For Copilot

david wyatt — Mon, 17 Aug 2026 05:55:20 +0000

There have been 3 amazing tools launched by Microsoft recently:

Code Apps
Cowork
New Copilot Studio (aka GitHub Copilot Harness)

These tools had me incredibly excited, as they not only allowed me to do my job better and quicker, but also enabled me to do things that weren't possible.

But then things started to go a little wrong:

Vibe.powerapp.com (the user friendly version of Code Apps) which I was expecting to allow citizen dev's to use it is still half finished and in preview (launched almost a year ago 18th November 2025). Things like this either get traction and hit GA, or they die in preview (often never fully deprecated).

Cowork moved to an expensive pay as you go model.

New Copilot Studio moved to charging for development and removing free usage of M365 Copilot users (this was such a big impact that the older version of Copilot Studio looks to be staying now instead of being replaced).

Although these changes haven't killed them, they have massively changed the likely adoption of these amazing tools, as:

Most developers wont want to use VS Code etc,
The price of usage will drive a "Prove ROI before trying" philosophy, which kills innovation and citizen developers.

Strategies

So where did it go wrong, well I think it goes back to the original Copilot Strategy, if you look at 3 different approaches to the AI boom.

Microsoft / Copilot

Microsoft's approach was to leverage their existing user interaction layer and add Copilot everywhere. The expectation was similar to Teams/Internet Explorer, having it everywhere for free/discounted would drive adoption, enabling them to corner the market. Every employee would use Copilot and once the value was established they would be able to start charging more and generating a profit.

With the initial launch disjointed and fragmented, often what felt like independently by each team. This was not helped by the fact that the models were not good enough and the surrounding technology like MCP did not exist yet.

Copilot in Office is a good example. The architecture has pivoted repeatedly—from the original Graph-grounded Copilot experiences, through to an agentic application-specific experience named Agent Mode 2 years later, and then 6 months later moved to a tool and context architecture built around things like MCP and Work IQ.

There were also constant pivots, with Copilot in Office a great example, first started off as one LLM with specific training, this then pivoted to what they called Agent Mode 2 years later, which was more of a specific Agents per application, before finally changing again to a MCP approach 6 months later. The end result is a much improved experience, but the initial offering was not good (and that's being polite).

Open AI

Open AIs approach was to become the brand of AI, like Jacuzzi, Cello tape, Kleenex, and Google. They were happy to offer a free/discounted licenses and wanted Chat GPT to be used by everyone, from Coders to Doctors to Lawyers.

Along with a broad audience they tried many different AI tools and standards. The Sora app is a great example, focusing very little on their core AI business, trying to expand into social networks.

Their initial lead allowed them to gain incredible market share, but in a similar vain to Android, they were never able to get the market share in profit (with Anthropic making more profit/less losses). After seeing Google approach from the free side and Anthropic taking the higher value enterprise customers, they have pivoted, now investing heavily in the Coding approach Anthropic did, with the same tools and performance, but currently undercutting them. This can be seen with the recent defocusing on Codex, and the coding side rolled back into the main Chat GPT brand, making Coding key to the original brand.

Anthropic

After being generally focused like Open AI, they decided early on to focus on a niche, they targeted coding as there area. Not only that the started with just the model (with simple chat and API). They were happy to give up the user interaction layer (Cursor was arguably the main winner here, gaining traction with the developer and enterprises early on).

This allowed them to focus all of their resources, they created a quality product, and then were able to create a "brand", allowing them to charge considerably more then every other provider. They could also invest in expanding the models capabilities, with things like MCP and Skills, all enhancing their product and establishing them as a market trend setter (pains me to say it but a bit like Apple). This meant they could influence and drive the wider market, with others following their lead.

Once the model were established and they felt that they were good enough they then moved down the supply chain, launching Claude Code. Investing here allowed them to improve their models even more, build user lock in, and start the expansion.

After this came Claude Claude Code Desktop (their version of Orchestrator/Codex/T3 Code), Claude Cowork and Claude Design. All expanding the userbase, now not just coders, but everyone using computers.

You can see this path leading to something like Microsoft, with a suite of tools and capabilities, making a Claude Enterprise license a key tool for every employee.

What these Approaches mean

Well we can all agree, currently it looks like Anthropic's approach was the best. And although its still very early, and I wouldn't necessarily bet on them, it
I think Microsoft's approach has created 2 issues for them, first most obvious is they have burned through their budget for adoption. Giving away for free/discounted only works if you can get customers hooked on the product. That never quite happened for Copilot, add in the broader financial markets are getting more concerned with never ending AI investment, it feels like everyone is trying to get to profitability quickly.

This is why they are having to charge full price for Cowork, charge for development of agents, and no "all you can eat vibe coding", you have to pay per token in VS Code.

The second was they are now behind the competition, and its quite possible those competitors now have strong footholds into Microsoft customers.

Cowork is the perfect example, its what I (and I suspect most people) imagined Copilot would be when first announced by Microsoft. It can do complex work across my files, pull together business and external data, and can be scheduled into a workflow.

And yet this wasn't created by Microsoft, but built out of Anthropic's Claude Cowork, using the same underlying technology, but built within the Cloud and heavily integrated with Work IQ.

And because of Anthropic's involvement it means that not only is it designed to work better with Anthropic models, it has completion out of the box, and there may well be licensing costs to Anthropic. Meaning it is:

More expensive to subsidise
By paying it they are giving money to the competition, which defies the point of undercutting the competition

Can They Turn It Around

This is Microsoft, so the answer is obviously yes. They have the talent, resources, network effect, and unique tools like Work IQ (man I've been so impressed with the better results since it launched), to still win the AI race, but I think a few things need to happen.

Model

Microsoft needs its own frontier level model. They could even get a Open weight model and build off that (like Cursor did with Composer 2 being built on top of Kimi K2.5). Having these in house models allows them to be cheaper and more finally tuned to Microsoft customers. They have so much user data (both user and how the users use their apps). I know they have the MAI, but I've not seen much except the flash code (so less powerful and not comparable to something like Opus).

Pricing

They need to figure a way to get flat rate licenses. Every license covers an underlying cost, they just figure out the ratio from normal users and heavier users, and slap a healthy margin on it. Business would be happy to pay more to get the security of knowing exactly how much it will cost.

Figuring this out will take time, an I worry having at as PAYGO now will make the data inaccurate. So somehow they need to figure a way to get the price to a position people will act like its a license.

Lead Not Follow

Work IQ is the best example of this, something powerful, unique, and new. Microsoft can't just follow others (Copilot Chat, MCP, Cowork, Scout), it needs to be an innovator, then using its market share to drive the agenda of the wider market. If Microsoft created a new standard, and rolled it out to all of their products, I can't imagine a single other vendor not following (well maybe except for Anthropic and Apple 😏).

Perfect The Managed Host (aka Power Platform)

A big part of AI is not just the exciting stuff, its the infrastructure it runs on. Azure, and more importantly the Power Platform, is perfect. Its a walled garden then can mitigate a lot of the risks from AI generated code. But the Power Platform still has issues it needs to fix:

Legacy unused Dynamics features
Lacks POLP (Principle of Least Privilege)
To focused on citizen dev's (a pipeline that requires dev edit permissions in prod 🤦‍♂️)
Messy administration (Bleeds into M365 Admin Center, poor tenant visibility)
Messy edge features (Too much roles into Azure, App Insights, Key vaults, VNet, just to name a few)
The 95% Problem (most features are 95% finished, leaving them unusable)

Wrap Up

Integrating Copilot with Microsoft's products made sense, but unfortunately I think there was far too much haste, and too much speed, leading to wasted investment in poor ideas and ideas that the technology wasn't ready for.

Anthropic's approach on mastering code, and expanding when ready. At the heart of everything is code, going to that level was always the right approach. Its the most efficient, consistent, approach, and has the most training data so models could master it first.

Hopefully Microsoft has figured this out, and things like the MAI models and Work IQ show they maybe have. But then I hear a lot about the super app, and I worry maybe not. Expecting developers, citizen developers, and business users all to use the same app doesn't make sense to me, unified admin center, hell yeah, please do that, but one user app no.

I always think of a smart phone, you have an app for every task, that way they are easy to use, easy to find, and targeted to particular user groups. And then any settings that work cross apps go in the settings app, which controls everything.

We will have to wait and see, I have my fingers crossed they do figure it out (and I'm wrong about the super app).

😎 Subscribe to David Wyatt

Using the New Copilot Studio Skills

david wyatt — Mon, 03 Aug 2026 06:15:33 +0000

One thing Microsoft is not good at is naming things, and sadly it's happened again. But let's go back to the beginning: what are Skills?

Skills are targeted prompts/context that are modular, so they are not always included in the LLM session. They are Markdown files with selected metadata in YAML, all in a file normally named skill.md (the parent folder and YAML metadata identify it).

They were created by Anthropic (Claude) and were designed for both the user to add in a prompt (/Skill), or for the LLM to decide.

Similar to Skills are Plug-ins. These can (and often do) include skill.md files, but can also have scripts, MCP servers, and other tools.

So back to Microsoft naming things badly.

Copilot Studio (Azure Bot Framework version) had skills, but they were not skills.
The new Copilot Studio has Skills, but they are not Skills, they are actually Plug-ins.

Plug-ins include Skills, so why does it matter? Well, it doesn't really, but I like to moan, and it means sometimes cool functionality can be left on the table because we presume Microsoft names things accurately.

Anyway I digress (I like to do that), now we understand what Skills/Plug-ins are I wanted to dive into them within Copilot Studio and cover:

Why Are They Cool
Building Powerful Skills
Adding Scripts/Templates
Using Skills

1. Why Are They Cool

I often go on about skills being cool, but why? There are a few reasons.

Context Management

Before skills, the standard approach was to give the LLM everything and let it figure out what it needed. The problem with this is twofold. First, more context equals more tokens, which equals more cost. Second—and more importantly—too much unrelated context can have a detrimental impact on the LLM response.

LLMs work by using input tokens to predict the next token, so polluted input tokens can make the LLM predict the wrong next token (this is a huge simplification, but you get what I mean).

Transferable

As skills are simple Markdown files, they can easily be transferred between different agents (and even platforms—I use some skills in both GitHub Copilot and Copilot Studio).

Flexible

As skills are just natural language, you can literally use them for anything. They can be used to:

Add specific context/knowledge
Add learnings or nudge responses
Create distinct topics that might have overlap
Create workflows through chaining

Just to name a few.

But that's real skills. What about Copilot Studio Skills? They have all of the above (because Plug-ins have skills included), but they also have two more big benefits.

Scripts

This, to me, was a game changer when I learned about it. Copilot Studio has a built-in Python compiler, so Copilot Skills can include Python scripts that the LLM can use.

Imagine this: you include an Excel file, and instead of trying to get the LLM to return consistent analytics through natural language, you can build a Python script to do it. You now get deterministic outcomes with LLM flair.

My favourite implementation so far is a Power Automate Code Review Agent that uses Python to structure the definition consistently for the LLM to review.

Templates

Again, this is about consistency. When we want our data output to be the same (for example, a PowerPoint template or Word form), LLMs are not our friends. They will try to deliver what you want, but there will always be small variances. If you include a template file in your Skill, the LLM will always return the data in that format.

So we can now agree Skills are cool, but how do we use them correctly?

2. Building Powerful Skills

Knowing what type of skill you need is the first step. I think there are three types of skills: behavioural, action, and knowledgeable.

Behavioural

These are skills that influence how the agent acts.

Example:

Always review your work with a 3 stage approach:
- validate the goal has been complete
- consider any broader impacts to the development workflow or infrastructure
- check for any potential security issues

If you identify any issues complete an update and repeat. **DO NOT Repeat more then 3 times**, at this point create a md file named `review-comments` with any issues you have identified

Actions

These are when you want the agent to do a specific thing, it could be deploying or running GitHub Actions. But it is not limited to tools, one of my favourite is grilling / grill-me my Matt Pocock (if you have no seen his skills you really need to).

Matt Pocock Skills GitHub: grill-me

Interview me relentlessly about every aspect of this until we reach a shared understanding. Walk down each branch of the decision tree, resolving dependencies between decisions one-by-one. For each question, provide your recommended answer.

Ask the questions one at a time, waiting for feedback on each question before continuing. Asking multiple questions at once is bewildering.

If a fact can be found by exploring the environment (filesystem, tools, etc.), look it up rather than asking me. The decisions, though, are mine — put each one to me and wait for my answer.

Do not act on it until I confirm we have reached a shared understanding.

3. Adding Scripts/Templates

As I said, in Copilot Studio these are actually plugins, which give you the incredible power of scripts.

To use the script there are a couple of ways. You can provide them with references so that the agent reads them and decides when to use them.

These are ideal for knowledgeable skills where the script adds data.

The second approach is to explicitly tell the agent to call a specific function with specific input.

These are great for action skills.

To pass information into the script add imports, along with explanations of what they are in the actual skill file.

To get the values returned we can either pass them straight into the context using print:

Or we can create a temporary file and save data to that.

Set output parameters for the function:

parser.add_argument("-o", "--output", help="Output JSON path")

Skill sets the output to model.json:

python scripts/extract.py <solution.zip> -o model.json

Then we just write what we want to the output.

We can then use that file in other skills by using Python to read it.

python scripts/review.py model.json --area Connections -o findings.json

As you can see its relatively easy to pass data to and from python scripts, but what if you can't write python, well that's when a little vibe coding can come in useful.

In my experience LLM's are pretty good at writing python, but I've found them even better at converting between languages. In the above example everything was converted from some JavaScript I had written, and I had zero issues.

4. Using Skills

Once you have Skills you need to understand how to use them within your agent. There are three main ways for a skill to be called.

Instruction

The instruction file will state which skills should be used and when. This is the most simplest and consistent way to use Skills. You set out what conditions to use them and why.

Description

The top of every skill in YAML contains the name and description, the LLM will be passed these and it can then makes its own decision when to use them. This gives the best flexibility and empowers the agent, but with the loss of consistency/deterministic outcomes.

From a Skill

Just like an instruction, Skills can call other Skills. The main benefit of this approach is enforcing chains/processes. As because its not in the instruction file the LLM will not be passed it unless there is a need, keeping the context clean and focused.

As you can see, Skills(Plug-ins) bring so much power to your agent, they:

Improve performance through better context management
Allow branching/paths, removing the need for topics
Create complex workflows
Bring the power of custom code to your agent

😎 Subscribe to David Wyatt

The GitHub Copilot Harness Copilot Studio

david wyatt — Mon, 20 Jul 2026 06:25:28 +0000

Copilot Studio has been around for a while now, originally Power Virtual Agent before the Copilot Revolution, and as chatbot builders went, it was ok.

But it never really felt right for me, it topics felt cumbersome (and this is from a Power Automate guy), and I never got the results I expected, and some how it felt super complicated. The simple truth was it was an old fashioned chatbot builder with generative AI bolted on, and it could never deliver compared to GitHub Copilot, ChatGPT, Claude, or Gemini.

The thing is it wasn't just the UI or design, it was built on a different engine (check out this great article explaining more perspectives.plus), and Microsoft knew it was on the path, so migrated the backend and created a new front end, and that's what I want to talk about today.

Hopefully you have seen the new Copilot Studio, if you haven't go to your preview environment, or slapped .preview in your Copilot Studio url (copilotstudio.preview.microsoft.com)you would have seen the new Copilot experience.

How its different
What's New
What's missing
Is it any good

1. How its different

Apart from the engine, the main difference is the removal of topics. Topics were the old way of building out predefined responses from your agent. It included question/answers and actions like API calls. Topics have been around since Power Virtual Agents, before the LLM era. Copilot Studio bolted on some AI to help channel requests to topics, but they were more like Power Automate then GitHub Copilot. They have been replaced with Skills, which I will go into more detail about later.

There is also some new features but this is main different, as it represents a fundamental change, from:

The maker trying to decide on actions and AI deciphering the user to find right topic

to:

The agent decide on the right actions to take

There has also been a change in the deterministic side, with Agent Flows been replaced with Workflows (a new UI with some new AI features), but I will go into that in another blog. Additionally both the UI and UX are much improved, options are easier to find and the preview/test is much better, being with not only full screen but showing the steps/reasoning the agent is making.

2. What's New

The new builder focuses around 6 main areas.

The models are the same, the instruction the same, but the UI is now simpler and feels more like a modern LLM.

Microsoft IQ

If you see IQ, it means Microsoft's way of grounding data for your agent. And by that I mean the agent gets access to your organisations data, currently that covers.

Work IQ - All of your data across Office etc, your emails, chats, OneDrive files, the agent will have access to it all to add to its context when you ask it anything

Fabric IQ - All of your business key data.

Foundry IQ - Knowledge sources created in Foundry.

Work IQ in particular is very cool, you don't need to set anything up and your agent instantly has on-behalf access to the current users data.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/use-microsoft-iq

Skills

If you don't know about skills you really need to, they are the best thing Anthropic have created (nope not MCP, I'm not a big fan, but that's a conversation for another day).

You can think of Skills as optional prompts and context that the LLM can decide to use. They are markdown files and support files (like scripts, templates, or knowledge docs), and are optional, so only used when the LLM thinks its needed (you can see how they replace topics). So in a nutshell we get:

User request & instruction - LLM asks for skill - request & instruction & skill

Skills are super cool, as a basic one is just a simple instruction file that is used for specific use case, just text and you get the benefits of lots of complex workflow logic.

They deserve a blog all for themselves (watch this space), but needles to say they are one of the best tools Claude Code, Codex, and GitHub Copilot uses, so its great to see them in Copilot Studio (there are also thousands already available for you to use/get inspired by, Anthropics GitHub has some good ones.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/skills-overview

Tools

Same as classic Copilot Studio, these are your connectors, MCP's, and Workflows (old Agent Flows). Just like your Skills they are available for the LLM to decide when to use them.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/tools-overview

Knowledge

Again like tools the same as classic Copilot Studio. Here you can add knowledge for the LLM to use to answer questions or make decisions

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/knowledge-copilot-studio

Connected Agents

Deja-vu, again nothing new, here will can link child agents and other agents to handover tasks. This was critical for the classic Copilot Studio to get ring fenced context. But Skills can do this now, so I think it will become really useful when you have a large ecosystem of agents. That way they can seamlessly pass you to the right agent if you are off topic or just lost.

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/authoring-add-other-agents

Memory

Memory is a simple toggle, and its kind of in the name, the agent can now remember previous sessions. Users can see all of their memories and manage them. I'm excited to see how this works, as context is a fine-line to walk, too much and it can have negative impacts on your requests. Though on the flip side it will be able to kind of learn, with it responding in the way you prefer and understand your requests better (come on that's cool isn't it 😎).

https://learn.microsoft.com/en-us/microsoft-copilot-studio/agents-experience/memory-overview

3. What's missing

The new Copilot Studio is in preview, so I expect most of these to be added over time, but as of now:

Access to the solution, you cant see the solution area in the environment, so if you want to export you need to got to the classic or Power Automate/Power Apps
All required components are not automatically added to the solution when you add the agent
All of the Knowledge sources, you are currently limited to External sites, SharePoint, and OneDrive
Autonomous Agents, though this is because the change in strategy, with the new Workflows taking on the trigger of agents. I think this is the right way to go, so I suspect Autonomous Agents will disappear for good

4. Is it any good

So is it any good, Microsoft doesn't have a good record for UI updates (cough Power Automate V3 launch), but in this case, hell yes.

This is what Copilot Studio should have been from day one, it now feels and acts like other LLM agents. It no longer feels like the old legacy Power Virtual Agent, it is something new and modern.

The results are smarter/better, you can do more, and you can build a lot quicker. I personally will not be touching the classic UI again, there is no migration path (different engine), and the results are just so much better (the only blocker is the knowledge sources, but in that case I would rather just wait). And with the pace (and total focus Microsoft has on Copilot Studio) I excited to see new feature updates soon.

So if you haven't used it, you need to try, trust me you wont look back.

😎 Subscribe to David Wyatt

Custom API's in Power Automate

david wyatt — Mon, 06 Jul 2026 05:35:20 +0000

One of the best things about Power Automate ane the Power Platform is connectors, there are over a thousand, covering nearly all of you needs, with zero effot.

But what about those API's that there is no connector for, well Microsoft has got your back, and in its normal manner it has a few ways to do it.

So this blog Im going over the 3 main ways to connect with custom api's in Power Automate

The Wrong Way
The Right Way
The Crazy Way

1. The Wrong Way

I'm going to upset a lot of people with what I'm about to say, but the HTTP connector is not the right way to connect to custom api's*

The asterisk is because there is 2 fringe cases where it is the right.

Before we talk about when its ok, lets talk about why it's not the right for normal connections.

And the simple fact is it is not as secure as other options. Using the HTTP action moves the authentication into the runtime, which introduces vectors of risk.

These are the main risks:

Credential Storage

Credentials have no default place to store them securely. If you want to use a HTTP action with auth, you need to save Passwords, API Keys, OAuth Secrets, Tokens somewhere.

Now there are places to store them, like credential banks like CyberArk, or Azure Key vaults. But having to access these can add (admittedly very very small) exposure to the vaults, a great example is Azure Key vaults have to be publicly accessible for the Power Platform to use them.

I know that Microsoft will say this is fine, but some orgs don't like it, especially with the risk of new frontier LLMs. Add in you can't add urls or service tags to Key vaults, only individual IP's, and it can be a security headache you don't want to deal with

Credential In Transit

HTTP action requires the auth credential to be handled in the flow run time, which means they will appear in the logs. The good news is there is secure inputs/outputs, but although that fixes the problem, its not totally perfect

Requires the developer to turn on
Impacts debugging

Data Exposure

This is one that is easy to miss, but if you are posting data through the HTTP action, and that endpoint is dynamic, either through action inputs or environment variables, then it is possible for them to be edited and data sent to a bad actor.

Again we have controls, like HTTP endpoint filtering in DLP (if you are not using this then you need to!). But again we are adding overhead and more potential points of failure.

So as you can see, we really shouldn't be using them, but hey David what about that asterisk, and if they are so bad why did Microsoft add them, good question.

So there are 3 times I would use them, and one of them is a very unlikely.

PoC

If you are building a flow to see if its possible, or generally as part of a incremental built out, then using the HTTP action totally makes sense. It allows quicker incremental building, working in one UI and workstream. Once you have everything working you can take the learnings and move to a more robust solution.

No Auth

Yep there are times when the API (or in some cases using it to web scrape pages, check our my previous blog about how to How to web scrape with power automate cloud. In these cases we now remove handling auth and any sensitive data (if you are pushing sensitive data to an endpoint with no auth you have bigger issues to deal with).

So yep that is a good use case, and one I have used a few times.

Super unlikely

If you have a flow that has to handle dynamic endpoints, then this maybe your only option. In these cases you get sent a dynamic url with auth, these are normally used for file sharing. In most cases they use the same base url, so you might be able to use other ways, but in those niche cases, this is your only option, and the risks become necessary.

2. The Right Way

I'm pretty certain you already know the right way, but just in case its...... a custom connector.

Custom connectors allow you to use the built in connector/connection bank built into the Power Platform. Now all of the auth is handled outside of runtime, with the auth created during build/deployment, and never even touching the flow runtime.

On top of the auth the endpoints are pre-built, ensuring that there can be no changes without change control.

Custom Connectors do come with draw backs, in particular:

ALM - they have to be deployed/updated across all environments
Gateways - don't play nice with gateways, only allowing windows and basic auth.
They don't support all auth, tools like APIGEE are often configured with client OAuth, and these don't work with Custom Connectors.

But the simple truth is they are worth the trade offs (and you cant use gateways with HTTP actions so meh). Improved your risk vector for some additional administration is 100% worth it, and in theory nearly all security practices add administration, and we always follow them.

3. The Crazy Way

This one is a bit silly, but I wanted to call it out. If you are using an API that is from a vendor that does not have a connector, you can always make and submit your own.

Microsoft allows 'Independent' publishers to create connectors. This means you, me, or anyone can create connectors, submit them to Microsoft and they become available (Service Now is a good example, its not made by Service Now, but Microsoft as an Independent Publisher.

Don't get me wrong, this is A LOT of work (again another previous blog about how and how painful here), but in some cases it might be worth it.

You remove complexity around ALM (though add a more painful one with publishing), but more importantly you help others out. A big thing about the Power Platform is the community and helping out (you are reading a free blog made purely to help you), so I like the idea of sharing your learnings and effort with others.

4. Secret Bonus way

There is one more kind of way to do this, and this is my favourite connector the HTTP with Microsoft Entra ID (preauthorized)'.

This connector is amazing for 2 reasons, first it uses Entra SSO, so the auth is simple, no SPNs, no Key vaults, everything done the normal way. Second is it can access anything within the Microsoft world. That's all of the Grap API (so every office software etc), but also some Azure services.

And as the connection is linked to the endpoint url, it should be pretty secure (the input url should never be dynamic because it is related to the connection. This symbiosis ensures that it cant be changed), and it stores all credentials in the connection/connector vault, win.

Shock horror, I've already done a blog about the connector, check it our here 😎

There you have it, there are lots of ways to access non standard API's in Power Automate, but as always there is a right and wrong way. The wrong way can often feel like the easy way, and you may get pressure from enterprise architects and others who do not understand the platform, and just want the easy way. But as a developer or administrator its your job to do it the right way, even if that can add a little effort.

😎 Subscribe to David Wyatt

Vibe Coding My Own Power Platform Admin Center

david wyatt — Mon, 15 Jun 2026 06:09:46 +0000

I will stop you there, yes this does sound like a silly idea, but trust me, there is some method to my madness, and as always, the journey is half the fun.

So 2 things convergent at the same time that almost felt like fate:

I was creating a complex Security Role setup (because you know only system admins can do that and I don't want my developers to have the keys to the kingdom)
Second Open AI gave me 1 month GPT Plus free

So I thought can I make my life easier and burn some free tokens.

And like all good ideas they grow into something crazy.

1. Where it started

I'm sure most admins will agree the Security Role UI is not the best, it doesn't seem to fit the screen well and feels like it was designed to edit single tables, not large complex roles. At the moment I get Excel spreadsheets with the roles required permissions and I have to copy them over, so I thought how cool would it be for the app I'm building was able to:

Create roles then export them (and existing) as a Excel file
I handover to the dev team, they fill in,
Hand back to me where I do a quick security check then upload

And that's where it all began

2. The Design

Auth is never fun, especially for a Low-Code developer like me who relies on the platform to do all the heavy lifting. Fortunately we have a great foundation to build off, the new NPM Power Apps CLI, this is obviously a terminal app but:

It can do full Dataverse Auth (and now connections using https://api.powerapps.com API)
No need for registering a spn and getting security approval (winner)

So my idea was to use the cli package and spin up a local node instance, this will stop any cors issues and allow me to have a nice web UI. It also means in future it could:

Be installed through terminal nice and easy
Packaged in SEA of Electron
Hosted as a full web app

3. The Build

I have basic knowledge of JavaScript so can read it and code in it, which meant I was in a good place to leverage AI and my free Codex tokens to build the solution.

The App is 100% AI coded, I have reviewed a handful of lines of code, but I'm fully in the world that unless this is something professional (i.e. I'm paid to use it or paid to sell it), then I'm happy to take the risk and tech debt.

I've spoke about how I prompt before and my next blog I'm going to go into more detail about it, so I'm not going to talk about it to much, except to say:

This is definitely not a one shot prompt
I did research before around technical implementation so that I could guide Codex
I worked on a feature-fix-refine cycle, with prompts and work focused around completing a specific feature

4. How It Came Out

Amazingly the end result was exactly what I wanted, it is lightweight, fast, and super easy to navigate/use. It significantly decreased time taken to roles, and decreased potential errors.

I had to get auth and environment working first, then a PoC CSV version, before finally ending with a formatted Excel workbook.

5. Scope Creep

Everything I had wanted to complete was done surprisingly quick, in total an hour or so, and I hadn't even hit my 5 hour allowance let alone my weekly, so I decided what more I can do.

And this is where I had a realisation, the Admin Center is split into 2, with tenant settings and environments, and then below environment each environment setting. This makes sense and in the world of one solution it is the best choice, but we are no longer in the world of one solution and there are times when this is not the best structure.

The other approach is to remove the environment structure and go by functional area, so like in my above admin center, instead of seeing all security roles in each environment, I have a security role section where I see all environments. And I thought what else in my workflow would also benefit from this, so far I have:

Solutions

I work across lots of environments, I even work across different tenants, so trying to remember where stuff is can be a challenge, I endup opening multiple tabs and searching for them. So I decided to make a solution tab.
This allows me to quickly select an environment and then search for the solution. As that was super easy and just one API call I added

SolutionComponent call and Entities table to get all the components in the solution with display name
Link to the solution in make.powerautomate.com
Basic updates:
- Change connections in Connection References
- Change Environment Variables
- Turn flows on/off
- Share flow both co-owner and run-only user (Add in SystemUser and Team table)
- Update manual flows connections to either flow owner or run-only user
- Share Canvas, Code Apps, and Agents

All of the above was stuff I had to do and took more time then I liked in the standard UI.

But as I have gone this far and then thought what about exporting the solution for code reviews, so I added the unbound ExportSolution API. And as I was fully on the slippery slope I then asked myself, what about deploying to another environment.

This required another new tab and the ability to not only use the unbound ImportSolution API but also all of the connections and Environment Variables:

List all connections References and Environment Variables in the Solution
Get Connections from target environment and create them if necessary
Get current environment variable values from target environment
Create the Settings JSON and submit that

And it all worked, amazingly well after only a few prompts (I also did a chunk of research and had some good knowledge on the export/import API's which definitely helped).

I was now in full addiction mode, targeting every friction point in my admin role, every task that takes just a little too long, so next was...

Users and Teams

Assigning user roles, and more importantly adding and assigning teams can be a time consuming task, but now I can complete them all in one go.

Connections

Unfortunately connections in Power Automate are brittle and often break, requiring a process to identify and fix. Add in Custom Connector secret updates can cause users connections to store stale tokens means that we need a way to quickly delete them. So this tab lists all connections in an environment (obviously you will need to be System Admin else you will only see your own).

Tables

Ok I'm a little out of control now, but there are times when I want to check to see if tables are deployed across environments, along with getting good documentation. So I added a Table tab, that lists all tables and:

Shows all or just custom columns
Creates a table of columns that can be exported to Excel
Creates a Database Design Diagram

The updates also rolled back to the Solution tab, so I can see all Table/columns and a Diagram of all the tables in the solution (wanted this for so long, Chrome Ext coming soon).

AI Flows

Keeping track of credit usage has improved massively but still not perfect, so I grabbed all the events from the AI events table. And with a little exploring of network traces to see how the Automation Center did it I was able to see all the flows using credits

Copilot Studio Events

I wanted this to be like AI Flows so I could track usage of credits, but that is done by none Dataverse API's. But I could see the bot transcript table, which meant I could see which agents had most sessions, and could open up a transcript if needed to check on outcomes.

Flow Runs

Already well represented in the real Admin Center but I thought why not, now I can see all flow runs in an environment by flow, and identity failed runs easily.

6. Wrap Up

There was a few realisations I had from this adventure, and just how powerful AI is wasn't one of them.

I said along time ago I didn't agree with 'AI is the newUI', people simply prefer user interfaces more then text inputs. But I now think its 'AI provides a personal UI'. The future is that anyone can create a bespoke interface for their personal ways of working, or even events, no more compromising.

You prefer menu on the right, done,
Options by function not hierarchy, done
Edit in Excel and upload instead of in app, done
On mobile instead of laptop, done

The options are literally endless, and the value in almost infinite marginal improvements should not be underestimated.

And for me this means software developers need to pivot to open solutions. Shockingly Salesforce have figured this out with Headless 360, with the data structure and infra the product, and you bring your own UI (BYUI) now the future.

I really hope the rest of the Power Platform Admin Center API's are exposed and structured as easy as Dataverse API's.

The last realisation is a little less exiting, and that's around these 'all you can eat' subscriptions like from Open AI and Anthropic and how they changed my behaviour. With GitHub Copilots new (and old model) I was very targeted and thoughtful with my prompting, adding a new level to the project. But with Codex my behaviour changed, the 5 hour/weekly limit turned into a goal to use, focusing on quantity not quality. This led to me making sure I was in Codex every 5 hours and other addictive like behaviours, I can see how easy it is to become AI Vampire's.

So for now I wont be renewing my GPT Plus subscription, no matter how good it was.

Power Devbox Admin is available in NPM powerdevbox-admin, so if you have Node installed you can install it locally with:

npm i powerdevbox-admin

Or just run it locally with:

npx powerdevbox-admin

Or if you want to fork it (or help improve it) you can find the repo here https://github.com/wyattdave/pdac

😎 Subscribe to David Wyatt

CodeApp JS - My Shortcut to Vibe Coding Power Apps

david wyatt — Mon, 01 Jun 2026 06:17:10 +0000

Code Apps are my current favourite thing about the Power Platform, they follow what I think Microsoft's AI strategy should have been all along "Automate the code underneath, not the UI", as that's what LLMS are good at.

But I found a couple of issues with Code Apps:

The CLI requirements is a barrier for some
The process is disjointed (e.g. getting connection id from url)
Require repo like GitHub (another barrier)
React is good for some use cases but overkill for others

So I wanted to create a way to fix these issues, I wanted

A way for most makers to build without adding connectors
To enable Copilot and other Agents to build right first time
No CLI commands needed and a simple workflow
Store the editable code in the platform

Callout, although I dabble in TypeScript I'm stuck in my ways and prefer JavaScript, also I like to build things, so anyone who calls out this probably isn't necessary and the LLM will do all the complex stuff is right

So here was my idea, create a fork of code apps built on top of the power app SDK.

This project has rattled on for a while, and it all came together when Microsoft launched a NPM version of the power platform cli, allowing me to build in that inside my solution instead of an external dependency.

1. CodeApp JS

My plan was to build a conversion process for the SDK into a simple JavaScript (removing the build stage) file that I could then build on top of. The idea was to have these files:

power-apps-data.js - the SDK
codeapp.js - helper functions, debugger, Dataverse actions, and later date the Flow actions
connectors/ - folder with all of the most used connectors converted to JavaScript, they would have easy to use wrappers and built it debugger
Index.js* - where all the project JavaScript is
Index.html* - where the app UI is
power.config.json* - the app config details

*These are standard Code App files that are always required

The default connectors I thought of that covered 90%+ of use cases where:

Dataverse
Office 365 Outlook
Office 365 User
Office 365 Groups
SharePoint
SQL
Teams

The next step was to improve how LLMs build Code Apps, as by default they just want to build normal web apps, so I created 2 main areas, agent and skills.

The agent.md file is like a system prompt that you can set in VS Code, it ensures the LLM knows that this is a Code App and to do things like use the SDK instead of simple fetch() functions. The skill.md files are for each connector, they ensure the LLM updates the power.config.json file and doesn't make any silly mistakes.

They all started from a foundation and were incremented on with learnings from building apps, the more I built the more learnings I could train the LLM with

This means that out of the box a maker could build a Code App, but they would need to add schemas for datasources to help the LLM and still used one cli command to publish to the Power Platform.

2. Build Setup

At this point I have done 1 and 2, but what about 3 and 4, well this is where I needed to build (my favourite bit 😎).

To make the workflow easy I needed to replace the CLI commands, and that meant a new UI. The approach I decided to go with was, in a strange contradiction to my objective, was to build a CLI.

There were 3 reasons why I decided

First because I could batch/improve the commands and add new ones. Examples include if I wanted to add a new connector I got the command to find the first valid connection and use that (no getting connection id from the url).

The second and most important was because the CLI can be the foundation for any UI.

So we have the Code App JS files, which are used by the CLI, which is then used by other Apps. That way when I update the files with new connectors or SDK updates it cascades through, and if I update the CLI with new commands (like when the call flow was added), again it cascades down.

Third I just really really wanted to make a CLI.

3. CAP CLI

The CLI is split into a light and full version. The light covers the CLI commands, the full version builds Copilot SDK into it so it can be a fully standalone agent tool.

Light - the CLI commands

The CLI commands in theory should make the process more streamlined and simplified, these are the commands I created.

CAP auth - signs you into Power Platform
CAP environment - lists all of your environments and lets you select them. After selecting it also updates the power.config.json file
CAP dataverse - inputs dataverse table, adds it to the power.config.json and adds the schema to the config file (deletes or unnecessary files too)
CAP flow - lists all flows for you to select, adds it to the power.config.json and adds the schema to the config file (deletes or unnecessary files too)
CAP deploy - publishes app to environment, it also copies the power.config.json file into the config folder first (you will see why later)
CAP deploy --debugger - turns on debugger so in the app you can see and copy all connector actions (great to passing to LLM to help debugging)
CAP connector - inputs connector, finds first connection id from environment, imports TypeScript code, converts, embeds debugger functionality and moves to the connector folder (deletes or unnecessary files too)

there are more shortcuts to these like CAP environment -- but you get the idea

That's the standard commands from the Power Platform API, but why stop there, so I've added some of my own

CAP setup - copies all of the templated CodeApp JS files into your project folder, asks for name etc to setup power.config.json file
CAP table - allows you (or the LLM) to create Dataverse tables, you input name, publisher and then add as many columns as you need (any type)
CAP import - my favourite, but I need to explain more

CAP import is the key to objective 4. See the best thing about Vanilla JavaScript in CodeApp JS is it does not need a build step (convert from TypeScript to JavaScript), so the code in the Code App is the code you have written. This means in theory you can export the solution, unzip it and see the code you wrote (or Copilot did). The one thing missing is the power.comfig.json file. But if we copy that, and any other import files like the schemas into the dist folder, lets say in a config folder, then we would have everything we need.

And that's what import does, it lists all of our Code Apps in an environment, you select the app, it finds a solution its in and then exports the solution zip. Once it has the solution it unzips it, grabs the code and adds it to your project folder, finally it copies the power.config.json from the dist/config folder to the root.

So now you can use the Power Platform to store your dev code 😎

Full - Copilot

The full version has everything the light version has, but also has the Copilot SDK build in, so you don't need vs code or other agent tools, you can use CAP on its own (and again you can build you own agent tool on top of this).

CAP copilot - sign into your GitHub Copilot account
CAP model - view available models and select the one you want
CAP skills - view list of skills and open to see them
CAP instruction - create your own instruction.md file
CAP - open up interaction session, all inputs are prompts sent to the llm, except when you prefix a /, which the falls back to the CLI for commands like CAP deploy
CAP-p - runs a one off prompt to the llm (like Claude-p)
CAP session - view all saved sessions and select one to continue

As you can see it successfully switched to returning in blocks of 10, though as always there is a small bug with loaded total only showing 10 🤦‍♂️

4. How I use it

Lets be honest, although the CLI is cool it is not the best way to build (cough sorry Claud Code), so how do I use it.

Well at the moment I use a VS Code Extension I created based on the CLI.

CAP - Code Apps

For me its the perfect blend of Low-Code and AI. It has all the buttons I need to complete actions like adding Dataverse table or deploying (see bottom of the screen)

And it delegates all of the code writing to the AI (bit like what we do with Power Apps, we interact with buttons, and delegate most of the code to prebuilt code provided by Microsoft developers).

It also has a couple of added benefits

Using Copilot in VS code enables additional models like Gemini Pro 3 that are not enabled through Copilot SDK
For CLI your admin will have to enable Copilot to use SDK and for you to install the CLI, where as VS Code Ext is normally just one click
I'm use to VS Code so I can use it easily.

Here's a demo video of me building an app using it (Im no Youtuber so expect no production costs, and its a little boring so you may want to fast forward lol)

But I am working on an orchestration app, so that all my Code Apps can be found in one place with a nice UI.

5. Have Ago Yourself

For more information of Code Apps check out https://codeappjs.com/ and more information on CAP CLI check out https://codeappjs.com/cap.html.

Its all open source, so if you want to add connectors/features or fix bugs (I'm sure there are a few), please feel free to submit PRs. Likewise if you don't like the JS side of it, but like the commands you can fork it and use any useful bits.

The interesting thing I found about this is that AI gives us something that we never had before, a world of bespoke solutions to our personal developer ways of working. I found myself constantly spinning up new ways to make me more productive, from new bookmarklets, to entire CLIs and libraries, and that for me is super cool 😎

😎 Subscribe to David Wyatt

From logic Apps to Workflows and what it means

david wyatt — Mon, 18 May 2026 06:34:50 +0000

You may have seen recently the launch of Workflows, this is a cool new automation builder inside Copilot Studio.

But is it actually new, as with most things when you draw back the curtain you see that things are a lot less different then they appear.
Underneath Workflows are Power Automate flows, so that means that now we have 4 different ways to build our flows

Classic UI
New UI (V3)
Agent Flow (Inline)
Workflows

Well actually there are 5, as Power Automate is actually built on Logic Apps, and although the UI is the same V3, it also has a code editor (and with a nifty VS Code Extension I made you can edit flows from your environment in code too).

So=PowerDevBox.power-automate-utility) I made you can edit flows from your environment in code too).

So I was wondering, what exactly is the difference between flows built in these different UIs?

1. Logic Apps

Logic Apps are where it all began, as the origional Power Automate flows were just Logic Apps with a few tweaks. Even the UI was the same, just with the additional of code editor and some additional/missing connectors. When Logic Apps moved to a new UI called V3 so did Power Automate, and when you look at the clientData Power Automate uses a Logic Apps schema:

https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json

2. Classic UI

The Classic UI was loved by developers for a long time, and with the launch of V3 not so smooth (missing features) a lot delayed moving over (Microsoft even had to introduce a toggle to switch back). Even now V3 is established you will still see Classic in Power Apps when selecting a flow, some logs, and randomly when creating a flow from solution screen.

3. New UI (V3)

The V3 UI is the current UI for Power Automate (for now) and was 100% client side deep, with everything under the hood the same. You can not tell any different by looking at a flow in the Workflow table, and they were 100% interchangeable.

The UI moved from inputs and buttons inside actions to a side panel, along with a fresh new modern look, version control, and Copilot.

4. Agent Flows (Inline)

Originally flows used in Copilot Studio looks identical to Power Automate, with the only difference how they are billed (Power Automate runs use the owner/app users API allowance, Agent Flows use Copilot Studio Credits), but in August 2025 that changed, with Agent Flows having a different UI.

The New New UI was a hybrid of Classic and V3 UI, with inline inputs, side panels, and other benefits from V3.

When you open the same flows in Power Automate they fall back to V3, but the story isn't quite over there. The Inline UI was suppose to launch in Power Automate at the same time, it was pushed back to February, and following Microsoft's playbook of poor rollouts, this version was slow and unresponsive, leading to it being pulled and planned for later 2026.

Again looking under the hood there appears to be no difference between Agent Flows and Power Automate flows, with the same definition (Logic Apps), but there are some differences.

First different connectors are available/not available, and second was within the Workflow table, where there was a new field, modernflowtype.

If this was set to 0 it was a normal flow, if it was set to 1 it was an Agent Flow. So you can simply update the field in an API call or in the details in the UI change the plan to Copilot Studio.

Though be warned, for some reason you can not change them back. Im guessing the modernflowtype is more of a trigger, with a plug-in running on it changing to update something in the resource, and creating a switch back wasn't prioritised for development.

{
  "error": {
    "code": "0x80048d0b",
    "message": "{\"errorCode\":\"InvalidModernFlowOperation\",\"message\":\"This modern flow's type cannot currently be changed.\",\"correlationId\":\"95c3fa83-ee4b-4c1a-bf3a-59850b4ea8b5\"}"
  }
}

So at this point we had 4 UIs, with them all running on the same infrastructure but 3 different billing methods, but that is now changing.

A recent announcement brought to my attention by the awesome Jukka Niiranen showed that Logic Apps and Power Automate were actually breaking up. Power Automate (inc Agent Flows and Workflows) have forked from Logic Apps and now have there own update and release plan. The infrastructure is no longer Logic Apps, but SelfHostMultiTenant. You can see this manifesting in 2 ways so far, the new http trigger URL, and the Express Mode. So yes, this divergence definitely feels like its for Agent Flows benefit, not Power Automate.

5. Workflows

And that brings us nicely to Workflows, this UI is still hot of the press and in preview in selected regions so subject to change.
Again looking under the hood there is nothing new, though this time its with Agent Flows (modernflowtype:1). There are some differences in practice, different connectors being the main one, and for now you can still select the same flow and open it as an Agent Flow and build in that UI.

With all of the updates again client deep compared to Agent Flows it feels that this could eventually replace Agent Flows (like V3 was suppose to replace Classic), though its less then a year old so that seems too quick for deprecation.

So what's the take away,

Well first Logic Apps is an incredible product, that is so well built its been the backbone for all automation in the Power Platform and will live on as the foundation
It doesn't look like we are going to get Code Flows (what's a Code Flow I hear you asking, well I was expecting Microsoft to create Vibe Coded Function Apps - which I named Code Flows - , but it looks like investment is not going that way)
Power Automate is not driving Power Automate anymore, Workflows (and maybe Agent Flows) are, as they need the Express Mode, and they are getting all of the investment. Power Automate is just coming along for the ride.
Expect more changes, now they have forked I expect changes throughout, including eventually the definition and one day https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json might disappear.

Part of me is excited that Power Automate will get all the benefits of the investment in Agent Flows/Workflows, but the other part of me is worried that just like before when Logic Apps drove the agenda, again Power Automate has to follow.

😎 Subscribe to David Wyatt

Let's Talk About Power Platform Environments

david wyatt — Sat, 25 Apr 2026 11:39:54 +0000

I had an interesting conversation with my Architect recently about Power Platform environments (aren't all chats with Architects always the most fun 😎), we have the most fun chats lol. And it made me think I thought about how they should probably change, and what the future holds.

There are 3 things that I want to talk about:

Quick Fixes
Big Fixes
The Future

1. Quick Fixes

The trusty Power Platform environments hasn't changed much over the years. Yes we have had managed environments and developer environments. But they are only skin deep changes, deep down nothing has changed. And that makes sense, as its the foundation of the platform so we can't go around making breaking changes.

But I think there are still a few easy win changes.

Well first lets go back to that elephant in the room, Dynamics. As the Power Platform is built on Dynamics, that means every environment is setup like a Dynamics instance.

Security Roles

There are a 100 security roles added to each new environment, now I don't about you but I have probable used less then 10, check out this list, how many do you even know, can you tell me what even half do?

#	Role Name
1	Agent 365 Tools Role
2	AIB Roles
3	AIB SML Roles
4	ApolloServiceRole
5	App Deployment Orchestration Role
6	App Opener
7	Approvals Administrator
8	Approvals User
9	Async ingestion
10	Basic User
11	BizQAApp
12	Bot Author
13	Bot Contributor
14	Bot Transcript Viewer
15	Bulk Archival Role
16	BusinessApplicationPlatformRole
17	Cards Basic Role
18	Cards Role
19	CCI admin
20	ContextualAIS2SRole
21	Data Sync Framework Role
22	Data Sync Service Role
23	Dataflow Maker
24	DataLakeFolderEntityContributor
25	DataLakeWorkspaceAppAccess
26	DataProcessingConfigTableAppAccess
27	Dataverse as a Cluster App Role
28	Dataverse Search Role
29	Deflection Service Role
30	Delegate
31	Delegated Mailbox Approver
32	Desktop Flow Machine Configuration Admin
33	Desktop Flows AI Application User
34	Desktop Flows Machine Application User
35	Desktop Flows Machine Owner
36	Desktop Flows Machine User
37	Desktop Flows Machine User Can Share
38	Desktop Flows Module Developer
39	Desktop Flows Runtime Application User
40	EAC App Access
41	EAC Reader App Access
42	Environment Maker
43	Export Customizations (Solution Checker)
44	Fabric AI Skill Role
45	Federated Knowledge Role
46	FileStoreService App Access
47	Flow-CDS Native Connector Role
48	Flow-RP Role
49	Global Active Metrics Monitoring Alerting Custom Role
50	Global Discovery Service Role
51	Help Page Author
52	Help Page Consumer
53	Insights Apps Platform Role
54	IntegratedSearchApp
55	Knowledge Manager
56	Knowledge Quality Service
57	Knowledge Quality Service Role
58	Microsoft Copilot Administrator
59	Microsoft Copilot User
60	Non-Relational Data App Access
61	Office Collaborator
62	Omnichannel CDS Flush Role
63	Portal Application User
64	Portal RP Service Role
65	Power Apps Checker Service Role
66	Power Automate AI Flows Application User
67	Power Automate Operator
68	Power BI Embedded App Access
69	Power BI workspace admin
70	Power BI workspace contributor
71	Power BI workspace viewer
72	Power Platform Data Analytics Role
73	Power Platform Dataflows Service Role
74	Power Policy App User Role
75	PowerAppsRPRole
76	PowerPlatformInsightsRole
77	Process Mining Application
78	Process Mining User
79	Project Background Services App Role
80	Purview Label Role
81	Report Service Role
82	RPE Role
83	Service Deleter
84	Service Reader
85	Service Writer
86	Solution Checker
87	SuggestedActionS2SRole
88	Support User
89	SupportUserCustomAPI Role
90	Sustainability all - full access Role
91	Sustainability all - ingest - full access Role
92	Sustainability BusinessUnit - full access Role
93	Sustainability BusinessUnit - ingest - full access Role
94	Synapse Link Service Access
95	Sync Permissions
96	System Administrator
97	System Customizer
98	Teams Chat Sync App Access
99	Tour Author
100	Tour Consumer

Imagine if we only had Power Platform specific roles, maybe:

Environment Maker
System Administrator
System Customizer

We then have an option to add roles like Approvals, Copilot Studio and Power Automate Desktop. All of the system ones for spn's could be abstracted away. Finally I would make basic user on by default, so if you access the environment then you are given the role. And any that are removed with no way to add could be documented so that admins can create them themselves if needed (or our friend Copilot 😎.

System Customizer

There is also the problem with the system customizer role. Its Dynamics day role was to allow the maker to create custom tables. Without it if you create a custom table you can't add data to it without a custom security role (so you need to make the table, then make the role, then use the table). The idea was sound, as it removed the environment settings but allowed the developer full access to the data in the non-prod environment. But as the Power Platform grew and became solution aware the plan broke.

Because the platform is built on the platform i.e. flows are stored in the same way as custom data, we have a big issue with our security roles.

You want to create Dataverse tables - System Customizer/custom role
You want to add data to a table without a custom role - System Customizer
You want to create custom AI builder model - System Customizer
You want to create a security role - System Administrator

Thats right to do any of the above development I need the permission to see all Dataverse tables, including system tables like flows. And if you want to give someone that secuirty role, well only admins can, because you could easily give yourself any role.

There needs to be a new role that is purely scoped to custom tables created by the maker. That way if you create a table you can add data etc, but no one else can until they are given permission.

Common Data Model tables

We also have the Common Data Model tables, as the environment owner I should decide if I want a Accounts table, don't waste my expensive Dataverse storage with unused/misused tables, and clutter it with tables I will never use.

Not only would you save all that Dataverse capacity you get the added benefits of:

Simpler to administor
Less vector of attack (unecessary roles and consitent database structure is a hackers Christmas)

The simple approach would be to have the tables in a solution you can download/add.

As this is a quick fix section, the easy update would be to enable admins to delete the tables, so I may be forced to include on setup but I can at least run a script/flow post setup to remove them

2. Big Fixes

In a nutshell an environment is kind of a container.

Containers are lightweight, portable software packages that bundle an application's code with everything it needs to run (libraries, dependencies, settings) into a single, isolated unit, allowing it to run consistently and reliably anywhere.

If you think of things like Dataverse tables, api's, model driven apps, as libraries, dependencies, settings, then it kind of makes sense.

In the Microsoft world you might even think of them as a Resource Group (I suspect under the hood they are). But a resource group is meant to act as a lifecycle boundary: everything in it is created, updated and deleted together. Guess what has a lifecycle boundary in the Power Platform, that's right a Solution.

So really a solution is a resource group, but its not treated like that. Because Resources groups also come with scope permissions to the Resource Group and its contents, Solutions do not have that, there is no permission to see a Solution, just its contents. A Solution is more like a filtered view then a folder.

And I think that contradiction has made a mess. And its because of the Dynamics, which treats solutions like components and the environment the container. If you see it through the eyes of Dynamics it makes sense, but through the eyes of the Power Platform it doesnt.

I think there needs to be a refocus, with the environments tending more to Power Platform needs.

We need to treat solutions more like the container. They need to have security roles scoped to them. So as an example a developer with a Solution Customizer role could:

See everything in the solution
Create custom tables and add data to them within the solution
Edit all flows/apps within the solution

But they couldn't:

Delete the solution
Create security roles at the environment level
Edit solution details

That would be limited to the Solution Administrator or other role.

This would bring the power platform in line with PoLP (Principle of Least Privilege), as someone who simply wants to create a custom table and security profile should not need permission to change the environment settings and view/edit all other developers work.

The other big issue, which Microsoft is trying to fix is hierarchy. Each environment is a totally separate entity. This is ok when you work within the environment, but what about when you work above. As a environment admin dealing with environments its not fun. Everything is siloed away, and getting a rolled up global view is only possible by a series of loops and copying of data.

The new Inventory setup in the PPAC is trying to solve this problem, and doing well. But under the hood it seems to be just doing the loops and copying for us, not fixing the underlying issue. It also is:

-Limited to Global Admins (PolP alert, though RBAC is planned)
-Limts data to PPAC

The environments should be structured in a hierarchy, with all platform data in one source. Then each environment role a given permissions to those records. Why have a hundred Security role tables when we could have one that is filtered to each environment.

Although that sounds like more work for the CoE, who now cant outsource environment administration so easily, it doesn't stop this, and it gives them greater visibility and control (and don't forget, with a Solution Customizer role you shouldn't need admins purely to create security roles).

3. The Future

So that's how I would fix enviroments, strip them down to focus on the Power Platform, and create lower-level granular security roles at the solution level.

But what about the future, well that's where I think the environment update becomes more important. The Power Platform is growing beyond Low-Code, for a long time the platform was simply to enable the low-code tools. But with the advent of AI, and the democratising of Pro-Code we are fast approaching a would where the platform becomes the value.

Code Apps prove this, if you think about it, I can now use GitHub Copilot to create feature which Pro-Code apps/sites, but that is only ski deep. Things like security, Auth, life cycle, deploying, load balancing, etc are all things that AI can maybe do, but not easily. Enter the Power Platform, now my AI generated apps are secure, have built in auth, deployments, roles, life cycle, everything that you would worry about, How cool is that, you have the walled garden that you can unleash AI in with a lot less risk.

For a while its felt like its hard to get improvements in the Power Platform unless its Copilot/AI related, so for a while I doubted updates to the environments would ever happen. But now with the ability to use the platform for AI generated code instead of Low-Code, I think it might get the support now, come on Micrsooft, lets get environments fixed.

😎 Subscribe to David Wyatt

Power Apps- Comparing Different Ways to Create Apps With AI

david wyatt — Mon, 20 Apr 2026 06:51:49 +0000

Its surprising just how many different ways there are to vibe code a app in the Power Platform, at last count I had 6, but I'm pretty sure I have missed a few. So I thought it would be a good idea to compare a few of them.

I'm limiting my list to just Code replated Power Apps (so skipping Plan Designer, as it creates Power Apps not Code Apps).

In theory that means everything will be React Apps, but just for the fun of it I'm throwing in my open source project Codeapp js, which builds standard HTML/CSS/JavaScript web apps and deploys as a Code App.

My plan is to do 2 demo apps and build them across:

Generative Pages
Vibe.powerapps.com
CodeApp using GitHub Copilot
CodeApp JS (using GitHub Copilot with custom Agent UI)

The only rules are that the same prompt should be used, and each can have up to 2 follow on prompts to fix any small issues.

Also some call outs to be made:

I'm going to use the model I think is the best at the moment, Opus 4.6, but for 2 of the options this is either no available or I don't know what is being used (but I'm 100% certain it wont be)
These are a very selective demo apps, with limited scope
I'm only build everything twice, and as AI is nondeterministic you will get different results each time
I created CodeApp JS, so I will probably have subconscious biases so keep that in mind

App One - Personal Profile App

This app is designed to create a quick one pager that shows our latest 10 emails and this weeks meetings. I chose it as it used 2 different connectors (office365 User and Outlook), used multiple actions per connector (my profile & and my profile image, my emails & my meetings). Its also should generate a mix of images, key information, and table data, so should push the design aspect of the solution.

And here's my prompt:

Create me a app that has all my key information to hand. It should open with a profile section, which shows my profile image, and other key information about me. Then it should have current 10 emails showing from, subject, when, and preview sentence. The final section should show any meetings this week, with time/date and title of the meeting.

Lets see how they did:

Generative Pages

Generative pages creates a React App like the other Power Platform solutions, but this one is designed to be embedded in a model driven app. This use case should still be possible, as it's not overly complex and sing those connectors is a definitely a possible use case.

I ran the prompt and sadly we didn't start well, it straight up errored:

Time for a follow up prompt, so I passed the error and asked it to fix it. And success it now showed a app, but.....

It was just place holder data, everything as hardcoded in the HTML. Time to bring out the final prompt, I asked it to make it dynamic and use the users connections.

Sadly its still a fail, it did get my details, but I think it got it from the SSO (like Power FX getUser() function does not use a connection, just the details from the top ribbon).

In the end I think the biggest issue is the model, GPT 4.1 is simply not good enough (in my experience nothing below 5.4 is at a good enough level, with 5.3 Codex ok).

The UI was pretty basic, but very inline with the Model driven app, so I think that's a win.

Vibe.powerapps.com

Power apps vibe is a skinned version of Code Apps (bit like what I did with CodeApp JS), When you look at the generated files you can see it is setup exactly same as Code Apps, with same power.config.json file, SDK, and TypeScript files.

I ran the prompt and it reasoned the right course of action, using Office 365 user and Outlook (I saw it reference support skills),

Sadly we had the placeholder result again.

You can see when looking at the power.config.json file no connections were created.

I did the follow up prompt asking for it to use the logged in users details, but after a bit of reasoning it said it had done it but in fact it had done nothing but create some follow on questions. I clicked the first option to get the users image but sadly again nothing happened.

I can't see the model used, but I suspect again it's 4.1, from the style it's definitely a GPT model (which is disappointing as it looks like generic AI generated content).
The good news was it performed less over engineering from previous testing, where for no reason it would spin up Dataverse tables and supporting Agents.

I also loved the UI, its clean and modern, and allows you to:

Prompt edit (select an element in preview and ask for edit)
~~Edit Code directly~~ I don't know if I dreamed this but I can't edit it anymore, fingers crossed it will one day

Code App with GitHub Copilot

We are now moving out of the Power Platform and into VS Code, so this is definitely less Citizen Developer territory. It requires node and the Power Platform CLI installed, all easy but can be intimidating. You also have to run cli commands:

Auth
Environment select
Initialise app
Create Connection

The create connection requires you to create a connection in Power Platform first and get the connector name and connection id.

I ran the prompt and sadly we were back in placeholder world.

But I think this was my fault, as I hadn't added the connections first. Adding the connections generates connection TypeScript files. Adding them and it worked first time (and second attempt first time too)

CodeApp JS Plus

Code App JS is pretty much a skin on top of the GitHub Copilot SDK, so it uses all the same model, the main differences are:

As stated it uses vanilla JavaScript instead of React
UI to add buttons for cli commands
Custom Skills and prompt/instructions

All that really matters in this test is the last, can custom skills/prompts make a big difference.

Amazingly it one shotted it and got it right first time (remember it using same model and harness as React Code Apps, and that would also have one shotted it without my mistake.

The big difference is the UI, as you can see that custom skill really helped (well I think it did, as it definitely doesn't look like the boiler plate UI's you normally see).

App Two - Kanban Board

No time for a slightly different app, this is more focused on data sources (Dataverse in this case), as I think this should help the built in tools more.

My favourite test is Agile Poker, but that is definitely not a minimal prompt app, so I went with my second, a Kanban board (like Microsoft Planner).

Create me a Kanban app, the app should allow the user to create and update tasks. The tasks should also have a status that can be Backlog, Ready, In-progress, Awaiting Review, Complete. Each status should be a bucket and the task card can be drag and dropped to change the status. The Dataverse Task table should be used to store the tasks

Generative Pages

So first attempt with Generative Pages and sadly not a good start, stuck in loading hell.

A couple of prompt fixes and sadly we didn't get anywhere except improved error message popups.

At this point I called it, sadly Generative Pages just doesn't work for me.

Vibe.powerapps.com

After failing last time I didn't have much hope but boy was I wrong, it one shotted it, fully working, and looking pretty good.

Again it's a very GPT looking app, but I wouldn't be disappointed with it, and with the ability to edit code and "point and prompt", I think I could customizer it more if I wanted.

Well done Vibe, and now Im thinking this is definitely not GPT 4.1, its either GPT 5 or maybe GPT 5.3.

Code App

I had high hopes for Code Apps, but it decided to swap with Vibe this time. First I had a build fail, though was a quick fix

After it made a nice app, that generally worked.

But sadly It had a couple of issues, first white font on white background, and second when I created a task the whole screen went white.

I tried to prompt fix, but I had to give up, though I think one or more and it would have been all good (but I had to be fair).

To make things more interesting I decided to try with GPT 4.1, so that we get a fair comparison with Generative Pages.

Sadly a build error again.

And even when I got it to load I couldn't get any working functionality, and it looked awful.

CodeApp JS

Finally we are trying Code App JS both both Opus 4.6 and GPT 4.1

I used the CLI version this time, yep there is a CLI version coming soon, watch this space. Under the hood its the same as the VS extension.

And good news, it one shotted it again, and again it made a nice look (though this time I think a little more generic).

Now for GPT 4.1, and first attempt it said it did a lot, but when I opened it it had done nothing 🤦‍♂️

But after a prompt to tell it to actually do something it made something that looked ok.

Sadly I could not get the create to work, and there was no popup for the tasks, but I could move them, so had a working, List Items and Update Item.

Round Up

So what does this prove, well not a lot really as my sample size was far too small, especially for something as un deterministic as AI, but I have some thoughts.

The model is just so so important, Opus 4.5 was such a leap in performance (along with higher Opus and GPT 4.6), and if you are using a older model you are leaving a lot on the table. Additionally GPT 4.1 is so legacy it should not be used.

I really hope Microsoft does either of these 2 things:

Allow frontier models to be used in Vibe.powerapps.com and Generative Actions (even if that requires additional billing), as vibe in particular has a lot of potential
Build their own model so that its cheap enough to offer to everyone

And the second could be so cool. If you look what Curser did with Kimi K2 as the base model and their training data from all of their uses, they ended up with Composer 2, which is up their. Microsoft must have the same or better training data from GitHub Copilot, so if they built on top of a Open weight model that could be amazing.

The other thought is how important having skills and prompts/instructions are. They can get measurable better performance, and definitely create more visually unique solutions. And as this is limited to outside of the platform solutions, I would recommended learning some new tools.

Oh and Generative Pages is just not good (I tried loads more and never got anything good), it really needs to be deprecated and Vibe.powerapps.com used instead.

All the apps are available to download from my repo here: [https://github.com/wyattdave/Power-Platform/

Generative Pages
My Diary
Task Board

Vibe.powerapp.com
My Dashboard
Kanban Board_202604110917

Code apps (React)
My Week - opus 4.6
Agile Board four six - opus 4.6
Agile Board - gpt 4.1

Code apps (JS)
My Update - opus 4.6
Kanban Board - opus 4.6
kanban four one - gpt 4.1

😎 Subscribe to David Wyatt