Power Automate and PowerApps frontends extended with a service running on Azure AKS
We built an order management solution on Microsoft's low-code stack, then pushed past the platform limits with a Flask microservice on Azure AKS. A case of working with the stack a client already runs instead of forcing a rewrite.
Problem
The client needed an order management solution inside their existing Microsoft 365 environment. They wanted us to build within their current stack rather than add a new platform. The low-code tooling hit its limits once the business logic grew complex.
Approach
A PowerApps frontend and Power Automate flows handled what the platform does well: form-based data entry, approval workflows, M365 integration, and SharePoint connectivity. Where the platform stopped, a Flask microservice took over custom computation, external API calls, and stateful processing, called from Power Automate via HTTP connector.
Architecture
PowerApps serves as the user-facing interface. Power Automate flows orchestrate the workflow and M365 integration. A Flask microservice on Azure AKS handles logic that Power Automate cannot express. The low-code layer and the microservice talk over the HTTP connector with structured JSON payloads.
Outcome
We delivered a working order management system inside the client's existing Microsoft infrastructure, with no new platform to license, train on, or maintain. The Flask layer extended the solution where it was needed without replacing what the low-code stack handled well.
Context
The client already ran Microsoft 365 across their organisation. Building outside that ecosystem would have meant new licensing costs, new tooling for non-technical staff, and a system separate from the workflow integrations they relied on. The brief asked us to build the order management solution within the Microsoft stack, so Power Automate and PowerApps were the primary tools.
What the low-code stack handled
PowerApps provided the interface for order entry, status tracking, and approval actions. Power Automate ran the workflow layer: approval routing, notifications, SharePoint list operations, and M365 calendar and email integrations. For most of the requirements, these tools were the right choice. They were fast to build, maintainable by non-developers, and native to the client's environment.
Where the microservice came in
Power Automate has hard limits on custom computation and stateful processing. Some order logic resisted a clean expression in the platform: aggregation across multiple list sources, conditional routing on calculated fields, and calls to external APIs that the standard connectors do not cover. Rather than force this into a fragile chain of flow conditions, we deployed a Flask microservice on Azure AKS to handle these cases. Power Automate calls it via HTTP connector, passes structured JSON, and processes the response like any other connector output.
Deployment
We containerised the Flask service and deployed it on Azure AKS in the same Azure tenant as the client's other services. Authentication between Power Automate and the microservice used Azure-native identity, which keeps credentials out of flow variables. We scoped the service narrowly so it handled only the operations the low-code platform could not, keeping the maintenance surface small.