I read a post on Microsoft’s Power Platform blog that Process Maps in Power Apps plans are now generally available. Since I’ve explored the business process management side of low-code in my earlier newsletter issues, this was a topic I thought to be worth investigating again. What has been shipped and how could app makers take advantage of it in practice?

Unfortunately, Microsoft employees have stopped writing their own blog posts. As a result, what used to be detailed texts from product managers are now mostly just generic AI slop that has very little information value. The Process Maps GA post is one example of generic Copilot-generated content that has high-level “why it matters” fluff instead of concrete use cases with details about the technical functionality to be expected from the product. Even though the post appears under the IT Professionals audience category.

An earlier blog post from a couple of weeks ago was just as misleading: Unlock More Value from Your Existing Solutions with Plans. Its core message was that “you can now create a plan directly from your existing solution.” Great — except that feature went GA already half a year ago. Trying to read the What’s New section of the post did not reveal anything about specific additions having been made. Because most likely there are none. It’s all just a Copilot hallucinated blog post on a topic that MS forgot to promote many months ago.

“I remember when the Dynamics product team blog had detailed technical content on the new XRM platform features…” “Sure grandpa, let’s get you back to bed.”

Anyway, it all just means we need to do our own investigation and read the MS Learn pages in more detail to determine how the features MS launches work and whether they are useful to us. I’ve been practicing this quite a bit in the past few years and I enjoy the challenge. So, let’s get to it!

Before we get to it, though, I want to say that the concept of Plan Designer has value. There definitely is a need for a layer above the technical Power Platform solutions and their components. Whether it works today well enough or not, that’s secondary in the grand scheme of things. (Oh, and also the fact that the plans are a child item of solutions and not the other way around shouldn’t get us too distracted right now.)

I wanted to pick an example process that was not too simplified (like something that the App Builder agent in M365 Copilot targets) but also realistic for a Power Platform solution to cover. I decided to revisit a demo I had talked about in an earlier issue about External access to Power Platform data: loan application request from a customer to a bank.

The fun part about this is that we have a clear benchmark. You can browse an interactive demo of how the example process has been implemented with Dataverse, model-driven Power Apps and AgileXRM. Or check out a YouTube video of the demo flow. In short, an external party (customer) is applying for a loan and that results in both automated and manual verification steps on the bank’s side. This end-to-end process is both visualized and managed via an MS Visio flowchart that’s visible inside Power Apps in this example:

How do we turn this into a business requirements description that AI tools can chew on? Well, we of course use AI for that! I took the YouTube demo link and gave it to Google’s NotebookLM to extract the transcript text. It then generated a set of nice artifacts from it, such as the infographic version that’s quite neat in turning boring text into more engaging visuals:

With the image, a mind map and markdown output of the business requirements from NotebookLM, I asked ChatGPT to do some final processing of it. I was ready to turn this into a native Power Platform version with the Plan Designer. Let’s see how that went.

When LLMs are dealing with text alone, they can be more convincing than any human expert. So, I’m not going to pay too much attention to how the Requirements Agent in Plan Designer performed. Its first draft looked nice and ChatGPT only suggested a few additions to it, which were easy to enter as bullets in the business requirements.

The next phase is the Process Agent that creates those now-GA Process Maps. Again, the high-level textual grouping of activities into processes looks as neat as you’d expect from a GPT model these days. Each process then has a map behind it — which is the part that I found somewhat problematic.

On the surface, the activities on the map are what you’d in general expect to see with this business context. But do they make sense? Are they useful? How should I use them?

Despite the GA status, there is no apparent way to export the process. No, these are not Microsoft Visio flowcharts. After all, why would Microsoft use such a thing from their own product portfolio? It totally makes sense to leave it to partners like AgileXRM to build their Visio plugin and integration instead…

As of today, to validate the business process model that the Process Agent generates, you have to be a maker within this Power Platform environment. You can perform some edits to the flowchart with the very basic tools offered by the GUI. Or, you can prompt Copilot on the top-level description of the process and ask it to change things. Then, magic happens, and something changes in the process flowchart. Maybe.

I have a hard time figuring out how these process maps serve the users in their current form. It seems that they primarily exist to serve the AI instead. These are instructions that are meant to be passed along to the next agent — not for humans to design in detail, let alone review together in a traditional workshop environment.

Now, it would of course be amazing if the process flow itself were an accurate reflection of how the system’s processes will operate in the production environment. Imagine if the processes turned into Power Automate cloud flows with actions mapped to data sources directly? Unfortunately, that remains a distant dream today, as we’ll later find out.

The Data Agent takes the stage next and turns the process into a set of database tables. The resulting data model is fairly simple, putting the loan application in the middle and everything around it. Still, it’s probably a good enough starting point for a PoC in most cases. The creation of a few demo rows in each table speeds up this phase quite nicely and takes advantage of the generative abilities of LLMs in the perfect way (“produce data that looks real”).

