If you search for “Flow Builder” online, you’ll likely land on a Salesforce website. It has been their business process automation tool since 2019, after all. But this article is not about that. Instead, we’ll take a look at Microsoft’s Flow Builder, the brand-new tool bundled with Microsoft 365 Copilot, and see what it is all about.

Currently in preview as part of the Frontier program, there’s not a launch blog post for it yet. But the end-user documentation page of the tool is available here. It starts like this:

Below you can see what it looks like. I gave it the following prompt: “Every day at 3 PM, find my open tasks in Planner that have a due date within the next 3 business days and send a summary email to me with a list of the tasks, grouped by plan name.” Then, Flow Builder proceeded in building me this:

Could this be the future of how Power Automate cloud flows will be built with the help of AI? Not exactly, but it’s definitely worth paying attention to. There’s more to it than meets the eye. As always, whenever Microsoft launches a new product/tool, it’s built on a bunch of tech stack that came before it. Understanding what’s old & what’s new is essential groundwork when providing advisory services to MS customers and partners. So, I took a deeper look.

In this newsletter issue I’ll share the key findings of my Flow Builder test drive, acknowledging that it’s still preview stuff and things may/will change. There is certainly a lot of potential in reimagining the Power Automate UX to be useful for normal folks instead of hardcore low-code makers. The marketing potential for Microsoft to promote this as “an AI agent that automates your work” is even bigger.

I have no doubt people in the community and at MS will create many engaging demos of the happy path. So, I didn't attempt to compete with that. Instead, I focused on doing what I’m particularly good at: finding out the things that don’t work. For the Frontier edition of Flow Builder, the category of errors and issues I found were the following:

Because of its LLM nature, Flow Builder will not build the same flow the same way every time. It will make mistakes, just like Copilot does - even when working within a highly restricted domain like this tool with support for less than 10 connectors.

Microsoft Flow was launched a decade ago as the automation tool to empower every user. Since IT was blissfully unaware of low-code or citizen development at the time, these gradually built up quite a lot of admin headache to clean up things and put up guardrails for Power Automate flows.

Surely Microsoft has learned the lesson and did a better job with Flow Builder? Unfortunately, that doesn’t seem to be the case. At least not in this preview stage.

The conversational UI of chatting with agents is flexible, but not accurate. Flows, on the other hand, should execute precise business logic and follow the platform rules. I came across a situation where the Flow Builder did not know how to build flows, resulting in strange error messages you cannot troubleshoot via the Flow Builder UI. In fact, Microsoft intentionally makes it hard to use the full powers of Power Platform with this new agent.

What licenses do you need for running Copilot based automations? The answer to this can change on a weekly basis. It is therefore not a big surprise that the licensing enforcement mechanisms in MS cloud was not ready for running Flow Builder as intended yet.

So there.😁

It’s not all bad, don’t get me wrong. Using GenAI in the maker facing tools as a helpful assistant is something I have much more faith in, as opposed to the dream of autonomous agents magically doing our work for us. We need this layer to work first. If it doesn’t, why would we let LLMs run around, talking to our customers and handling business transactions?

Non-graphical business logic rules should be easier for LLMs to generate than visual apps. Flows should be where AI excels in. So far, the built-in Copilot in Power Automate has often left people screaming in anger. Compared to how much better ChatGPT is at helping makers (like me) build flows, it seems obvious that Microsoft has stopped investing in this particular Copilot and is getting ready to reimagine the product currently known as Power Automate.

Flow Builder isn’t yet the complete replacement — not even close. Nevertheless, I believe it demonstrates what Microsoft envisions as the direction where automation is heading on their stack. So, let’s dive in and explore this brave new world.

First, I had to enable the Copilot Frontier program in my tenant. That particular screen in the M365 Admin Center had been giving me errors for months. Once I grew tired of waiting around for MS to fix things on their end, I started poking at different options in the UI and checking error messages on the browser side.

I finally figured that the error appears if you try to enable the whole tenant for Frontier. Select a specific security group for the non-required field, and everything works as it should. Doh!

