Back when I entered the workforce at the turn of the millennium, Nokia was to the tech world roughly what OpenAI is today. Magical technology suddenly available to regular consumers, disrupting established patterns both in business and personal life by tearing down a long-held barrier (location and time in communication). Their award-winning marketing tagline was: Nokia - connecting people. Simple, beautiful, Finnish.🤩

The Power Platform and other similar low-code tools were disruptive largely because they allowed anyone to connect apps and data sources together in the cloud. Not via the landline-style integration projects, rather just by clicking a digital button on the computer screen. No need to understand at all what happens behind the scenes (especially not the security dilemma). It just works!

Until it doesn’t one day. When you start receiving email alerts like this one:

No big deal. Just another couple of buttons to click and everything once again works. Right?

If you don’t pay attention to the process (or the message) and just keep clicking on the presented buttons, you can think everything is working “by design”. Most users probably try to just keep their automations running. Me, I’m the kind of troublemaker that starts to look deeper into what is happening — and then posts about it. This is of course what was the trigger for this week’s newsletter issue. One of the many available trigger actions.😁

Let’s look at the email body text first:

Those are hardly ever the real reasons, based on my experience. They certainly aren’t in my Niiranen Advisory M365 tenant. In general, configuration changes on the tenant level or password changes (which have NOT been recommended as a security policy by MS for years now) are rarely the cause for this behavior. If we click on the run history link in the email, we’ll see a much more honest take from the raw action outputs:

It’s an expired OAuth refresh token, of course. Sure, it could be because of the reasons mentioned in Microsoft’s email. But it’s unlikely. Here’s a quick table I prompted to illustrate the token expiry causes and frequency:

In short, what happens is that Power Automate connections hold a stored refresh token, as there is no interactivity like with Power Apps for the login. By default, that token has a 90-day inactivity clock. If the flow runs in this time frame, it will attempt to renew the token. If not, it’s effectively dead. With custom policies for the Entra ID tenant, that time could be shorter, of course.

This applies to OAuth-based connectors, meaning the usual connections people would set up via the convenient buttons and auth dialogs. Service principals, API keys, basic auth — those would not encounter the same expiration limit. But for the commonly used OAuth connections, if a cloud flow does not run once within the 90-day period, expiration is fairly certain.

Note that having MFA on for the account should not in any way interfere with whether the OAuth connections work or not, that’s a common misconception. Another point that actually makes the email alert more misleading is that a password change with an account that has MFA enabled should not reset the token. This, combined with the Jan 2021 change where RefreshTokenMaxAge support was dropped, means that connections most often should not expire without some tenant-level admin intervention on Entra ID side.

That’s the theory. Yet even in vanilla M365 tenants, connections still frequently break.

Last year we saw Flow Builder Workflows (Frontier) agent in Microsoft 365 Copilot introduce a modern AI-first experience for building automations. Not trhough a GUI, but through chat. As usual, I took a critical look at what the possibilities and limitations with this approach were at the time.

I haven’t seen any announcements related to Workflows (Frontier) since then. When 2026 Release Wave 1 arrives, we may see either 1) Workflows get promoted while Power Automate cloud flows are left to rot as a standalone feature, or 2) nothing major for Workflows, which would indicate the Frontier version may never graduate into a production-ready product. It’s a coin flip and I’m not sure I want to place any bets.

But back to connections. The flow in question happened to be built via Workflows (Frontier) agent, even though the email alert is just standard cloud flow content. The “Fix My Flow” button takes me to the connections page in Power Automate maker portal. In there, AI actions (the connector in question) is listed. However, unlike all the normal connections, there’s no “reconnect” link to reauthenticate. Nor is there any details page behind the three dots, just an option to delete the connection.

As I wrote in the earlier issue in October, there’s a lot of UI-level blocking and hiding going on with Workflows (Frontier) agent. It is built on the shared Power Automate cloud flows foundation, of course, yet the product’s creators tried hard to stop the user/maker from looking beyond the prompts. We can see one flow run in the maker portal, but for more details we have to open the M365 Copilot app and the corresponding agent.

Okay, this is… not any better. We have no view of the connections used by a workflow. We can view the run history, yet there are zero actions we can take on anything here via the GUI. I guess our only option is to do what gave us this workflow in the first place and engage in a chat with the agent.

It responds politely to my question at first, although it is completely oblivious to the context. It naturally starts with generic knowledge about Power Automate and its features. When it repeatedly asks, ‘please give me the flow name,’ I try to tell the agent that we are on that very page right here — plus the UI is designed in a way that hides the flow title when working on its logic.

“I’m sorry, Dave. I’m afraid I can’t do anything about the connections I set up with you.” The LLM answer is the kind of hallucination that is totally expected yet grinds my gears:

My response to Workflows (Frontier) agent can be seen below:

So, we’re stuck. Something in the platform has caused the connection to expire. Because the “design” did not take this scenario into consideration, the whole automation probably needs to be thrown away at this stage. Which would not have happened if we had just used Power Automate cloud flows in the first place (unless you used the modern editors, which have occasionally irreversibly corrupted my flows in the cloud).

If an unrepairable connection is bad, what could be worse? How about thousands of broken connections generated by the Workflows (Frontier) agent? Oh, yes. That would be worse. And it is, as we’ll see next.