SimpleFlow
Multi-tenant iPaaS and AI Foundry agent runtime on Azure.
For Platform engineers and integration leads at Microsoft Solutions Partners and ISVs shipping multi-tenant workflows to downstream customers. Complements Power Automate for the in-tenant Microsoft 365 workloads it handles best; SimpleFlow is for the multi-tenant ISV use case Power Automate was not built for.
n8n was not built for MSPs. Zapier was not built for regulated workloads. SimpleFlow is designed to run workflow and agent execution on Azure Logic Apps Standard and AI Foundry Agent Service, deployed per tenant into the customer's own Azure subscription through Azure Lighthouse, so the workflows are the customer's own Azure resources under their own governance. The control-plane record is designed to carry which workflows exist, their version history, and the audit trail of privileged actions taken on the customer's behalf.
When you can get SimpleFlow
Coming soonNot open yet. Tell us where to send word when it is.
What you can do now
Get product updatesNone of these creates an account, a trial, or access. Each one records what you asked for so a person can answer it.
Where this stands
- Availability
- Coming soon
What it costs
No published price yet. Pricing is set before this product opens.
Routes that are not open
- Direct trial with Simple Intelligence Not open yet
- Direct subscription from Simple Intelligence Not open yet
- Microsoft Marketplace Not published yet
- Sponsored subscription for member companies Not open yet
The connector library is the trap, and building one is how small teams lose.
Anyone replacing Zapier or n8n is asked for the long tail of integrations on the first call, and a team our size cannot hand-write a credible one, let alone keep it current as every vendor changes their API. SimpleFlow was rebuilt in May 2026 to stop trying. The workflow runtime is Azure Logic Apps Standard, so the connector library is Microsoft's first-party set, maintained by Microsoft, inheriting Microsoft's certification posture rather than one we would have to earn control by control.
The design puts your workflows in your subscription, on your compute.
The intended shape is that each customer gets their own Logic Apps Standard instance with its own App Service plan, storage account, and Application Insights, deployed by Bicep into their own Azure subscription, with agents in their own AI Foundry project. Those resources would be operated through Azure Lighthouse, which is Microsoft's existing delegation service, so the customer keeps ownership of the resources and can see and withdraw the delegation from their own portal. The Bicep for both sides exists. It has not been run for a customer.
Getting off the old tool is the part that actually blocks people.
Most teams carrying an automation tool their security review no longer likes are not stuck on the destination, they are stuck on the hundreds of workflows already running. So a migration engine was built before anything was sold: it reads n8n, Zapier, and Make exports and emits Microsoft's standard Logic Apps triplet, which is a format an Azure team can read and finish rather than a private one only we understand. Six Zapier built-in step types translate deterministically today. Everything else comes out as a marked placeholder carrying the original parameters verbatim, because the model-assisted half is still a deterministic stub in the code rather than a live call.
Where this stands.
SimpleFlow is a designed product with a substantial codebase and no customer environment available. The architecture decisions are written down and argued, the control-plane API and the migration engine exist with tests, and the per-tenant deployment is written as Bicep. None of it is serving anyone today, so everything below describes design and code rather than a system you could be pointed at.
Working today
- A decided architecture with the reasoning recorded: sixteen decision records covering the runtime pivot, the per-tenant topology, the delegation model, the authoring surface, the identity model, and cross-tenant aggregation
- The per-tenant runtime written as Bicep for both the control plane and the customer side, deployed through Azure Lighthouse against a resource group the customer names
- A control-plane API in .NET 9 covering workflows and versions, runtime deployments, agent invocations, knowledge queries, marketplace fulfilment and metering, audit, compliance and data-subject requests, and administrative surfaces
- A migration engine that reads n8n, Zapier, and Make exports and emits Microsoft's standard Logic Apps triplet, with six Zapier built-ins translating deterministically and the SaaS long tail routed through an AI-assisted path that stamps confidence and reasoning onto every placeholder it produces
- The Azure Portal workflow designer embedded as the authoring surface, so customers author in the component Microsoft ships rather than one we would maintain
- Entra ID multi-tenant OIDC as the only first-party identity provider, decided in writing, with non-Entra users routed through Microsoft's own guest-invite path rather than a second provider we would implement
- A federated-read design for every cross-tenant view, where queries run against the customer's own Log Analytics rather than against a copy of their telemetry
- An end-to-end test suite covering the control-plane API and the migration engine
Not yet
- The design has never been tested by a real customer subscription, which is what makes everything above provisional rather than proven. Nothing here has been through the review, the connector edge cases, or the operational surprises that a first deployment produces.
- The permission scope of the Lighthouse delegation is still being narrowed, so this page describes the delegation mechanism rather than publishing a permission list that would then need correcting.
- The AI-assisted half of the migration engine returns a deterministic stub rather than calling a model, so the SaaS long tail is not translating for real yet. The six deterministic Zapier built-ins do work.
- There is no purchase route. The Azure Marketplace offer is a draft with one of its twenty go-live items checked, and there is no other way to buy it.
- No certification is held. Logic Apps Standard inherits Azure's compliance posture for the resources it runs on, which is a real and useful property of the architecture and is not the same thing as SimpleFlow holding an attestation of its own. It holds none.
Verified against the product on 2026-08-23.
Who this is being built for.
Shipping the same workflow to fifty customer tenants
One workflow authored once and deployed into each customer's own subscription, versioned centrally, with each customer's runs and connections staying on their side of the boundary. This is the case the product exists for, and it is the one Power Automate was not built for: Power Automate is excellent at the in-tenant Microsoft 365 work it handles, and a multi-tenant ISV motion is a different shape.
Getting off a tool your security review has stopped approving
The migration engine reads an n8n, Zapier, or Make export and produces Microsoft's standard workflow JSON, connection definitions, and agent definitions. What comes out is a procurement-ready artifact in a format your Azure team already reviews, with every step the engine could not translate confidently marked as needing review rather than quietly approximated.
The buyer whose first question is whose subscription it runs in
A multi-tenant automation service running in the vendor's cloud is a conversation about isolation that the vendor has to win on its own word. Deploying into the customer's own subscription is meant to change the question from how well we isolate to what exactly we are authorised to touch, which is a question the customer answers from their own portal rather than from our documentation. Getting that authorisation scope right is the part still being worked through.
Agents that need to do something, not just answer
Agents run in the customer's own Foundry project, invoked from a workflow through a custom connector, with knowledge sources indexed under the customer's identity and governed by the customer's existing permissions. The workflow is what gives the agent hands, and the approval steps are where a person stays in the path.
How it is designed to work.
You accept a delegation, in your own portal, against a scope you name
The onboarding step is an Azure Lighthouse offer the customer accepts against a resource group they choose. Lighthouse is Microsoft's own service rather than a credential exchange we invented, so the delegation appears in the customer's portal under their service-provider view, they can read exactly what it grants there, and they can withdraw it at any time without contacting us. The specific permission set is being finalised as part of the work described in the readiness section.
The runtime is deployed into your subscription
Bicep provisions a Logic Apps Standard instance with its own App Service plan, storage account, Key Vault, and Application Insights, plus an AI Foundry project when agents are in play. These would be your resources, on your bill, in your region.
Workflows are authored in the Microsoft designer
The authoring surface is the same designer component Microsoft ships in the Azure Portal, embedded in our shell. Connector forms, parameter validation, and the expression builder come from Microsoft and stay current with Microsoft, which is the point of embedding it rather than rebuilding it.
Saving records a version on our side and the workflow on yours
A save is designed to write an immutable version row in the control plane, carrying who saved it, when, how large it was, and whether it was AI-authored, then forward the definition to your Logic App. The version history stays on our side so it survives a runtime being rebuilt; the running definition sits on yours.
Observability is designed to read your telemetry where it already is
Dashboards are specified to query the customer's own Log Analytics workspace through the delegation rather than a replicated copy, joining results in memory. The one thing the design deliberately keeps on our side is an audit row for each privileged action the control plane performs in a customer subscription, because both sides need to be able to answer what SimpleFlow did this week.
Design decisions worth knowing about.
Nothing on this list is available today. This is the product we intend to build, written down so you can tell us whether it is the right one, and it will change.
The runtime is Microsoft's, and that was a decision with alternatives on the record
SimpleFlow started as a custom .NET execution engine and stopped being one in May 2026. The decision record that replaced it lists the five alternatives that were rejected, including the tempting one of running Logic Apps multi-tenant in our own subscription, and says why each was refused. The consequence a buyer cares about is that the workflow engine, the connector library, and the certification posture underneath all belong to Microsoft rather than to a small vendor promising to keep up.
Leaving is designed to be a customer action, not a support ticket
Azure Lighthouse delegations are withdrawn by the customer from their own portal, without contacting the provider and without notice. Building on Microsoft's delegation service rather than on an exchanged credential is what makes that true, and the design treats a withdrawn delegation as a supported end state that marks the runtime unreachable rather than as an incident to escalate. An arrangement where the customer needs the vendor's cooperation to leave is not one worth asking anybody to accept.
Migration output you can read before you trust it
The engine emits Microsoft's standard triplet rather than a private format, so the result is reviewable by anyone who knows Logic Apps. Anything the engine could not translate confidently comes out as a marked placeholder rather than a silent approximation, carrying a generated flag, a confidence figure, the reasoning, and the original step parameters captured verbatim so a reviewer can finish the mapping by hand. A migration tool that hides what it guessed is worse than one that translates less.
Cross-tenant views are designed without a copy of your telemetry
Aggregation across tenants is a hard problem to solve honestly, because the easy version is to copy everything into one place first. The specified pattern queries each tenant's own workspace through the delegation and joins the results in memory rather than persisting them. The one exception written into that decision is the audit trail of our own privileged actions, which is a record of what we did rather than of what a workflow processed.
One identity provider, on purpose
Microsoft Entra ID is the only first-party identity provider, decided in writing and reversible only by superseding that decision rather than by a quiet feature flag. A user outside Entra signs in through Microsoft's own guest-invite path in the customer's tenant, which is a Microsoft feature rather than an integration we maintain. The cost is that a prospect running no Entra at all is harder to onboard, and that is accepted rather than hidden.
What is designed to sit where.
The control plane, in our subscription
A .NET 9 API and a React application holding the workflow and agent version history, the migration engine, the template library, the administrative surfaces, and the audit trail of privileged actions taken in customer subscriptions. It is multi-tenant, and the target architecture is deliberate that it is not where customer workflows execute.
The runtime, in yours
Logic Apps Standard for workflows, AI Foundry Agent Service for agents, Foundry IQ for knowledge grounding, with a Key Vault, a storage account, and an Application Insights instance alongside them. Single-tenant by deployment topology rather than by partition key, which is the distinction a security reviewer is asking about when they ask about isolation.
The seam between them
Azure Lighthouse, scoped to a resource group you name and accept in your own portal. Requests from the control plane to your resources are signed with our managed identity and authorised by that delegation, so the model does not involve handing over a customer credential for us to store. What the delegation is permitted to do is the part currently being narrowed, and this page will carry the specifics when they are settled rather than before.
The authoring surface
Microsoft's Logic Apps designer embedded in our shell, with its data services pointed at a control-plane proxy that forwards to your Logic Apps management API through the delegation. The proxy exists so that the browser-side designer is not the thing holding a token against your subscription.
What it is built on.
A name here is a system this product is built to work with, not a promise that the connection is live in your tenant. Where a connector carries a status label, that label is the current state. Anything that needs its own vendor registration, its own consent, or its own approval says so, and nothing on this page can be taken as available until it is confirmed for your tenant.
Microsoft platform this is built on
Connectors, maintained by Microsoft rather than by us
Migration sources it reads
Reading data from an external system is not a way to sign in. Customer identity stays with Microsoft Entra ID, and no data source on this list authenticates a person.
Where each statement on this page comes from.
What a platform team asks first.
What is the fastest way to tell whether this is worth watching?
Ask where your workflows should end up living. If the right answer is that they become Azure resources inside your own subscription, under your own governance and on your own bill, and you need the same workflow shipped into a lot of subscriptions rather than one, this is being built for you. If your workflows are comfortable where they are, nothing here needs to be on your list.
Where is our workflow data designed to go?
Workflows are designed to run on Logic Apps Standard in your own subscription, with connections in your Key Vault, run history in your Application Insights, and agents in your own Foundry project. The control plane is designed to hold the version history of your workflow definitions, your tenant record, and an audit row for each privileged action we take in your subscription. That is the target, written as a design rather than as a guarantee, and the right way to check it is against a deployment you can inspect rather than against a marketing page. When there is one, ask for the Bicep and the delegation offer and read them.
What exactly would you be able to do inside our subscription?
The mechanism is Azure Lighthouse, scoped to a resource group you name. You accept the delegation in your own portal, you can read exactly what it grants there rather than taking our word for it, and you can withdraw it at any time without contacting us. The specific permission set is being narrowed right now, so we are not publishing a role list that would then need correcting. When a customer environment is available, the delegation offer you are asked to accept is the authoritative answer to this question, and it should be reviewed on its own terms.
How is this different from Power Automate?
It mostly is not, at the runtime layer, and that is deliberate: underneath, Microsoft is running the workflow either way. The difference is the shape around it. Power Automate is built for work inside one tenant. SimpleFlow is built for authoring once and deploying the same workflow into many customers' subscriptions, with version history, migration tooling, and a delegation model designed for a provider operating on somebody else's behalf. If your automation lives inside your own tenant, Power Automate is the better answer and we will say so.
Does the migration actually work, or does it produce something we have to redo?
It produces Microsoft's standard workflow, connection, and agent definitions, which is a format your Azure team can read and finish. Six of Zapier's built-in step types translate deterministically. Everything outside that set currently comes out as a marked placeholder carrying the original parameters verbatim, because the model-assisted translation is a stub in the code today rather than a live call. Treat it as a head start that shows its work, not as a finished migration.
Do you hold any compliance certifications?
No. The resources your workflows run on are Azure resources in your subscription and inherit Azure's posture, which is a genuine advantage of this architecture and is a statement about Microsoft rather than about us. SimpleFlow itself holds no attestation, and anybody telling you the architecture confers one on the vendor is describing something else.
How do we hear when it is ready?
Ask for product updates through the form on this site, which records the request against SimpleFlow specifically. There is no waiting list with a position in it and no early access programme to apply to, because neither exists and inventing one would be worse than saying nothing.
What it sits next to in the portfolio.
SimpleFlow is the connective layer beneath the suite rather than another application in it. Where each product owns its own work, this one is designed to carry an event from one to the next, and to reach the systems a customer already runs that no SIG product replaces.
The useful conversation right now is about your exports.
If you are carrying a security exception for an automation tool, the thing worth sending is what your workflows actually do: how many, which systems they touch, and which ones nobody is allowed to break. That is what decides which connectors and which migration paths matter first, and it is the input that shapes the order this gets built in.