Server Logic can now reach Power Automate
Microsoft has added support for calling Power Automate cloud flows from Server Logic in Power Pages. The post went up on September 18, 2026, bylined Nagesh Bhat, and it states the change plainly. "We are introducing support for invoking Power Automate cloud flows from Server Logic in Power Pages."
The reach is the reason to pay attention. Microsoft says Power Automate provides connectivity to more than 1,400 external services and data sources, across Microsoft services, third-party applications and custom systems. The stated benefit is reuse of existing flows, connectivity patterns and governance instead of building a separate set of Power Pages integrations.
The post points readers to the Power Pages documentation for configuration and asks for feedback through the Power Pages ideas community. It does not say whether the capability is in preview or generally available, so confirm the release status in the documentation before anyone plans around it.
The reuse argument holds up
Anyone who has built a customer portal alongside an internal model-driven app knows how the duplication goes. The same call to the order system gets written twice, once in a flow for employees and once for the portal, on a different connection and with a slightly different payload. Six months later the internal version handles a new status code and the portal version does not.
Duplicated logic drifts, and the drift shows up as a support ticket nobody can reproduce internally. One implementation of a call to the system of record is easier to reason about than two, whether the caller sits inside the tenant or out on the public internet. We have made the same point about the difference between a connector and an integration and about where business logic should live.
So the case is real, and none of what follows is an argument against using it. The change moves the threat model of every flow you expose, and most flows sitting in a tenant today were written for an audience that had already signed in.
Which identity the flow runs under is the first question
A flow invoked from Server Logic runs under some identity, on some set of connections. The post does not spell that out. Get the answer before the first build, because it decides most of what comes after.
In Power Automate, connection references carry the credential. If a flow's SQL or SharePoint connection belongs to a maker, then an anonymous visitor filling in a form on a public page is borrowing that maker's access every time the flow runs. The visitor never sees the credential, and the downstream system sees the maker rather than the visitor.
Portals have always had a gap between the visitor's identity and the identity that touches Dataverse, so that part is familiar. What changed is the reach. A flow can call anything in that catalogue of 1,400 services, so a badly scoped connection now extends past Dataverse and into whatever system of record the flow talks to.
Our view is that any flow reachable from a public page should run on connections owned by a dedicated service principal with its own permission set, never a maker account that also holds interactive access. The rules we set out for service account identity across platforms apply here.
What an attacker does with a form that starts a flow
Take an ordinary case. A page collects a support request from an unauthenticated visitor, Server Logic calls a flow, the flow creates a record in the ticketing system and sends a confirmation email. Anyone who can reach that page can run that flow, as often as a script can post to it.
The questions to settle are about rate. What caps invocations between a public page and the flow. What happens when Power Automate throttling starts rejecting calls, and whether the page then fails usefully or simply hangs. Whether ten thousand submissions in a minute costs you anything. The post addresses none of it, and a page with a form on it carries a different exposure from a page with text on it.
Then there is what the flow does with the input. A flow that drops a string from a form into an HTTP action, a SQL statement or an email body is accepting attacker-controlled data into a step that runs on a privileged connection. Validate in Server Logic before the flow is called, because the flow may have other callers that skip it.
Inherited governance is only as good as your DLP posture
Microsoft's point about inheriting governance from Power Automate is accurate and easy to read too generously. Data loss prevention policies in Power Platform sit at the environment level and sort connectors into business, non-business and blocked groups. A flow called from Power Pages is governed by whatever policy covers the environment that flow lives in, and by nothing else.
So the honest first task is not building anything. Open the DLP policy for the environment hosting your portal flows and read the connector classification on the assumption that an anonymous visitor could trigger any flow in it. That assumption is closer to true this week than last. A policy written with employees in mind will not survive the reading.
Environment separation matters more here than usual. If portal flows live beside finance automation, the visitor-facing path and the payment-run path share one policy boundary. Our guide to governance that keeps low-code moving covers that argument, and flow ownership debt covers what happens when nobody can say who owns the flow you just exposed.
The check to run before a page goes live
List every flow that Server Logic can call from your portal. For each one, write down the identity on every connection reference, the environment it runs in and the DLP policy covering that environment, and the systems it writes to. If any row names a maker's personal account on a connection, fix it before the page ships.
Then do the part people skip. Post to the form the way a script would, a few hundred times, from outside your network, and watch what the downstream system receives. If the answer is a few hundred records and nobody got paged, the page is not ready.