Would I personally trust Data Agent to create the tables for me? I probably wouldn’t for anything that has a chance of ending up in production use. Yet this is one of those areas where my knowledge of all the gotchas with Dataverse does more harm than good. For app makers that aren’t so obsessed with patterns and practices we learned back in the XRM, this experience makes everything immensely more approachable. We should never forget that we’ve all been those newbies at one point who struggled to figure out which menus and windows to click on.

We just need to keep in mind that AI generates the V1 here. Whether it’s able to support the app makers through V1.1 to V9 is another question. At some point, understanding what happens on the Dataverse side will be extremely beneficial. In fact, I would consider it even more important that the AI features in Power Platform would support the “add-to-existing” scenarios rather than these “net-new” happy paths.

With our data model in place, it’s time to create a UI on top of it. Model-driven apps are the logical place to start, given they are (surprise!!!) based largely on the data model. The Solution Agent described a Loan Processing Workspace app to be the central hub for internal users across all the relevant processes. Smart move, I would have done the same.

As for the app UI, it’s got nice SVG icons in place for the Dataverse tables involved. The views have relevant columns. The forms are very basic, 1-column versions, that serve as a decent starting point for building something useful. Charts can be automagically generated with Copilot these days, and when you adjust the columns and chart style to be sensible, then save them as a personal chart — we’re on par with the CRM 2011 era visualization capabilities.

A curious omission that AI made here is that it forgot about the customer. Yeah, the Applicant lookups aren’t populated in the sample data. And then once you start paying attention to the menu, you notice that the Customer Applicant table has not been included in the app. Now, some might say this accurately reflects how banks in general tend to design their business processes with little regard to the actual customer, so perhaps we can blame the LLM training data from the real world for this.😁

In terms of canvas apps, the Solution Agent suggested that a Loan Workflow Configurator app would be created. “Empowers process admins to quickly adjust rule thresholds and routing logic, and to publish agile workflow/process changes with no code required.” Okay, interesting. Let’s see what it is supposed to be:

Hmm, what’s the problem here? Oh, I see! It seems that the Solution Agent hallucinated a table called “Process Rule”. The only problem is that the Data Agent didn’t create one. If only these agents could have communicated better internally to avoid such a silly mistake. Yet since we are following a waterfall approach here where the agents run one after another, there’s no chance for Plan Designer to go back upstream and make a table exist when it’s noticed only later on in the process.

It’s all about the processes when it comes to most business apps. Having database tables and a CRUD UI to work with it is nice, but not that different from just running things on Excel tables. Automating, visualizing and enforcing business processes is where I believe the true transformative power of dedicated systems comes from.

Unfortunately, this is where the current AI tooling from Microsoft falls flat on its face. The gap between what words the agents are able to produce and how it translates into a working process is enormous. Let’s look at an example so you’ll see why.

This was the prompt that Plan Designer tried to push to Power Automate’s “create a cloud flow from a description” feature:

Here’s what Power Automate suggested to create from it:

“When an item is created in SharePoint?!?” Well, that’s a complete failure to follow pretty much everything in the description. So, instead of “Next” I clicked “This isn’t what I’m looking for”. At which point I’m told: “Creating a cloud flow from a description is a preview feature that supports the most common actions in several Microsoft 365 apps. Support for more actions and connectors is coming soon.” Hmm, that’s not at all what the feature documentation says, but fine.

The real problem is that whatever Plan Designer imagines Power Automate to be capable of doing, it isn’t. That kind of prompt would require so much more agentic AI capabilities than what cloud flows offer. Which they of course could theoretically have, given it’s the end of 2025. But since Microsoft seems to have given up on Power Automate and is instead looking at making every automation an agent flow, we don’t have anything useful to assist the flow maker here.

The other flow envisioned by Solution Agent, “Offer Generation and Contract Flow”, was an even more ambitious automation. “Automates the creation of formal loan offers and contracts, including document generation and workflow for signature and completion tracking.” I don’t even have to show the end result to you now, you can already imagine it.

I really wish things were different. Because these cloud flow artifacts are, in my opinion, by far the most tedious part to build on top of Power Platform today. If we could just prompt ChatGPT to build the logic and manage it as code, it would be sort of bearable. But instead, we have to fight the cloud flow editor UI and its expressions like it’s 2015.

For a process that involves interaction between the external customer contact and the internal employees, the solution Microsoft would naturally propose here is a Power Pages site. While MS partners can also offer alternative approaches, such as AgileDialogs offered to both external and internal users, or WordPress integration with Dataverse, the choice that Plan Designer must make is clear: if external access then Power Pages.

Right from the Customer Application Submission & Pre-Check, we get the option to “Create with Site Agent”. According to Plan Designer, “the Site agent will create this website for you. It handles the initial setup, including layout, domain configuration, and suggests a set of pages tailored to your goals.”

Sounds sweet. Yet it doesn’t work. In fact, I’m not sure if the feature even exists. Clicking on the plus icon throws me to the Power Pages maker portal home page. I tried to copy and paste some of the site specs from Plan Designer into the “Start building your website with Copilot” dialog box, yet I got an error message every time: “There was a problem connecting to the server. Please try again.”