Next, the Flow Builder agent needed to be deployed in the Copilot Control “System”. After some more waiting around, I got to the actual UI of where the agent flows were supposed to be created. Only it was time for another persistent error to stop me. Because no matter which one of the three template prompts I selected (or even my own), Flow Builder was unable to save a flow.

The problem seemed to manifest itself already before getting to the clicking of the Save button. Flow Builder failed to create the connections needed for the actions it used. When looking at a way to manually fix this, the information shown to the user was not exactly building up confidence. Because I saw tens of unnamed connection references for all the connectors offered by Flow Builder.

This made me think: “is this thing pulling all the connection references across all environments in the tenant?” Because that would be an unfortunate gap in the low-code platform that acts as “Credential Sharing as a Service”.

After a couple of weeks, when these same errors were still blocking me, I decided to validate whether this was specific to just my user account. Since the Flow Builder can only be unlocked via the $30/u/mo M365 Copilot license (that hasn’t exactly been popular among customers), I had to reassign my one precious premium Copilot license to my alter ego, Tapio.

Surprisingly, everything worked with the other user account. Testing the sample template prompts, the Flow Builder that failed to connect to anything with the identity of Jukka managed to complete almost all tasks for Tapio. That “almost” was the critical thing here that taught me a lot about how this Builder fundamentally operates. You see, even when it gives an error, it doesn’t mean that anything is wrong with the system configuration, your rights and connections, or the task given to Flow Builder.

“It’s the AI, stupid!” Thanks to its LLM-based operation logic, the building process is non-deterministic. Sometimes it works, other times it doesn’t. This happens even with an extremely simple prompt like the one MS suggests for trying out Flow Builder:

Running that “code” should result in similar flows for different users, but not quite. We’ll later see one bigger issue that AI managed to create from it. But the easiest things to spot are how the flow names and other wording aren’t identical across different flows built from the same prompt. Because the model temperature can’t exactly be set to zero without losing everything that makes it seem smart.

With Tapio’s user account, 3 out of 4 connection creation activities worked. And then, I made the key discovery: I should NOT try to manually open the connection reference from the GUI. Instead, I should prompt the agent to fix it. “Hey, the Teams connection isn’t working, can you fix that?” And then, if you’re lucky, the agent manages to save it properly.

In the below picture, the text output from the agent seen before the connections list is actually incorrect. Because after spitting those words out it went and turned the red cross of the Teams connector into a green tick mark.

This can also happen in the flow saving process. Even when all the connections were green, the next task for the AI could fail. I the earlier screenshot from Tapio’s user account, you’ll see that the Office 365 Outlook action creation was red. And the saving failed for the first time.

What do we do when AI fails to complete a task? We ask it to try again! This time, that means only clicking the Save button for the second time. And like magic, the errors disappeared.

When I finally managed to save an Agent Builder flow, I was able to go and check the most curious part about it that had caught my attention in the M365 Message Center message. Specifically the statement: “Flows are saved in each user’s Power Platform environment.”

If you know something about how Power Platform environments work, you should be confused at this point. Because there is no concept of “my Power Platform environment” in the product. That’s not how any of this works. If the people who wrote this documentation had experience from the BizApps side, I bet they wouldn’t have phrased it like that.

Sure, in theory it could be possible that new environments would be provisioned for each user. But that kind of resource wasting for Azure resources did not sound plausible. What I did think for a moment was that these Flow Builder flows might get saved to the Microsoft 365 Power Platform environment. You know, the one that appeared in every tenant in Spring 2025, with M365 Message Center calling it “a dedicated environment for Agent Builder agents”. Which then got rebranded to Copilot Studio “lite” experience. And which isn’t actually using that environment for anything. But Copilot scheduled prompts live there today instead.😵‍💫

Well, forget about all that complexity! Microsoft has once again taken the shortest possible route in building the product and chosen a path that every Power Platform admin would oppose if they knew about it. Yes, of course these Flow Builder flows get stored in the tenant’s Default environment!

Just for kicks, let’s revisit what the community reaction was back in April, when MS said they would be creating the dedicated Power Platform environment for M365 based agents. One comment said: “Really, REALLY!! glad to see this come into reality. A few of us had to share our concerns of how we lived through cleaning up SharePoint apps and flows falling in the Default environment and now don't want to relive that for agents.”

