DEV Community: david wyatt

How to Create Your Own AI Coding Agent

david wyatt — Mon, 06 Apr 2026 06:10:11 +0000

Nearly all developers are taking advantage of AI coding tools, but what happens when you have a particular niche, where not only do LLM's have less knowledgeable, but potentially their knowledge is based on the general, which is straight up wrong for your niche.

This is what I found when making Power Platform Code Apps. Code Apps are full React apps that are hosted in the Power Platform. For that reason they have a specific SDK kit and cli commands. Models like Opus 4.6 do a good job considering how niche it is, but imagine when you then build someone bespoke on top of that niche. That's what I did, as I don't use React I wanted a vanilla JavaScript build (before you comment yes I know I should use React and Typescript, but remember I'm a little strange). This meant there was simply no training or even docs on it. And because it was using vanilla JavaScript, all of the training data actually kept sending the LLM down the wrong path. So at this point I wanted to create my own coding agent.

In general there are 3 ways to get a more bespoke model

Build your own
Fine‑tune or distil an existing model (optionally with reinforcement learning)
Prompt

You can imagine the path I chose, yep the easy one.

Prompt Overview
Platform
Implementation
Learnings

1. Prompt Overview

If you already know this feel free to skip, but I wanted to give a quick overview of the full prompt stack.

There are many levels to a prompt, each higher and more important, you have:

Model System Prompt

This is the highest level, often added by the model owner, it is for things like security and legality. It will cover things like:

Not to share how to do illegal actions
Not to encourage harmful actions
Not to share confidential information about the model Not an exhaustive list

Application System Prompt

Next level down, and this will be what the application you use adds. This covers specific tools the application provides, and pattern/mechanisms the app designer found to improve performance. Examples include:

This Tool reads the local folder
This Resource provides information about x
When dealing with cli ensure that authentication is validated first Theoretical examples, as these are closely kept secrets

Instruction.md

Instruction files are project specific instructions, these generally cover things like:

Naming conventions
Folder structure
Design principles
What Skills you want to be used when
Any learnings the LLM has made (you can set the agent to update the file itself)

This helps ensure the project is consistent and easier to read/maintain.

Skill.md

These kind of blur the line between prompt and context. They are specific instructions/knowledge sources for specific situations. By moving them out of the instruction the LLM decides when to add it in (kind of like a dynamic context/instruction). Examples include:

Instructions and Skills where created by Anthropic and designed for Claude Code, but other tools and models can use them to, just with less consistent or hierarchy results.

Your Prompt

And finally we have your prompt that you send, with any additional context.

2. Platform

There are a few ways I could approach this, but the ones I considered the most were:

CLI Wrapper
VS Code Extension
GitHub Copilot Extensions

I use GitHub Copilot so you can see why my choices are what they are, and with my experience being in VS Code Extensions, and the fact I like to hybrid write code with the agent, it made sense for me to build there, though one day I want to try a CLI wrapper.

Call out here, you will see later that you can get most of the functionality with just a well setup workspace, covering instructions and skills, but that's no fun 😎

Building in VS Code has some killer advantages:

Built in auth to GitHub Copilot
Built in terminal
Can have custom UI
Expand beyond text with buttons etc
No hosting/backend
Distributed for free in VS Code market

So once decided on platform the next step is the build.

3. Implementation

My AI Coding Agent was going to have 3 main advantages over simple GitHub Copilot

Simplified UI based CLI commands
System Prompt - built specifically to ensure the LLM didn't use its JavaScript training to go off plan
Skill files - all of the learnings from implementing CodeApp JS

Simplified UI based CLI commands
For Code Apps to work they require the Power Platform CLI, this gives the ability to authenticate, create connections, and deploy to the Power Platform environment. So to make things more LowCode and easier I want to abstract away those commands and make it more integrated.

For this I built a kind of pipeline based on button presses, these:

Setup the CodeApp JS files
Authenticated with tenant
Listed and selected environment (updating config files too)
Created connections based on what code was written
Deployed app

System Prompt and Skill.md
This were most of the value codes from, I've banded them together because they are created in the same way, with the only difference being system prompt is always used and skills specific to the task.

To create the right prompts and skills I kind of trained the model, and by that I mean I built lots of apps. During the process I made sure I read the reasoning, and every time there was a bug, built the resolution into the files.

Looking at my GitHub Copilot usage can you guess the days I was testing/learning 😎

It's time consuming, boring, and expensive, but by working this way the idea is to only make the mistake once.

And that's the real secret sauce, all I'm doing is learning from experience and then documenting it so that the agent knows what to do and what not to do.

I think this process of training/learning is key to all AI development, including Copilot Studio. You need to test, test, test, test, with each test generating a nudge/tweak to your instruction/prompt. This iterative approach improves results and consistency from your LLM's.

4. Learnings

There are a couple of things that definitely got me, and the biggest was dealing with context/prompt stack. I found when using the agent on my personal Copilot license it worked perfectly, but when I used my work account I would get failures with "No choices", and this was because my work account has lower context limits. This meant I could send less data to the agent, which was not good considering how small the code base is compared to full applications.

The issue with context limits can be massively impacted by how you build your agent. Incase you didn't know the prompt/context stack is everything you have to send to the LLM. See the LLM has no memory, so you have to send all of the history each time. And with the use of tools you don't actually send one request, but multiple. This can create a huge stack. Below shows this:

As you can see in the above not only was the all the system prompts etc sent, they were sent 5 times (and this is a simple example).

But what is worst is the last message to the LLM, the context stack at the end of these back and forth can get big, very big. As you can see the LLM wants to read files, write the code, and it wants to double check/test it by reading again. And that's how you can run out of context even with small projects.

There are a few ways to fix this (and a few bugs I found in my code).

The first and most obvious is getting your system prompts, instruction.md, and skill.md content down to the minimum. Make sure they are concise, don't duplicate, and are not too verbose.

Next is make sure you send only the right data, this is where one of my bugs was, I was sending all of the skill.md files every time. I tried getting the extension to pick the right files by keywords, but this often meant they were missed. In the end I passed a list/description to the LLM and got it to decide which ones it wanted. The other thing to do is use file trees and keep them tight. File trees allow the LLM to know what files are related and only to send the right ones. You can set how wide they are, but the wider equals more text sent.

The final approach is to deal with the context history. As I said you send all of the previous interactions back each time, but what if you can decrease that. The normal approach is compacting, this is where you ask the LLM to summaries the history and use that instead. It definitely works, but it can mean important context is lossed. The approach I tried was to break up the process and then remove unnecessary information.
I did this by creating a decision log file that is used by the LLM to store a todo list and any key decisions (also useful when returning for new dev session). The LLM then breaks up the project into tasks and completes one by one. When one is complete it updates the todo list and removes all of the tool calls and reasoning, leaving just results.

As with everything there are trade offs, you don't want to remove to much context, especially if most of your users have higher limits (new models keep pushing the boundary of input/output token limits).

Another issue I found was the model, it has such a big impact on performance. Using Opus 4.6/GPT5.4 would deliver great result, but dropping to Auto or GPT4.1 would deliver terrible results. There isn't much I can do here but recommend better models on setup, and look at some documentation how to prompt/structure your build better for older models.

The other issue I got was duplicate CLI installs. My laptop had a old CLI installed directly and a updated version from the Power Platform extension. This would lead the the extension giving the LLM the wrong CLI (the out of date one). This is a niche case, but it does show the risk is in relying on external dependencies like CLI's and VS Code extensions. There isn't much you can do here, but it did drive me to build more into the UI, and getting the LLM to tell the user to use the buttons when it is having issues. The simple truth is code is deterministic, so whenever you can, move the functionality to old fashion code and UI.

And there you have it, if I can create my own AI Coding Agent, anyone can.

If you want to try the agent it you can get it for free here https://marketplace.visualstudio.com/items?itemName=PowerDevBox.codeappjsplus, and if you want to learn more about CodeAppJS or contribute checkout here codeappjs.com

😎 Subscribe to David Wyatt

Setting Your Environments Up for Code Apps

david wyatt — Mon, 23 Mar 2026 06:41:41 +0000

Im not going to lie, Code Apps are now my favourite thing about the Power Platform (well maybe not, my heart still belongs to Power Automate, but man its close).

The reason I love it is because I always wanted to be a ProCode developer, but I never had the time or skill. I could just about build something with vanilla JavaScript, but libraries/frameworks lie Next.js, Vue and Angular, I didn't have the time. And although Code Apps are React based, with a little creativity you can build vanilla JavaScript apps instead (Power Apps - A Cooler Way to use Code Apps.

Now the truth is they are not right for everyone, and vibe coding them is still a little more painful then fun, but they are definitely cool and something you should be looking at.

So this blog is all about getting setup to build them, I don't think they are ready for citizen developers, but have potential for professional Power Platform developers.

Environment Setup
Content Security Policy
Code Storage
Code Reviews

1. Environment Setup

This one is quick and easy. For once Microsoft did the right thing and left something new as off by default. To turn on Code Apps in an environment goto PPAC, select your chosen environment and select features.

Then with a little scrolling you should see the option to turn it on.

2. Content Security Policy

This is one you might not know about, but is super important.
The DLP policy is the main way we secure the Power Platform, it's a whitelist for:

Connectors
Custom Connector Urls
HTTP Action Urls

and the good news is they work across Code Apps. As Code Apps should use the SDK to create connections just like a Canvas App.

But as we have said, Code Apps are React apps, which are JavaScript apps. So we can use simple JavaScript to call API's instead of connectors.

  const response = await fetch(
      `https://restcountries.com/v3.1/name/${encodeURIComponent(name)}?fullText=true`,
      { signal: currentAbort.signal }
    );
    if (!response.ok) throw new Error(`HTTP ${response.status}`);
    const data = await response.json();

    if (data && data.length > 0) {
      renderCountryDetail(data[0]);
    } else {
      showError(`No details found for "${name}".`);
    }

Example fetch api call

So how do we stop this, well good news Microsoft has thought of that. And by thought of that I mean use the existing PCF controls that allow you to edit the CPS (Content Policy Security), and guess what by default it is fully locked down (2 for 2 Microsoft, so proud of you).

The CPS can be found in PPAC environment settings, but instead of features its under Privacy + Security, scroll to bottom right and you will see it.

There are settings for Model Drive, Canvas, and App. We want App as that is for Code App.

As you can see by default it isn't on, and is blocking everything.

You can simply turn it off, but I strongly recommend against that even for innovation environments.

There are a lot of settings you can play with:

But the most useful ones are:

Use default frame-ancestors - sites where the app can be embedded
Use default connect-src - this is for those fetch API calls I mentioned
Use default script-src - use code hosted in a different location
Use default style-src - use css hosted in a different location
Use default img-src - use images hosted in a different location

And the 3 to be really careful with are:

Use default frame-ancestors
Cam allow any site to pretend to be the app, allowing the users can be clickjacked.

*Use default connect-src *
This is your dlp policy, so it exposes data exfiltration.

Use default script-src
This allows remote code execution, as you are running someone else JavaScript code in your app.

The image one is less of a risk but one you will probably hit, there are still small risks (data leakage, copyright, etc), so keep a whitelist is still recommended.

I don't recommend messing with the other settings (I personally would only stick with img-src and a little but with connect-src to start with).

In a counter intuitive way turning them off doesn't actually turn them off, it just switches to a whitelist, which by default is empty (3 for 3!). So you need to actively add your source.

You don't need to use wildcards (*) for all endpoints, only for subdomains. Which means you can enable for everything (not recommended) by using just a wildcard.

Example	Needed in connect-src
https://restcountries.com/v3.1/name/peru	https://restcountries.com
https://restcountries.com/v3.1/all	https://restcountries.com
https://api.restcountries.com/...	https://api.restcountries.com
Multiple subdomains	https://*.restcountries.com
Any URL anywhere	* (not recommended)

And you should be all ready. Just a quick call out, CPS runs when the browser hits the site, so updates don't always appear without closing and opening the browser.

More info can be found here MS Learn CPS.

Though I think it's important to say, connectors are by far the better way to go, if you need to call an external API you should be using custom connectors. Just some of the benefits include:

DLP is across tenant and environments so easier to manage
Stops you having to deal with storing secrets
It handles the risky stuff like auth

So if you are going to use it, is probably only good for unauthenticated API's.

3. Code Storage

Code Apps are stored in the Power Platform as simple HTML, JavaScript, CSS files (like Canvas Apps they are not actually stored in Dataverse, there is just a reference table - {{dataverseURL}}/api/data/v9.2/canvasapps?$filter=canvasapptype eq 4).

But it means you cant edit/build in the Power Platform, you have to build it code editing tools like VS Code. So if you want to edit it you have to export it in a solution, and this leads to the big problem, when building in React the code is transpiled to JavaScript, which is a one way process. So you can't edit it, which means you need to store the code somewhere else.

Quick all out, I mentioned I build in vanilla JavaScript, and one of the benefits to this is it's not transpiled, so as long as you don't minify the files you can export the solution and edit the files. Check out codeapp.js to find out more.

code app using codeapp.js

The best place to store your code is probably GitHub, its free, works great with VS Code/most code editors, and has features like version control/multi dev. But it's just code in files, so you can store it anywhere, the most important thing is to set up a central location and ensure its used, as else once its lost you cannot get it back.

4. Code Reviews

Not really part of the environment setup, but something I wanted to call out because it needs to be part of you deployment process between environments. As Code Apps use standard code it means that your normal code review process wont work, tools like appreview-pro don't support them (yet 😎), on top of that there are more risks/vulnerabilities.

But on the flip side it's just code, and this is a tried and tested path, so there are already lots of tools for code scanning/reviewing, just use your organizations preferred tool.

But that then leads to the broken line of trust, as what is deployed is transpiled, how do you review it? I recommend that your deployment pipeline changes, and you do not follow the standard Dev - Test - Prod, you need to deploy from your repo to Test - Prod, and that needs to be done by someone who is not the developer, and after they have completed the code review / scan.

And that's it, you should have the foundation to build safe Code Apps, but as I said I still don't think they are right for everyone, but they definitely are something you should explore/have in your toolbox, and are definitely cool 😎

If you want to use the demo app I created that uses https://restcountries.com/ api you can download it from my repo here: https://github.com/wyattdave/Power-Platform. Its built with https://codeappjs.com so you can read all of the code too.

😎 Subscribe to David Wyatt

Power Apps - A Cooler Way to use Code Apps

david wyatt — Mon, 16 Mar 2026 07:13:12 +0000

If you don't know about Code Apps in the Power Platform let me quickly fill you in.

They are full React apps that are packaged and deployed through the Power Platform.

Because they are piggy backing off the platform infrastructure rather then part of it there are some callouts

You don't build them in the platform - you use VS Code (or other coding tools)
The development code is not stored in the platform (only the built code)

This means you don't user make.powerapps.com and even a unmanaged solution for development, as once in the platform you can't really edit them (without hacking open the solution file).

The thing is, code apps are obviously not LowCode, you need fully trained developers to build them, so why would it be in the Power Platform?

Well there will be some developers who use it purely to avoid setting everything up in Azure and avoiding the pain of auth, but i think the real answer is vibe coding.

I wrote a blog already about how you can use GitHub Copilot to build Code Apps vibe coding a power app the pro way with codeapps, but in my opinion using AI for development is best when you can read the code.

So that had me thinking, I can read basic JavaScript, HTML, and CSS, React is just compiled to this. And looking at the code app in the solution, it is just JavaScript, HTML, and CSS. So can I just build a normal web app and deploy that instead of React.

And the answer is yes 😎

The starting point to look at is the dist folder, this is where the React code is built into normal web tech.

As you can see, it's just a index.html file, a JavaScript file, a CSS file, and a image file.

So straight away in theory we could just drop our own code in and it should work.

Well not quite, and that's because we are running it inside Power Apps, so we need to communicate specifically with Power Apps.

And this is where we need the the Power Apps SDK. Looking in a normal code app the code is in the Power Apps node library.

As the code is spread across multiple files, and in TypeScript, it's not easy for use to use.

We could use the built file from a test app:

But it's incredibly hard to read, may not cover everything we need, and has any app specific code included.

So to make sure it covered everything it's time to bring in a partner, and in my case its Opus 4.6. After a few tries I managed to get it to create a JavaScript version to use.

But although its fully functional, it definitely isn't readable, so this is when I decided to build bridging functions. These functions create a easy to use code that then calls the sdk.

Now all I need to do is import the functions I want and build my own JavaScript code.

Our Index.html now looks something like this:

<!doctype html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>YOUR APP</title>
    <script type="importmap">
      {
        "imports": {
          "@microsoft/power-apps/data": "./power-apps-data.js"
        }
      }
    </script>
  </head>
  <body>
    <div id="root">hello world</div>
    <script type="module">
      import { createItem } from "./codeapp.js";
      async function boot() {
        //on load code
      }
      // code
      boot();
    </script>
  </body>
</html>

power-apps-data.js is the sdk
codeapp.js is the bridging functions

And now we have a working HTML,JavaScript, CSS app. We still need to do some more bits to make it work, and this is all around the Power Platform CLI (so we still need that installed).

You need:

Create power-config.json file: _pac code init --displayName "" _
Sign into Tenant: pac auth create
Select environment: pac env select --environment "environment-id"
Create connection: pac connection create --name "connection-name" --application-id "app-id" --client-secret "secret" --tenant-id "tenant-id"
Add data sources (for all connections): pac code add-data-source -a "connection-name" -c "connection-id"
Deploy to Power Platform: _pac code push --solutionName YourSolutionName _

And thats about it.

If anyone this sounds interesting to you, I've created a couple of things to get you started.

codeappjs.com is all of the files needed for you to build your own JavaScript Code App. It also goes into a lot more detail around functions, and provides working demos.

Currently it has 5 connectors:

Dataverse
SharePoint
Office 365 User
Office 365 Outlook
Office 365 Groups

But it's fully open source, so hopefully everyone can add more.

To use it yourself you can either:

Download simple zip file with all the files
Clone the GitHub repo
Install from NPM
Use CodeAppJS Plus

What's CodeAppJS Plus, well I'm glad you asked, it's a AI Coding Agent built specifically for JavaScript Code Apps. It runs as a VS Code extension, with a chat interface for prompting your Code App, it also has CLI commands set as buttons for easier use.

It still requires the Power Platform CLI, and GitHub Copilot, and obviously VS Code to run it.

Install it here

So why did I convert React to Vanilla JavaScript, well a few reasons:

If you have read some of my previous blogs you will know I'm a little crazy
I can code in JavaScript and I wanted to code my own Code App
In spirit of LowCode I wanted to make it a little more simple
Believe it or not AI seems to deliver better results then React

Example Kanban app created in CodeAppJS Plus

I never did quite understand why Microsoft has gone with React as the vibe coming language.

React has 3 main advantages

Its declarative (desired outcome) vs JavaScripts imperative approach (sequence of tasks)
Great for reusability
Handles complex state management better

But here's the thing:

Prompts by their very nature are declarative
Reuse is less important when agent is doing all the work
Power Apps are very very rarely that complex that they need better state management

So why use React when its a lot more verbose, wasting tokens, and buld step adds more tool calls.

If you want to see how I made my own AI Coding Agent, check out my next blog.

😎 Subscribe to David Wyatt

From Low-Code to AI Development

david wyatt — Mon, 09 Mar 2026 07:18:23 +0000

There doesn't seem to be a day that goes by without a post or article stating that "Low-code is dead", and while this isn't true, with AI development things are definitely changing.

Although working in low-code tools like the Power Platform is my job, in my spare time I like to pretend to be a pro-coder, and with AI tools now at a level that I can almost not pretend.

So this blog is all about how I do AI development, its probably not the right way, or the best way, but it works for me.

My Skill Base
My Setup
How I Build

1. My Skill Base

As I said, I'm not a pro-code developer, but I know a few things. And I think it's important to understand that using AI tools with no understanding only leads to deferred pain. I think there are big differences between AI Development and Vibe coding.

So what do I know:

Basics of HTML, CSS
A little more than the basics of JavaScript (I may not be able to write all of it but I can read it)
GitHub (barely)
Git Bash, wrangler (barely)
Cloudflare workers and Pages
Cloudflare Database and Keyvaults

But I don't

Understand React
Use TypeScript (but I could as do use it in OfficeScripts)
Bother with any sort of build process
Work on the main branch(unless I want a non-prod instance)

But my mind is like this, React gets built to Html/CSS/JavaScript, so why not skip a stage and get the AI to just build it direct.

2. My Setup

I'm not into CLI's that much, so no Claude Code, and Cursor is expensive, so that leaves good old VS Code (plus I get GitHub Pro as an MVP reward 😎). The output window is ok, but I don't just read the agents outputs, I like to see the code, so it works for me.

I'm a Opus man, infact Opus 4.5 was when I felt confident to move beyond AI Assisted Development to full AI Development. 4.6 is better but not significantly. If Opus is having a bad day I will get Codex 5.3 ago (looking forward to testing 5.4), and Gemini 3/3.1 is worth a go when you want something more visually creative. But 9 times out of 10 its Opus for me, but that's more of a personal preference, as most of the top models and some open weight are perfectly good enough.

One of the most important things I think you need before you start AI development is an instruction file. This is like a custom prompt that you use to ensure the agent works the way you want. It shouldn't be too big, and I personally don't let the agent write its own.

My instruction file covers a few things but the main ones are:

Naming convention
File structure
Language preferences (as example Opus like JavaScript var's, where I'm a let guy)
Coding preferences

The last one is the big one, I like my the LLM to work in small units, building in function blocks. That way changes are often contained, it's easier to read, and everything is reusable.

This is my current instruction.md file:

# Copilot Instructions for AutoReview Pro

These instructions guide AI coding agents working in this repository to be immediately productive and consistent with project conventions.

## Project Overview
- standard web technologies: HTML, CSS, JavaScript (ES6+).
- Core files:
  - `index.html`: Structure, assets, and script/style inclusions.
  - `styles.css`: responsive and built to light/dark themes using CSS custom properties.
  - `script.js`: key functionality of the site
  - `dom.js`: dom manipulation functions
  - `imgs/`: image files for UI icons.
  - `README.md`: Features, usage, and future enhancements.
  - `Sitemap.xml`: for search engine indexing.
- No build step.
- Create as a Progressive Web App (PWA) with service worker for offline support and caching, but with always fetching latest data when online.
- cloudflare hosting

- Follow these naming conventions:
  - Use camelCase for variables and functions.
  - Prefix variable names: `b` boolean, `i` number, `s` string, `a` array, `o` object, `e` element.
- Ensure variables are type consistent and avoid implicit type coercion by using naming conventions.
- CSS should be in a separate file, avoid inline styles unless for dynamic styling.
- JavaScript should be in a separate file, avoid inline event handlers and scripts in html.
- JavaScript files should follow: script.js for main logic, dom.js for dom manipulation functions, specific js files for large logic, and per html page for page-specific logic.
- Function-first approach; avoid classes unless necessary.
- Build functions for reusability and testability.
- Use descriptive names for variables and functions, avoiding abbreviations.
- Use let and const, avoid var.
- Use const for dom elements where possible.
- Use `//` for single-line comments and `/* */` for multi-line comments.
- Use forEach, map, filter, reduce for array operations instead of for loops where appropriate.
- Use arrow functions for anonymous functions and callbacks.
- Use " for html attributes and ' for js strings, ` for template literals.
- Use `new RegExp("pattern","flags")` (avoid literal `/.../flags`).
- Use `fetch` for API calls, with async/await syntax.
- Handle errors gracefully with try/catch and user-friendly messages. 
- Follow the existing code style and conventions in the project for consistency.

I also have a few skill.md files for specific tasks (skills are similar to instructions but the LLM uses them when necessary), my favourite example is frontend-design skill from Anthropic.

https://github.com/anthropics/skills/blob/main/skills/frontend-design/SKILL.md

This is an example of a prompt I will use to help start:

create me 5 landing pages for my website. the site provides training, consultancy, and custom builds. Each site should be creative and unique, they should follow a modern design. To aid review create a way to navigate between the 5 pages. Make sure you use the frontend-design skill.

You can see them all live here

3. How I Build

My approach to using AI is to use it very much like a tool, I want it to do a specific thing. This means the scope and outcome if focused and generally small. Over time and with improvements of the models I've felt more confident in increasing the size and complexity of the thing.

In my mind this evolution can be broken them into 2 categories, AI Assisted development and AI Development.

AI Assisted means that I lead the agent a lot more, I normally prompt at a function level, and then I review the output and then link everything together by hand. The reason I like this is:

The context is small for the LLM so its normally better results
Its contained so easier for me to review
As I'm doing the linking and using I still understand everything

A good example was when I was building my code review tool AutoReview-Pro, I had a lot of JSON data that I wanted represented as HTML tables, so I used this prompt

Create me a function for converting JSON to HTML, I will pass in 2 arrays. The first will be the array of data, the second will be configuration. Each item in the configuration will represent the columns in the output, each item will have these keys: Name - field from the data array, Display name - name of the column in the header, Width - width % for the column, Link - field to use when clicked, this is optional and if not included it should not include a link

After reviewing the function and testing it I then used it in my code where I wanted it.

But as the models have become more powerful I have felt more and more confident moving to AI Developed. You can think of this as the next level up, where the scope of work increases and the detail in the prompt decreases. I now want to create a piece of functionality/value in the project. A good example would be:

I want the users to be able to download the entire collection. The button should be next to the edit collection button. The output should be a postman collection file and be downloaded to the users device. Use the toast function to update user with success/fail messages.

As you can see the piece of work is now:

Larger scope - updates 3 files: JavaScript, HTML and CSS
Less involvement by myself - it links everything together
Simpler prompt - half the length

There is trade off that it's harder for me to review the output, and I'm more inclined to be lazy and just trust it. So there is potential for some tech debt in there and missed dege cases, but it moves me from being 5x faster to 20x faster, so I would say it's worth it.

In both use cases I have a golden rule, which is "I do small updates". If I need to update a colour of an item, I go into the CSS and edit it, if I want a button moving, I moved it. This is because there is minimum time saving, it removes the risk of double code and it forces me to understand the code based.

Double code - this is one of the biggest issues I see with agent generated code, the agent solves a problem in 2 different ways (e.g uses CSS and JavaScript when solution only needs one), this makes it hard to read, really hard to debug, and can generate bugs when the 2 different ways clash.

There is also the elephant in the room with AI development, Vibe coding. Do I vibe code, yes, but do I do it for anything important no.

In my view the main difference between AI development and Vibe coding is scope and understanding.

Whn vibe coding I scope everything to the agent, and I don't understand the output. If I was to ask a agent to create me a app that did x, it would most likely:

Create a React App - I can't develop in React
Design/architect in a way that I'm not use to
Build to its training, so generally make something that looks AI generated

So when I do vibe code I ensure my instruction.md file is used, that at least means it builds in something I can develop in and generally the way I like it.

I also don't do it for anything important, anything where if it broke I would be in trouble if I could not fix it.

And that's how I now build, when I look back at the last year and some of my projects and the level of AI involvement, its crazy.

Flow Utilizer - 100% me
AppReview-Pro - 80% me
AutoReview-Pro - 50% me
Power Platform Undoc - 20% me

And look at those sites, it's hard to argue against the agent being a lot better at building then me.

😎 Subscribe to David Wyatt

Power Automate - Why You Should Love Coalesce

david wyatt — Mon, 23 Feb 2026 08:04:33 +0000

One of my early blogs I spoke about how I love Do Unitil loops, and Im sure some people thought I was a little crazy, and now I'm talking about loving a expression, and I think everyone now knows Im crazy. But trust me, after a read you might be joining me on the coalesce side 😎

What is coalesce
Simple uses
Cool uses

1. What is coalesce

Well in a nutshell coalesce is designed to handle null/undefined values. So if you have a optional field in a action response you can use coalesce as a kind of if statement:

If value-is-not-null
  use-value
else
  use-this-value-instead

You can also stack more then one value, so it could be:

If value-is-not-null
  use-value
else If value-is-not-null
  use-value
else If value-is-not-null
  use-value
else If value-is-not-null
  use-value
else
  use-this-value-instead

The key things to remember is it will run sequentially, so the first valid will be returned, and if there is no match the last one will be returned (so always make the last is valid).

Coalesce also requires one type, so you cant have the first value a integer and the second a string, they would all have to be the same.

The last thing to call out is this is not a replacement for empty(), as blank strings and empty arrays will be classified as valid.

Input	Coalesce	Empty
undefined	true	true
null	true	true
"" (empty string)	false	true
{}	false	true
[]	false	true

Full MS Docs here: https://learn.microsoft.com/en-us/azure/logic-apps/expression-functions-reference#coalesc

2. Simple uses

The out of the box use for coalesce is when you are working with unstructured/inconsistent data. Actions will often have optional fields, which will mean if you reference those fiels you get a null value. Null values could break the action, or show unpleasant value to the end user.

So in the below example, how would you get the powerAutomate year for all users, when not all users have the certificate?

"value":[
  "user":{
    "name":"David",
    "location":"Nottingham",
    "certificates":{
      "powerAutomate":{"year":"2020"},
      "powerApps":{"year":"2022"},
      "copiltoStudio":{"year":"2024"}
    }
  }
],
[
  "user":{
    "name":"John",
    "location":"Timbuktu",
    "certificates":{
      "powerApps":{"year":"2024"},
      "copiltoStudio":{"year":"2024"}
    }
  }
]

This is where you would use a coalesce:

coalesce(
  items("For_each_User")?['user']?['certificates']?['powerApps']?['year']
,
  'Has Not Completed Certificate'
)

Likewise this can also be used for manual flows with optional inputs.

You could do it with a empty() expression and some if()s, like this:

if(
  empty(items("For_each_User")?['user']?['certificates']?['powerApps']?['year'])
,
  'Has Not Complete Certificate'
,
  items("For_each_User")?['user']?['certificates']?['powerApps']?['year']
)

But doing nested if()'s would be a lot more complicated, compared to a coalesce():

coalesce(
  items("For_each_User")?['user']?['certificates']?['powerApps']?['year']
,
  items("For_each_User")?['user']?['certificates']?['powerAutomate']?['year']
,
  items("For_each_User")?['user']?['certificates']?['copilotStudio']?['year']
,
  'Has Not Completed Certificate'
)

3. Cool uses

We will all agree, that although super useful, the above scenarios are not that common, so why would I love coalesce, well its because of another cool way to use it.

If you have read some of my previous blogs I want my flows to be optimised and efficient, no unnecessary actions (I deep dive more into it here The Direct Methodology). And coalesce will be your best friend for removing unnecessary actions, and that's because it's brilliant for conditions and switches.

Here's an example I see often:

The output from either branch is needed after, so its stored in a variable, makes sense right. But with a coalesce you don't need that variable, simple use the outputs where you would normally use the variable

coalesce(
  outputs('Get_a_row_by_ID')?['body/fullname']
,
  outputs('Get_a_row_by_ID_2')?['body/fullname']
)

And because you can have multiple inputs this can also be used on a switch.

There are some challenging situations, but again these can be done with a little creativity.

First Item
First is great when you want to grab just one row from an array (if only there was a real lookup expression), but that can break the coalesce, as the first throws an error not a null because a null has no length. But you can fix it like this

coalesce(
  first(
    coalesce(
      outputs('Get_rows')?['body/value']
    ,
      createArray()
    )
  )
,
  {"fallback":"hello world"}
)

So we first check if the array is null, if it is then we create empty array. Then we check to see if first item is null, if it is we fallback.

Array or Object
What happens if we wanted if a Get_item or Get_items, we know coalesce has to have the same type so it shouldn't work. Well again a little bit of creativity we can do it.

coalesce(
  outputs('Get_rows')?['body/value']
,
  array(outputs('Get_a_row')?['body'])
)

The reason this works is because our conditon means we always know either the Get_rows or Get_a_row will return a value. As the create array() will throw an error if Get_a_row is null, we do that second, ensuring it is never null.

As you can see coalesce has the power to remove multiple actions, a flow easier to read and saving API calls (remember a standard license only has 6k API per day and every call has a carbon footprint).

And that's why I love it, and there are over 140 expressions in total, so when building your next flow, try an expression before an action 😎.

I did a list of my favourite expressions to give you a head start.

Also I created a quick reference page with all the expressions and a Excel file you can download here Power DevBox Expressions

😎 Subscribe to David Wyatt

Power Automate - Building Readable Flows

david wyatt — Mon, 09 Feb 2026 06:49:58 +0000

They say the best code is written in a way that you don't need to add comments, just good naming and design, and that had me thinking about Power Automate.

Power Automate is a literal flow chart, flow charts were created to make processes easier to read. So why can't I understand what the hell some flows do!

And that's what this blog is all about, how with a few small changes you can build your flows in a way that anyone can open and understand 😎

Planning
Naming
Notes
Design

1. Planning

This one is kind of obvious but still very important. The biggest reason flows become hard to read is lack of planning. If the developer takes a "figure it out as i go", then the end result is disjointed and confusing.

So for every flow you should plan out a couple of key things:

What's the start state of the flow
What's the end state of the flow
What pieces of value happen within the flow

I recommend a lot more planning personally (Power Automate - 4 Steps to Building a Flow), but if you have these basic ones it will really help make the flow structured and consistent.

2. Naming

Naming things right will have probably the biggest impact on the readability of your flow, there are 2 golden rules:

Describe in clear language (no abbreviations)
Be consistent

I have 2 patterns I follow:

Variables

Variables need to clearly explain what data they are going to hold and the type of variable.

Variable	Type	Example
sVariable	string	sEmailSubject
iVariable	integer	iRowCount
bVariable	boolean	bFoundEntry
oVariable	object	oUserRecord
aVariable	array	aAllMatchedUsers

Actions

Actions have an additional requirement, what action it is. As all actions share the same connector image, if you remove the action type it can be really hard to read.

As example, how easy is it to read the below flow, how about can you tell me what the 2 actions do?

Guess what i do is create item, Guess what i do2 is delete item, quite a lot to get wrong lol

So actions must keep the original name of what they do. How much easier is below to read.

Again with consistency, all mine are Action - description. I also ensure the description is detailed enough. I could just put Get Items - records, but by adding the filter query of over 10 days old I can get a lot better understanding of what the flow is trying to do.

3. Notes

Yes I know my first sentence made out that you dont need notes when you create clear solutions, but its not true. Notes are such an under utilized feature in Power Automate. You don't need them everywhere, but there are a couple of times they can be really useful.

Expressions

If you have one of those beautiful expressions that use multiple functions to come up with an amazing solution (you know the ones 😎), without the developers insight and understanding these can be incredibly hard to understand let alone edit. Dropping in a comment that explains what the expression does and can make everything make sense (including for future you who has forgotten what the flow does too).

Solutions Through Pain

Again another one that we all experience. When something that should work just doesn't and you have no idea why (lets be honest its normally Power Automates fault but anyway). Through blood, swet, tears, repeated trial and error you come up with a solution. This where a note is so important, not only does it explain what its doing, but it also explains why the expected way doesn't. I've done it before where I refractored a flow, thought the original developer was mad and rebuilt the "right way", only to find it didn't work. I then had to suffer the same pain as the original developer to get it working again.

4. Design

Design is the probably the most difficult to nail, as it's more of interition. But there are a couple of key call outs that good design should have to make the flow easy to read.

Keep It Short

This is kind of obvious but often the most common not done. Keeping your flows short makes understanding your flow so much easier. And there are 2 main ways to do this.

The obvious is to use less actions, and this can be done by:

Removing unnecessary actions like variables and composes
Using right actions like filters instead of conditions
Ordering your actions before and after branches

The last one is probably the most under utilised but can add make a flow so much easier to understand.
If you duplicate actions in branches it easy to think they could be very different paths, but if they are the same except for inputs, then moving to after the branch and using a coalesce() ensures everyone understands its the same.

The other way is to split the flow into childflows. That way we make the actions more relatable. Though this can only be done when the actions are related and/or complete a specific piece of value. This rolls in nicely to the next design principle...

Grouping Actions

Actions that are directly related or complete a specific task should be grouped together. When you create your flow don't think of it as one flow full of actions, think of it as stages, and each stage should have actions. This design principle has 4 levels:

Ensure related actions are next to each other
Name the actions in a related way
Add the actions into a scope
Move the actions to a childflow

The scope is the most common used but in my opinion should be the least used. It adds nesting (see later), and api calls, and in most cases naming in related way is just as good.

Simple Paths

And this is the big one, you need to keep your paths simple, and the 2 biggest impacts to flow paths are:

Branching
Nesting

Adding branches means that you are now trying to understand each decision on its own, losing focus on the overarching point of the flow. It also forces duplication of actions which again can mislead the developer in to thinking its differences are bigger.

Nesting is similar, with how Power Automate is displayed it is easy to lose what level you are in and the impact of each of those containers.

Understanding what each of those nesting boxes means and how it impacts values can be incredibly difficult.

I strongly recommend you check out my previous blog about 'The Direct Methodology' which deep dives into how the other benefits of simple paths and techniques to enable it.

Think Like a Human

I see far to many flows that follow a very unnatural process path. I'm not saying you should copy the human process, but you need to follow the same logical steps a human would. My best example for this is handling 2 different outcomes in a loop.

Nearly everyone would make a flow like this:

You loop over every interview form, if passed then send passed, if failed then send rejected. But is this how you would do it in real life? I suspect you would sort into 2 piles by pass and fail. Then work through the passed, then work through the failed.

Easier to read ✅
Easier to read logs (i can find nth passed so much easier) ✅
Uses less api calls so maybe a ✅

If you make your process follow those human 'common sense' steps, then it is instinctively easier to understand.

As you can see there are some simple steps that add little development time that can make your flows so much easier to read, and trust me, future you will be so happy when debugging a critical issue 😎

😎 Subscribe to David Wyatt

Power Platform - Dealing With Tech Debt

david wyatt — Mon, 26 Jan 2026 07:01:21 +0000

In my opinion, one of the biggest dangers to any Power Platform setup is technical debt.

Technical debt is the implied future cost of reworking software caused by choosing an easy, fast, or suboptimal solution today instead of a better, more robust approach. It acts like a financial loan; while it speeds up initial development, it accumulates "interest" in the form of harder maintenance, increased bugs, and slower future development.

Reading the above definition its easy to think that low-code tools like the Power Platform decrease the impact of technical debt, and that's kind of true:

It's easy and fast, but robust

but the risk of tech debt in low-code tools is there, just in a different format

The Risk
How To Manage It
Low-Code and AI

1. The Risk

Low-Code technology builds on a foundation of re-use. Components are standardised, so custom code is minimalized and the risk of tech debt is drastically diminished.

The problem is there are 2 sides to tech debt, code and implementation.

Reading the code is one part of it, working through the choice of structure, functions, libraries etc, most of which is pre-created in the Power Platform.

But then we have implementation, its the next level up:

Why use an action in a loop instead of a filter
Why use a variable there
Why chose a flow instead of in app

and although implementation has less impact then code Low-code introduces 3 magnifiers:

Quantity

What's great about the Power Platform is its free (excluding premium functionality) for E3 and F3 licenses, so it's available to almost everyone, and that means volume.

Each flow or app maybe simple, and have minimum complexity, but the sheer number can break any CoE team. Just figuring out what something does takes effort, and dealing with so many diverse solutions can be tsunami.

Lifecycle

This is the real kicker, Power Platform solutions generally start as personal or small scale, so there is no plan for the life of it. And in the life of every Power Platform solution you are going to have 2 potential big life events:

Growth - adoption grows, new features are needed
Ownership - the developer moves on

Both mean implementation goes "wonky", as growth means building on top of something that wasn't planned to be built on (imagine a house with single story foundations having a second story added). And ownership changes often means that any updates are done in a totally different way. With design patterns/styles mashed together, making understanding even harder.

Engineering Mindset

An engineering mindset refers to the values, attitudes, and thinking skills associated with engineering. Engineers solve problems using systematic, iterative processes.

Low-Code allows people who don't have the time or opportunities to learn the deep technical knowledge to be a developer, and that's a massive pool of talent which makes Low-Code so valuable. But it also allows people who, without being rude, maybe shouldn't be developing.

The engineering mindset is key to being a good developer, and generally that ensures a foundation of design decisions that allows others with the same mindset to gain a quicker understanding.

So you will often find solutions that are even harder to understand, as although they solve the problem, it maybe in a very unique/unconventional way.

As the risk is still there, what is the possible negative outcomes. If you don't manage technical debt then your Power Platform will run great for a couple of years or so, but in that time 2 things will happen:

The solutions will become critical - roles taken on extra responsibility so can't handle the manual workload anymore. They also scale from personal/team to broader departments.

The original developer moves away, they get promoted or leave the business. The solution gets handed over a couple of times, but each transition is to someone less interested and knowledge is lost.

It starts off as one or two, but soon the CoE is undated, solutions that are too big to fail, with no team available to own it anymore, they are what we called orphaned.

And now you are desperately trying to figure out how they work, the issues that were manually handled, and how to make them stable and scalable.

And trust me when I say this, it will be a tsunami, and every solution you take on means less time to support new, often more critical, solutions being delivered.

2. How To Manage It

As a CoE you need to get ahead of this risk, and ensure that there is no technical debt. As no matter how hard you try and how many agreements you have, that orphaned solution will keep going up the leadership pyramid and until there is someone high enough to override all your agreements.

Standard Operating Procedures (SOP)

Every Power Platform CoE team should set up their standard operating procedures, these are the agreed way to do things. Often there are many different "right" ways to solve a problem, but to ensure easier understanding and less tech debt one right way should be agreed. This is your SOP, it should cover things like:

Naming Convention
Design Styles
Integrations/Connections
Environment Variable design
Solution Setup
Access Management

Having this documented ensures that every developer can start on the right path (if they decide too that is).

Training and Certification

MS Learn is great, and has some fantastic modules, but it's not enough. YOu need you own foundation training process. It should cover the nuances of your setup, your SOP's, and broader governance. Ideally you will mix in some MS Learn modules (but be warned Microsoft loves to change them with new features that you may not have enabled, I got burnt by a rogue Power Automate Desktop module in middle of a Power Automate Cloud module).

Lock Down The Default

Unfortunately Microsoft created the Default environment which means you can't easily get involved with the developer before they start building. But what you can do is limit the scope. The DLP policy should be very limited, only unblockable connectors, Dataverse should be moved to the non-business group so that it can't be used with anything else. No credits should be assigned and premium user licenses only given to makers who have completed training.

If you are able to make in a managed environment then do it, limit app shares to max 5 and flows should not be shared with security groups.

You should add what I call "Platform Flows", these are Power Automate flows that retrospectively fix issues that managed environments cant (and what you should use if you don't have managed environments). Examples I have include deleting Copilot Studio Agents and Agent Flows, and limit the number of flows a developer can have, any more they get turned off.

Automated Process to Prod

Now you have limited the risk in Default you need a pipeline to scale, and I don't mean automated deployments. You need a process where developers can:

Submit idea and CoE validate it (Intake Review)
Arch & Security Review
Review proposed design (Design and Impact Review)
Review code to ensue meets Arch/Sec/Design suggestions and SOPs
Document Solution
User Acceptance test Solution
Deploy to Prod (Separation of duty and change control)

There are lots of out of box solutions for this, but you also have one of the most powerful development platforms at your disposal, so a custom app, automation, and database to handle this is at your fingertips.

Documentation

Linked to the above and a necessary evil, but so important. Solutions need to be documented, the should include at least a Simple Design Doc and Simple Design Goal to help explain what the solution does. Additional information about NPROD environments, environment variables, and access is also key.

Monitoring

The final thing we need to do is keep close eye on our platform (not that easy with the Power Platform), we should be looking for solutions that are scaling or growing beyond our controls. Identifying them early and moving them through the process is key, as no matter how good your setup, new unique scenarios will emerge.

3. Low-Code and AI

Now here is the big picture, AI tech debt is Low-Code on steroids.

You think the volume of Low-Code solutions is high, wait till developers make 10 apps/automations per day
You think the volume of Low-Code developers is high, wait till there are 10x more developers

Then the real kicker, the foundation of reusable components that Low-Code is built on is gone, now layers of spaghetti code trained on non-quality controlled code.

So the volumes are higher and the code harder to understand. And I know the expectation is that AI can fix tean create documentation, but:

There will always be outline requirements/bugs that AI just can' solve
AI lacks the understanding of the solution, so it's docs are always skin deep.

Tech debt isn't a Pro-Code problem, it's not a Code problem, it's a development problem, everything developed creates tech debt, you just need to manage and mitigate it.

😎 Subscribe to David Wyatt

Power Apps- Moving Away From Inline Code

david wyatt — Mon, 12 Jan 2026 07:02:32 +0000

Its the age old question, where do you put your code? Now I suspect you are saying never heard that question before, but it's a choice we actually make.

Everyone knows the client and server choice, as we can run our code in the browser or get the server to do it and send it back through an api. But there is also a more fundamental choice, inline or block.

See you can just add your JavaScript in the element, like this:

<button onclick="alert('Hello World')">Click Me</button>

and I do occasionally see this, but the vast majority of JavaScript has now moved out of inline into consolidate blocks, either in a script tag *(for single page sites) or dedicated JS files:

<script>
  document.getElementById("demo").innerHTML = "Hello World";
</script>

So the question we should be asking is why, and bigger question is should we do the same in Power Apps.

In case you missed it Power Apps now has the app formulas properties, that can be used to run reusable code, they are called:

User Defined Functions (UDF)
Behaviour UDF's

So let's dive in and explain each

When to use Inline
UDF & Behaviour UDF's
When to use UDF/UDS's
Functions in Dataveres & Flows

1. When to use Inline

We all know Inline, with each component having 2 main types of properties:
Data - characteristics of the component, like X/Y co-ordinates or font colour
Event - triggered code based on an interaction with the component, like OnClick or OnChange

There are also Function and Action, though these are for custom components or locked code so Im skipping them here

Both Data and Event can run run Power FX code, like setting colour based on a condition or variable, or Patching a table on a OnClick. Code here has one main advantage, it's easy to understand as it is related directly to the component. I can quickly see that If(vsText="Hello World",RGBA(189, 178, 176, 1),Color.Red) will set the fill depending on a variable.

There is also the added advantage of being able to copy and paste the component between apps, as all of the code is self contained.

But there are also trade offs, in particular:

Reviewing Code

Trying to review the code of a Canvas App for either code reviews or debugging is painful when all of the code is inline. There is no one global view of all code, so you have to search and click throughout the app, only ever seeing a small snippet of the code. That advantage of being related to the component falls away when you are tracing interactions across components.

FYI this was such a pain I created a Web App that extracts all of a apps code and displays in one document, check it out at https://appreview-pro.dev

Reusing the Code

A fundamental to writing good code is to reuse your code, that way we our code base is smaller/easier to read, and we maintain code in one place (one version of the truth). With inline code that is simply not possible, so we have to duplicate code.

A good example of this was a app I built a few years back that queried a SQL database, I had to call a custom connector in:

New Search
Next Page
Previous Page
Jump to Page
Filter
Reset filter
Sort

Each button used the same code but different inputs, but I had to copy and paste the code across all 7 buttons.

So when should we use inline code, well I have 2 rules:

The Code will never be reused
One action

The first one is self explanatory, but what about the second. Well its around the code complexity. If the code is doing one action, like logic or maybe a patch, then it can be inline, but if its patching, reseting, and updating, then it should be moved to Source (formulas parameter and called as a function).

2. UDF & Behaviour UDF's

User Defined Functions are exactly what they say on the tin, they are custom functions that you create to run Power FX code. The difference between a standard UDF and a behaviour (not a fan of that name but Microsoft use it, I prefer User Defined Subroutine from my VBA days), are 3 fold:

Scope
Trigger
Outputs

UDF's are scoped to the function, meaning they can interact with variables and components. They are also declarative, which means that the system decides when it wants to recalculate it. Finally UDF's return a value, where as behaviour does not.

Here's a simple example of a UDF

AddOne(num:Number):Number=(
    num+1
)

and heres a simple UDS, sorry i mean Behaviour UDF

AddToVar(num:Number):Void ={
    Set(viNum,viNum+num)
}

The first returns the passed in value incremented by 1, the second increments a variable by the passed in value.

You create both in the same way:

App-Formulas

But the structure is a little different, with UDF's using () and

functionName( inputName:inputType ) : OutputType (
<Your Code>
)

sorry I'm going to call the UDS now, and UDS using {}

SubroutinenName( inputName:inputType ) : Void {
<Your Code>
}

But call out here, inputs are optional for both and there can be multiple

AddTogether(num:Number,num2:Number):Number=(
    num+num2
);

AddOneToVar():Void ={
    Set(viNum,viNum+1)
};

As you can see although UDF's are super useful, they are not really going to change the way we code our apps, as the use case is relatively small. But UDS are much more useful as we can follow the path the Web Developers pioneered.

3. When to use UDF/UDS

And this is my hot take, we really should be using UDS's a lot more, in fact looking at our 2 conditions when to use inline, means everything else should be moved to the formulas bar and called as a UDS.

If you plan to reuse the code, then it should be a UDS, if the event property is doing multiple Power FX functions, then it should be a UDS. Now like everything in life there are shades of grey, in particular for the last one, would this have to be moved?

UDS() : Void = {
    Patch(dummyData,{ID:1},{Title:"test1"});
    ResetForm(Form1);
};

Its actioning multiple Power FX functions, but its only 2 lines of code. And this is where you decide, but for me to create a clear standard and to improve readability I would move it.

But I have the following key caveats:

Naming must be good, I normally include the component name in it if its not reusable
If it is reusable include which components use it in comments

4. Functions in Dataveres & Flows

Back at the start I also talked about client and server, so thought it would be good to also bring them into my decision matrix.

Functions in Dataverse use Power FX, but they run on the server (I've done a lot more in-depth into these in a full blog here: Instant Dataverse Functions & Low-Code Plug-ins). The main reason to use Functions in Dataverse is for reusability, as the code is behind a simple API url, so can be called from other apps, flows and even pro-code solutions. But even for those use cases you have to consider:

At time of print its still very buggy and Microsoft's seems to have lost focus
Requires Premium license
Max run time is 2 minutes
It is synchronous, so you have to wait for the function to finish

So these would purely be used for those niche cases where the code needs to be run across multiple platforms.

The other server side is calling a flow, this adds the complexity of another tech (not Power FX), but if we are honest every Power App Developer can use Power Automate. And the bigger issue, is its slow.

But it has the benefits of being able to use more connectors, a non-user connection, and can be delegated, leaving the app to continue while the flow runs in the background.

So the big use cases are normally long running jobs that I don't want to block the UI with.

If you do want to know more I've done a blog already about it here Power Apps - Client or Server Side?, and an example of delegating to a flow here How to - Power Apps Getting Polling Update from File Upload.

So the hot take is, move your code to the block, away from inline. Now I know I will get a lot of push back on this (rightfully too), but I would say:

Its shades of grey, I'm not saying everything in block
Change takes time, but when you get use to it
Pro-Code is often the way to follow, as they have done all the learning for us

😎 Subscribe to David Wyatt

The Future of the Power Platform

david wyatt — Mon, 15 Dec 2025 07:12:38 +0000

I've read a lot, and written a little, about how AI Vibe Coding will impact low-code platforms like the Power Platform. It's quite clear where Microsoft wants it to go, as someone said "they want natural language to be the language of the platform". Microsoft are all in on this, because a natural language UI future:

Is a world where they could lose their legacy dominance
They can profit from the infrastructure needed
It moves to the new cash flow model- PAYG
It "in theory" opens up new users

The first one is the big one for them, they missed the mobile revolution and now they are full FOMO (fear Of Missing Out). At least mobile had limited impact on enterprises, but AI could create the first real break that encourages organisations to invest in a big infra move.

Nvidia is a big winner, as in a gold rush don't dig for gold, sell shovels. And the infrastructure to use all those shovels/graphic cards are large data centers, and Microsoft with Azure has that. So they are in a good position to have the economies of scale to be cheaper and profit from competition (worked well for AWS).

When everyone moved to the cloud companies like Adobe figured out very quickly the peaks and troughs of sales through direct purchases could be replaced with steady dependable and often sticky cash flow with subscriptions. It feels that Microsoft has drained that cash cow now, there are no new licenses to sell, additionally they are no easy way to track ROI, making keeping existing licenses harder. Pay As You Go could be the answer, linking a ROI to direct consumption, now organisations are incentivised to spend more, as every dollar spent with Microsoft is 2 dollars saved.

And the final one is that there is a whole new market. Currently Power Platform makers have to have a combination of skills and drive to create solutions. Now with AI abstracting away the skills more people can make solutions. I think this one is the weakest, because I would expect for every new user you will lose (or at least decrease the output) of a current maker.

With this in mind we should always be taking what Microsoft says with a small pinch of salt, they need their AI offerings to be your future, even if they (in my opinion) don't quite live up to the hype.

So we know Microsoft is going all in, so how will that impact the Power Platform, and what will it look like in a years time.

Years Time

This one is controversial, but I suspect in a years time very little will have changed. There will many (many) new AI features, and although these will be talked about a lot, they will not have trickled down to large organisations.

Large orgs are like oil tankers, they take miles to turn. All the new AI features will need to go through legal, governance, and most importantly security. Smaller agile companies will risk it, but large orgs with lots to lose wont.

I would also expect a little swing back, more investment back in core features like PPAC and less forced on AI features (it's amazing how the threat from large paying customers can have on Microsoft).

Don't forget in most cases these AI features are not solving a problem, they are improvements, and although organisations want that productivity boost to help their bottoms lines, they are happy to let someone else be the first adopter and take the risks.

After Next Year

The truth is AI is not going away, it is the future, so the way we work will change.

And this is where I think there are 2 possible paths we could end up down.

Path One - Microsoft's Happy Path

The AI tools start delivering what was promised, the following key things happen:

Vibe coding delivers robust solutions
LLM token costs drop significantly
Users switch from visual to text base UI
Security gets ahead in the arms race

Now Power Apps looks very different, Canvas Apps are still here, but now you start with a prompt, and after a few rounds of prompting the app is available to be updated in the UI. That's right, prompting will get you so far very quickly but th 80/20 rule strikes, and the last 20% is so much easier to do in the UI with a simple click/drag/type (My favourite example of this is car production lines, robots will do most of the work but there will always be a human on the production line to do the fiddly bits).

Flows will leverage the simplicity of prompts to create automations, but then gain the core requirement of deterministic outcomes. If you put a and b in, you always get c out.

Copilot Studio will be just like Power Apps, vibe coded. So you start with prompts and it creates all of the topics and connections. Again the UI will come at the end so you can do the last 20% targeted.

Power Pages is the interesting one, as its in a very difficult situation with Power Apps taking on React. So my guess would be that they unify Power Apps and Power Pages (going full circle back to Power Apps Portal). The developer builds the same and then at point of deployment decides if its external or internal.

Dataverse won't change much, its benefits are not just UI deep so I can see still being the AI database of choice.

Dataverse Low-Code plugins will disappear, and I vibe coded version of standard plugins will be created (Im kind excited by this, as the terrible buggy nature of Low-Code plugins ruined the opportunity).

Although AI has taken over the platform, there are still a plethora of legacy apps and flows, all of which continue to run, generating value, (as if its not broken why fix it).

Path Two - Microsoft's Unhappy Path

As you saw in the happy path, ther 4 key requirements are not easy. So I could quite easily see

Vibe coding still delivers spaghetti and unreadable solutions
The continued investment in larger LLM models means token costs staginate/rise
Users push back and want to stay visual
Prompt injections are not beaten and new vulnerabilities are discovered

In this world organisations simply don't pay for the AI features. They go the other way, forcing them off. The current crop of Low-Code tools deliver all the value they need, and security win the PR war with the senior leaders.

Microsoft is stuck as its invested heavily and needs to double down or pivot. They pivot, splitting all the AI features out into their own area.

Power Apps keeps the visual UI with a little bit of AI on the side. Special AI components and/or a way to use AI to create PCF components. Deep down I suspect this will happen even on the happy path, as vibe coding as a premise isn't right for organisations. They need understanding and stability, nothing of scale has ever been made vibe coding (well maybe fly.peter.com is an exception lol). The real value is AI assisted development, where the developer already has the skills and supervisors the AI, AI a tool not a delegation.

Power Automate doesn't change, the sprinkle of AI stays in certain connectors like now. The truth is Power Automate built on the very established Logic Apps, for me it's kind of at peak evolution (especially when inline UI launched properly, hurry up Microsoft).

Copilot Studio leaves the Power Platform going on to join M365 Copilot and other Agents that are designed to compete with the og Office suite.

Power Pages becomes the vibe coded part of the platform. It takes on the React code instead of Canvas Apps, but the code is visible and editable. It becomes more of the Low-Code to Pro-Code bridge, not used by citizen developers, just accelerating pro devs.

Dataverse starts appearing more and more outside of the Power Platform.

Dataverse Low-Code plugins start to work 😎

The current tools all get a blast of investment, all those features put on hold suddenly start being delivered.

Microsoft is also ironically in a good position, as even though they invested heavily in AI, so did their competition. And they are able to fallback om existing venue streams to steady the ship.

The Take Away

Although AI is the future, the future is not tomorrow, and no one knows exactly what the future looks like. It could be everything, or it could be a niche, it could be the new Smartphone or the new Blockchain.

Either way the Power Platform will still be here, bigger and better, and for me that's super exciting 😎

😎 Subscribe to David Wyatt

Fixing Power Platform Pipelines

david wyatt — Mon, 01 Dec 2025 07:19:22 +0000

Although Microsoft really didn't plan (or probably want you to) most organisations understood the benefits of application lifecycles and instigated a Dev / Test / Prod environment strategy.

With all of the benefits unfortunately came a big negative, and that is the overhead of deploying solutions.

This lead the the launch of Power Platform pipelines, but back to the first sentence, this was implemented quite right. And that's because a big part of lifecycle management includes segregation of duty, ago the developer should not have access to test or prod. The standard pipeline requires that the developer has full maker access to test and prod, which in the real world leads to developers editing in prod.

Microsoft again listened and released delegated deployments, using either a application account (SPN) or a normal but non-human account (Service Account). But again there were issues:

SPN Issues

Requires the developer who creates the pipeline to own the SPN in Azure, not good security practice
Uses the developers connections, so although they don't have access to test/prod environment, they have access to test/prod data

Service Account

Cant deploy connectors (yep you heard me, only solutions with no connections!)

Luckily there is a workaround to the issues, to get Power Platform Pipelines fit for use.

Design
Implementation
Flows

1. Design

The workaround works on 3 key facts:

Delegated Service Accounts can create their own connections
SPNs can have connections shared with them
Solutions have a config json included

So the workaround is a little bit of hot potato, with the connections being passed around.

First we update the config json with the Service Accounts connections
The Pipeline then deploys using the Service Accounts connections
After deployment the SPN swaps the connections (and the components) to the new owner

2. Implementation

Unfortunately then implementation is a little more complex, as we need to have some prior setup and extra admin.

Extra Setup

What's great about the pipeline is it allows you to create the connection in the target environment when you trigger the run. But that can't be done if not using the developers connections, so we have to set them up before.

In every target environment we need to create all possible connections that the Service Account could use.
Additionally we have to setup the solutions new owners connections, and share them with the SPN.

Extra Admin

As we have add extra complexity we need a way to administer this, and the key data we need is:

Solution
New Owning Service Account

as without that data we wont know which account to change to after import.

The easy way is to create a Dataverse table and Model Driven app (I call it the Pipeline Register), and while we are doing all that work we might as well add in some useful data like:

Approval
Documentation Link
Change Number
Developer team (so we can share read only access)

And once all that is done we end up with something like this:

Better resolution version here

3. Flows

Power Platform Pipelines have a very important feature, Gated Extensions.

So we going to leverage these gates to run flows to action our required updates.

OnApprovalStarted

These flow will create the Solution config json file which will update the connection references to use the delegated deployment service account.

First we get the deployment stage run details
Next we parse the json config from the table (@{outputs('Get_a_row_by_ID')?['body/deploymentsettingsjson']})
Then we need to find the connections for the Service Account in the target environment using Get Connections as Admin and filtering
Then from the parse we loop over each connection reference and find the exact connection in the target environment

and(
  contains(item()?['id']
,
  split(items('For_each')?['ConnectorId'],'/apis/')[1])
,
  equals(
    item()?['properties/displayName']
  ,
    parameters('Pipeline-DelegatedAccount (ia_PipelineDelegatedAccount)')
  )
)

Next is to set the property of a holding array variable to the new connection reference

setProperty(
  items('For_each')
,
  'ConnectionId'
, 
  body('Filter_array_connections')[0]?['name']
)

Finally we update the deployment stage run detail item will found at the beginning We get the environment variables from the parse JSON so not to wipe them

As this is also prior to import this is where I would add additional checks and approvals:

Is it in the Pipeline Register
If its to prod is it approved

OnDeploymentCompleted

After the solution is imported we need to change everything over from the delegated service account to the owning account.

The 2 key steps are:

Changing connections - I've done a deep dive how to here: Power Automate - How to Change Connection Owners
Changing component owner - again deep dive already done here: Automating Changing Solution Owner in the Power Platform

You must do it in above order as the new owner must have access to the connection used

And like pre approval there are other actions you can take:

Share any flows with dev team
Back up solution to external repository
Share App url's

As you can see there is definitely added complexity, especially around pre setting up connections. I tried the Power Automate Management action, Create Connection but always get errors. The other option is our trust Power Automate Desktop to do it through the UI, but I really wish there was some sort of credential bank for admins to manage them.

But if your org follows good practice like true separation of duty and application lifecycle management, then you can at least now use the inbuild Pipelines.

😎 Subscribe to David Wyatt

Dev.to Tag Hacking

david wyatt — Mon, 24 Nov 2025 11:44:52 +0000

I was digging around some of my old blogs recently and spotted something interesting, well not interesting, but unexplained.

I blog about the Power Platform, a lot, and one of the things I don't blog about is crypto, so I was surprised to see that a few on my blogs had these tags:

#crypto
#cryptocurrency
#bitcoin
#offers
#web3

Yep it looks like someone hacked my tags, most likely in conjunction with spam comments to push something dodgy.

I wanted a quick way to check all of my blogs and fix any, and luckily there is a API for that.

As Dev.to is built on Forem it has a robust and open api (No known rate limits and auth only for personal permissions like creating a blog). The docs are great as well, https://developers.forem.com/api/, so it's easy to use.

I used the https://dev.to/api/articles?username= endpoint, with an increased page size using ?per_page=1000

https://dev.to/api/articles?username=wyatt&per_page=1000

This returned the following info per blog:

[
    {
        "type_of": "article",
        "id": 2997601,
        "title": "Vibe Coding a Power App the Pro way with Code Apps",
        "description": "In a world of new AI tools and rebranding its hard to keep track of everything Microsoft has...",
        "readable_publish_date": "Nov 17",
        "slug": "vibe-coding-a-power-app-the-pro-way-with-code-apps-56dk",
        "path": "/wyattdave/vibe-coding-a-power-app-the-pro-way-with-code-apps-56dk",
        "url": "https://dev.to/wyattdave/vibe-coding-a-power-app-the-pro-way-with-code-apps-56dk",
        "comments_count": 0,
        "public_reactions_count": 20,
        "collection_id": 19972,
        "published_timestamp": "2025-11-17T06:56:28Z",
        "language": "en",
        "subforem_id": 1,
        "positive_reactions_count": 20,
        "cover_image": "https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fgris6a1itt7aydpnzsl3.png",
        "social_image": "https://media2.dev.to/dynamic/image/width=1000,height=500,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Farticles%2Fgris6a1itt7aydpnzsl3.png",
        "canonical_url": "https://dev.to/wyattdave/vibe-coding-a-power-app-the-pro-way-with-code-apps-56dk",
        "created_at": "2025-11-06T10:59:19Z",
        "edited_at": "2025-11-17T06:58:56Z",
        "crossposted_at": null,
        "published_at": "2025-11-17T06:56:28Z",
        "last_comment_at": "2025-11-17T06:56:28Z",
        "reading_time_minutes": 7,
        "tag_list": [
            "powerapps",
            "powerplatform",
            "vibecoding",
            "lowcode"
        ],
        "tags": "powerapps, powerplatform, vibecoding, lowcode",
        "user": {
            "name": "david wyatt",
            "username": "wyattdave",
            "twitter_username": "wyattDaveDev",
            "github_username": "wyattdave",
            "user_id": 653003,
            "website_url": "https://powerdevbox.com",
            "profile_image": "https://media2.dev.to/dynamic/image/width=640,height=640,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F653003%2Ff6da9df7-019e-4189-ab7f-c5c527fe1db6.png",
            "profile_image_90": "https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F653003%2Ff6da9df7-019e-4189-ab7f-c5c527fe1db6.png"
        }
    }
]

So it was relatively easy to throw together a quick site that listed all of my tags from the tag key in the response, and create quick links to them so I can fix them.

The site shows counts of all tags with quick links to a table with the blogs using that tag.

I also chucked in some extra fluff, like a csv download and a couple of charts provided by my favourite chart library chart.js

So if you want a quick way to check for any hacked tags or just to see what you blog about the most (and maybe spot a typo or 2 🤦‍♂️) you can try the site here: https://powerdevbox.com/subs/devto

You can also throw on a author parameter for quick loading: https://powerdevbox.com/subs/devto?author=wyattdave

I've also raised the issue with dev.to support, but the constant battle against spammers is no easy task.

Vibe Coding a Power App the Pro way with Code Apps

david wyatt — Mon, 17 Nov 2025 06:56:28 +0000

In a world of new AI tools and rebranding its hard to keep track of everything Microsoft has launched, but there is one kind of cool one that never got as much attention as I think it should and with the influx of new it probably wont.

We are all talking about App Builder, and Generative Pages in Model Driven Apps, but there are also Code Apps.

Code Apps only launched a few months ago, pitched as a way for Pro-Developers to build full React Apps in the Power Platform. But in my humble opinion that wasn't what they were created for, they were actually created so that the current crop of vibe coding tools could be used in the Power Platform.

I'm not a React developer so I won't talk about actually building in React, so I will talk about:

What They Are
Basic Setup
Vibe Coding Experience

1. What They Are

Canvas apps take config files generated by the maker studio and compile them into a web app.

So looking at the process Microsoft had 2 options where to insert AI, at the beginning, generating the maker studio inputs, or the second replacing the rendering engine. The latter had the benefit of using any web library, and the most popular being React, which was so prevalent all the existing models were good at creating.

So this meant a new process, something like this:

And that's what Code Apps are, they are apps with a different build process. As you can see the value USP of Canvas Apps is PCF rendering engine that allows Low-Code inputs, and although the environment is a big USP, it's nothing without those inputs. I can't see many React developers wanting to build in the Power Platform just for the environment, but I can imagine Low-Code developers wanting to vibe code a React app with the benefits of the environment.

2. Basic Setup

As always Microsoft learn provides some great documentation on how to setup everything up (https://learn.microsoft.com/en-us/power-apps/developer/code-apps/overview), but the headline prerequisites are:

Code App environment setting turned on
A code editor like VS Code
Power Platform CLI
Node.js - make sure you have an up to date version

Git is recommended but you can always download the zip file from GitHub.

Once everything is setup and you have download/cloned a template app (I recommend the Hello World App as the from Scratch kept having build errors for me), you need to use the CLI to sign into the Power Platform.

Like I said the docs provided by Microsoft a great so I don't want to duplicate for the sake of it, but in a nutshell you:

Sign into an environment
Install/update libraries
Initialise app
Build the app
Deploy the app

You can also build and run a local version of the app, though I often found this more pain then its worth

Install/update libraries

Most of the web is now built on libraries and dependencies, that way you do not need to build functionality from scratch, you can use what others have made. The package.json file lists all of the libraries and is used to install them (the package-lock.json file is also used but this is to stop newer versions being installed so that you don't need to worry about regression testing etc). These libraries are stored in the node_modules file.

Initialise app

This adds the additional information need specifically for Power Apps. It creates the power.config.json file, which includes:

Appid
Display Name
Description
Environment
Icon/logo
Connection References
Data References
Environment Variables

The CLI will create most of these but you can update at anytime, and some are not done in the CLI like icon and description.

Build the app

As you saw in the top diagram, React is not an end product, but a developer tool. So React is used to create standard HTML/JavaScript/CSS that your web browser can use. To turn your React into HTML/JavaScript/CSS we use a build tool, in this case Vite. Running the build will use Vite to convert all of the TypeScript and JSX into simple HTML/JavaScript/CSS.

Deploy the app

The CLI will now deploy the HTML/JavaScript/CSS files that were created in the dist folder. After the app will appear in the environment ready to use. Note that there is version control but remember that the React code is not stored in the Power Platform, so if you do rollback, the code you are editing in VS Code etc will not rollback (I would highly recommend using a repo like GitHub and creating a pull request for every deployment to the Power Platform).

And that's it you now can deploy your code app to the Power Platform.

Connections

We all know Power Apps have no power without connections, and the good news is Code Apps have that power. There are 3 types of connections,

Standard (data)
Dataverse
SQL

Again the documentation is great and gives a simple step by step guide to add the connections. For standard connections you use one of your connections (just need connection type and connection id) to create the connection, but it doesn't actual use your connection but still uses the App users when they log in (same for Dataverse, so security roles will still be needed).

The CLI updates the power.config.json with the connection and creates some TypeScript files (src/models for schemas and src/service for functions).

You can then use the connections in a very similar way to within a normal Canva App

const me = await Office365UsersService.MyProfile_V2('id,displayName,userPrincipalName')

3. Vibe Coding Experience

As I said, I don't think many React developers will use Code Apps, but vibe coders maybe, so how was the vibe coding experience.

Well my idea was to build a Agile Planning Poker App. I am fortunate enough to have paid for GitHub Copilot license that I used, I tried both claude 4.5 Sonnet and ChatGPT 5 and found the latter the best for me. The below is my prompt I used:

Objective:
Transform the existing Power App into a fully functional Agile Planning Poker application with a modern, minimalistic UI. Ensure all data is stored in the Dataverse table cr69a_planningpoker.

Functional Requirements
1. Welcome Screen (On Load):
- Display a welcome message and the user's profile image.
- Provide two options:
- Join an existing session (via input field).
- Create a new session (auto-generate a GUID).
- On session creation, navigate to the Round Screen.
- If new session the user should have the sessionOwner field set to true in the dataverse table
2. Round Screen Behaviour:
- Automatically add the current user to the round.
- Display all active participants to every user in the session.
3. Scoring Mechanism:
- Each participant selects a score by clicking a card.
- Reveal scores when:
- All users have submitted their score, or
- The session creator clicks Complete.
- Show: Each user's score and the most popular score.
4. Round Management:
- Include a Start New Round button that only the session owner can see (use sessionOwner field).
- Retain the same users across rounds.
- Reset users only when a new session is created.
- Indicate when other users have submitted score to all users but do not show score
- Show scores to all users when round finished
- If a new user joins they should join the latest round

 Data & Storage
- Use Dataverse table: wd_planningpoker for all session and round data.

 Design Guidelines
- Apply a modern, minimalistic theme.
- Avoid clutter; favor negative space and clean geometric elements.

 Cleanup Instructions
- Remove all Vite template boilerplate from the codebase.

And this was the result:

Welcome Screen

Round Screen

Well that's not entirely true, it took a few extra prompts (about 20), and they were for these issues like this:

Wanted the UI to be centered horizontal and vertical
The polling didn't work so other users didn't see when round finished
Often duplicated users in round
Change popular score to average
Make UI more modern and professional
Expand Join a session card so input box does not overflow
Make round card and point select card same size

As you can see I never did get the UI centered and I wouldn't call it modern and professional, and most took a couple of attempts.

I also spotted that the polling to check was using a batch api call, but the batch was just one api call, so not sure if Copilot is being super clever and smarter than me, or over engineering.

--batch_23479c3e-a81b-4e2e-88cb-4444444444
Content-Type: application/http
Content-Transfer-Encoding: binary

GET cr69a_planningpokers?$select=wd_round&$filter=wd_session+eq+%27e0e9f042-4444-4444-a440-a5f362c33013%27&$top=500 HTTP/1.1
Accept: application/json
Prefer: odata.maxpagesize=500,odata.include-annotations=*

--batch_23479c3e-a81b-4e2e-88cb-4444444444--

In the end my demo app was super simple and I was able to get it working with a few prompts, although not exactly how I wanted. The beauty of Code Apps is obvious, React, and the breadth of training material available for LLM's. As new models become available I see them getting better and better, and once you figure out I see them becoming so much better then Generative Pages and App Builder, I just hope Microsoft doesn't give up on them because of that complex setup.

I also hope they open it up to more then just React, and I did the vibe code approach because I'm not a React developer, and that's not as enjoyable as doing some of it yourself.

😎 Subscribe to David Wyatt