Is the Power Pages Site Agent even a thing? I couldn’t find MS documentation referring to it, other than this FAQ for site agent. “The agent feature in Power Pages provides you with an easy way to configure a GPT-powered Microsoft Copilot Studio agent for your website. The agent enhances the interaction experience for the website users by enabling them to ask natural language (NL) questions and…” Okay, stop it there, FAQ! You are not talking about an agent to create sites, rather an agent published on a site that already exists.

Finally, the “AI designed by AI” stage! Solution Agent described four agents to be added:

Clicking on the create button will provision new agents in Copilot Studio that have instructions, suggested prompts, and in most cases a reference to one related Dataverse table as knowledge.

This part seems to work pretty smoothly. Given how tedious it is to try and imagine instructions for AI agents, I usually ask ChatGPT to populate them. Here, I was able to skip that extra step and get Plan Designer to provide the details in right fields for Copilot Studio. Like with the Dataverse table creation, this is a feature I’d gladly use the Plan Designer route for.

Okay, how would we use these agents then? That part is not at all obvious to me. In the model-driven app, I can easily add them to the Agent feed. Yet that panel only allows viewing ongoing or past agent actions. I can use it to supervise agents, yet I cannot go and give any tasks to them. Or even say “hi”.

I can also add an app assistant agent. This is a net-new agent that doesn’t get any of the preconfigured instructions or other goodies from the Plan Designer. I went and added the four planned agents as child agents for my “Copilot in Power Apps - Loan Processing...” agent (that’s the slick name given to it by the system). Yet when I open the Copilot sidecar, I don’t seem to have the ability to trigger or mention any other agents.

Honestly, whatever those agents defined by Plan Designer had in their instructions feels like not worth digging into this much further. When there isn’t a plain and obvious way for how a bank employee using the Loan Processing Workspace app would discover them and interact with them, the chances of them delivering real business value are slim to none.

The Plan Designer plan is something that you can export as a PDF, so here’s the contents for you to check out. It’s simply four pages that are exactly the same content as you’d see in the Plan Designer UI. No, you can’t get it in any other format, and no, it’s obviously not meant to be edited anywhere outside this experience. The visual details of Process Maps are notably missing from the output.

The scorecard for the technology section is as follows:

Here’s how it went:

The one immediately useful output was the Loan Processing Workspace model-driven app. It’s completely based on the data model step, meaning the Dataverse tables created, and as such is a good starting point for app development if everything needed was properly defined there.

Everything else is… Well, pretty useless. Power Pages site creation didn’t work, possibly due to a technical error on the platform side. Power Automate cloud flows cannot even in theory currently fulfill what the Plan Designer hoped they would, based on its design. The canvas app is a mystery, given its purpose was based on a hallucinated table, but I’m not sure we missed much by not having it.

The Copilot agents do exist. But why? Their planned capabilities have no autonomy whatsoever. If meant to be used as assistants that could provide helpful information alongside the app data, we should be able to easily see them right next to those records. Triggering them from a Copilot chat somewhere else hardly sounds like the “UI for AI” that people would want to use.

The idea of having actual business planning artifacts alongside the technical Power Platform solution components is in theory quite powerful. Similarly, having LLM-based AI agents that understand both the business context as well as the platform capabilities and data model could definitely make my life easier. As opposed to me having to use non-Microsoft chatbot of my choice to plan more complex things in Power Platform, then copy-paste JSON and other solution config data back and forth.

I would surely want to have an IDE for these low-code solution development scenarios. What the Plan Designer offers today has not been built to offer that. It feels more like a glorified wizard that guides the user through stages of a simulation to build a business solution. The steps, the actions and the artifacts are all real in the sense that you’d encounter them in a project to build an actual Loan Application Processing solution.

The problem is that you can’t run an end-to-end project with this tooling that Microsoft currently offers in the Plan Designer. Which leads to the question: if you’re not gonna follow the plan and play along with how the AI agents imagine the world to work (while it doesn’t), why would you spend time using it? Why try to fit your business process descriptions into a format that the Plan Designer expects when it’s not gonna meet your needs anyway?

For simple apps that only require a few Dataverse tables and a model-driven app for internal users, this tooling can be useful. If you’re the lone citizen developer that is trying to build a solution without having support or funding from the organization, this is certainly much better than not having any structured plans in place. You should definitely try it — just don’t rely on it being always there for you to support your business process development needs.

Why? Let’s just say that Microsoft’s track record in the process management and especially visualization domain isn’t stellar. Visio has in practice been abandoned. Whiteboard never matured to become a true Miro competitor and features seem to be phased out from other products currently. As for the process map concept, it’s amazing how even inside Power Platform there are three different things called that:

If you want to map and manage your business processes, you’re gonna have to do that somewhere outside the Power Platform anyway. Using the generic LLM tools today, you can already ask them to turn your written process descriptions into visualizations like Mermaid charts, or go crazy with Python and vibe code your own plan designer. For this type of “soft” data processing that doesn’t require deterministic outcomes, GenAI is actually an incredibly useful tool already today.