Well, some people at Microsoft did listen to the concerns obviously and tried to do prevent history from repeating. And then, in the name of meeting Copilot KPIs, someone somewhere decided there’s no time to do things the right way. What we have instead is a bunch of hacks to get the agentic tools out the door. Built on existing tech stack, yet masked to look like they are something more.

For example, the Flow Builder flows aren’t visible in the regular list of “my flows” in Power Automate maker portal. However, as you saw earlier, they are of course included in the Default Solution technically, because that’s how the platform has worked since the XRM days. What has been put in place is an awkward blocker that doesn’t’ allow you to access the flow details page. “This agent flow can only be opened in the Flow Builder agent in Microsoft 365 Copilot” is what the user will see:

But wait a minute: Flow Builder doesn’t have all the necessary UI features to manage the flows! So, not all parts of the maker UI have been blocked. When things go wrong (and they eventually always do with flows), the flow run history needs to be accessible. And you can get to it from, for example, the “see flow run” menu of the Automation Center in the Power Automate maker portal. Or from the email notifications about failed flow runs. Just don’t dare to click on the “see flow details” or “edit” buttons outside the M365 Copilot agentic UX.

There is an Activity tab in the Flow Builder UI that sort of provides visibility into the state of the flow. However, it will only tell you if a flow run succeeded or failed. You can’t get to any of the useful details about why it failed. Maybe the chatbot could read the logs, but I won’t succumb to that if I can access a proper GUI.

Let’s get back to the struggles that my regular Jukka user account had in saving the same Flow Builder flow that worked for my alter ego. Since we learned that the solution view to these flows is accessible, we can perform any action that doesn’t require us to get to the flow details or editor UI.

This means we could try and turn on the flows that failed to get saved yet were created as drafts. At this point I want to mention that clicking on the Flow Builder save button on the same screen resulted in multiple flow instances being created for the same prompt…😅

This is what I saw:

“Turn on failed. Flow client error returned with status code "BadRequest" and details "{"error":{"code":"InvalidOpenApiFlow","message":"Flow save failed with code 'InvalidWorkflowTriggerRecurrence' and message 'The recurrence of trigger 'trigger' has an invalid time zone 'UTC+02:00'.'."}}".”

Okay, interesting! Instead of just some other MS service endpoint not responding, we have a specific error message outlining an invalid parameter.

Since Microsoft has decided to make things unnecessarily hard for debugging purposes with their UI blockers/gaps, let’s grab the Swiss knife for pro & low-coders alike: Visual Studio Code and PAC CLI. By creating a temporary solution and cloning it on our local drive, we can open the flow JSON definition for closer inspection.

On the left, we have the flow giving errors for my user account. On the right, it’s the flow from the exact same prompt, generated for Tapio. There’s a key difference here, which is the fact that when Tapio was using the Flow Builder, its LLM made an error in interpreting what “at 9 AM” means for humans in the real world. Not UTC but the user’s time zone, which happens to be UTC+2 in Finland right now.

Both user accounts have it in their M365 and Default environment systemuser records, yet Flow Builder forgot about this in some of the runs (which were performed within a few minutes, I must add). I went on to create a cloud flow via the classic GUI to check how this should be done. The trigger JSON that correctly would represent the selections I as a user made is shown below. “FLE Standard Time” is the value that will get the flow triggered at 9 AM in this user context.

Let’s recap. On one occasion, the Flow Builder got it technically wrong but logically close. On the other one, the output as technically correct and functionally not what the user asked for. I would say that’s a double fail ❌❌ for Flow Builder, even if the activation operation went through for the latter one. Remember: just because a flow runs, doesn’t mean that it meets the business requirements.

It’s important to understand that there are LLM tools used in both the building and the execution stages of Flow Builder flows. In the above example, the builder made the mistakes. However, there is also the possibility that individual flow runs will deliver different results. I didn’t get that far in my tests (I’ll tell you why in a moment), so let’s instead discuss the features that human flow builders using Flow Builder agent should pay attention to.