Microsoft announced Azure Logic Apps Automation at Build 2026 and put it straight into public preview at auto.azure.com. The launch framing was “automation just became a team sport“. The product framing is a managed SaaS experience: you sign in, and compute, connectors, model endpoints, and knowledge services are already there.

I have spent the last months in the Logic Apps agent loop on Standard, and I wrote a seven-part series about what actually breaks there. So my first reaction to Automation was not “new designer, nice”. It was a governance question: who owns the workflow, who can read it, and what happens when the person who built it leaves?

That question turns out to be the most interesting thing about this release, and almost nobody is writing about it.

This post covers what Automation is, how it works, a scenario you can build and demo in about half an hour, and an honest list of what preview does not do yet.

Logic Apps Automation: What it actually is

Strip the marketing and Automation is four things at once:

• A new SKU on the same engine. The Logic Apps runtime is unchanged. The connector catalogue, 1,400 plus, is the same one you already use. Expressions, control flow, stateful and stateless workflows, draft and published versions: all familiar. Adam Marczak put it well after testing it: Automation is new, but agentic Logic Apps is not.
• A new hosting model. Consumption is multitenant and scales to zero. Standard is single tenant but you provision and pay for capacity. Automation is single tenant with a dedicated runtime boundary, Microsoft manages the hosting capacity, and it scales 0 to N. That combination did not exist before.
• A new resource hierarchy. Project, then Application, then Workflow. Sandboxes sit at project level. This is the part that changes how you govern.
• A new portal. auto.azure.com is not a replacement for the Azure portal. It sits alongside it. Projects show up as Azure resources in your resource group, but you build in the new experience.

Logic Apps Sandbox

One capability worth pausing is the Logic Apps Sandbox: built-in Python code execution within the agent loop, running in a secure, isolated environment with no external compute resource required. In the Standard agent loop series, I covered tools as connector actions the model can invoke at runtime. Sandbox adds a different category entirely: the agent writes code, executes it, observes the output, and iterates. Data transformation, chart generation, CSV processing, and dynamic API calls tasks that connectors alone cannot handle and that previously required an Azure Function or a custom action sitting outside the workflow. In Automation, Sandbox is already provisioned alongside the model endpoints and connectors. You do not configure it. You enable the Code Interpreter toggle in the agent action, and the capability is there. That is the managed SaaS promise made concrete, and it is the scenario I plan to cover in a dedicated follow-up post.

Where it fits next to the SKUs you already run

Positioning is now clearer than it was in the first 48 hours after Build. Power Automate is personal and team productivity inside Microsoft 365. Logic Apps are the enterprise integration platform: SAP, EDI, B2B, high-throughput API orchestration, predictable 24×7 load. Consumption remains excellent for sporadic, event-driven work.

Automation aims at the gap in the middle. Teams that need enterprise grade infrastructure but want a SaaS experience and AI assisted creation.

A short decision table, and I am reading direction here rather than quoting a Microsoft matrix:

How an agentic workflow actually runs

An agent in Automation is a workflow action backed by a model. You give it a system prompt, a toolset, an input, and downstream actions consume its output. There are two flavours.

Native agents run the loop inside the workflow runtime. Every iteration appears in the execution log. Tools are the action nodes you place inside the agent boundary, plus a Code Interpreter toggle.

Foundry agents hand off to Azure AI Foundry Agent Service. The workflow sees one call and a final output. You pick this when the assistant already exists in Foundry.

The switch between them is a config change in the AI model dropdown. The rest of the workflow does not care. That is a genuinely good design decision.

Two expression details worth memorising, because they are the seams where things break:

@outputs('AgentName')['lastAssistantMessage']
@outputs('AgentName')['structuredOutput']?['severity']

and inside a tool, to read what the model decided to pass you:

@agentParameters('errorCode')

Build on structuredOutput, not on the final message. In my blog series, I hit this the hard way: agent output arrives as a structured payload, and reaching for the prose answer produces workflows that pass a demo and fail on the third real message.

Logic Apps Automation: A scenario you can build and demo

Here is a demo that survives contact with an audience. It uses an HTTP trigger, which matters: HTTP and manual triggers fire from a draft, so you can iterate with Test your draft without publishing. Schedule and event driven triggers only fire against the published workflow.

The scenario: integration failure triage. A message lands on a dead letter queue. Instead of paging a human with a JSON blob, an agent classifies the failure, checks the runbooks, decides whether it is retryable, and either posts a structured summary to the on call channel or raises a ticket. The deterministic parts stay deterministic.

CREATE Project

• Create a project at auto.azure.com, then create an application inside it. Wait for the status to flip from Building to Ready before you open it. This will take some time.

• Start the workflow. You can type the intent into the assistant box, or click Build from scratch. For a demo I build from scratch, because every step stays visible and explainable.
• Add the trigger: search for Request, pick When an HTTP request is received. Give it a schema so downstream tokens are typed.
• Add Parse JSON. Yes, the trigger schema already types things. Doing it explicitly makes the failure mode visible when you demo a malformed payload.

Building the Agent Steps

• Drop in the agent action. System message, roughly: You triage failed integration messages. Classify severity as high, medium or low. Decide whether the failure is retryable. Use the runbook knowledge source before you answer. If the runbooks do not cover this error code, say so explicitly and set severity to medium. Never invent a runbook reference. Return structured output only.
• Attach a knowledge base. Agent panel, Knowledge tab, Add knowledge source, Document Upload, upload three or four runbook pages. Knowledge bases are private preview, so this may not be enabled on your project yet. Azure AI Search is the fallback if you already maintain an index.
• Add tools inside the agent boundary. Keep it to three or four. Toolsets of three to seven beat toolsets of twenty. Write the descriptions like docstrings, because the model’s reasoning is only as good as they are.
  • lookup_error_code as an HTTP action against your error catalogue. Inside it, read the argument with @agentParameters('errorCode').
  • get_recent_failures as a SQL or HTTP action, so the agent can see whether this is a one off or the fortieth today.
  • code_interpreter toggled on in the Parameters tab, for counting and grouping. It is JavaScript only, has no network access and no filesystem, so do not ask it to fetch anything.
• Set the iteration bound in the Settings tab. Six is plenty here. This is your cost fuse.
• Branch on the structured output, not the prose:

   @outputs('Triage_Agent')['structuredOutput']?['severity']

High goes to a ticket and an on call ping. Retryable goes back on the queue. Everything else goes into a digest.

Then click Test your draft, and watch the monitoring tab stream the run live. Real time run history is the single biggest day to day improvement over Standard, and it is the thing your audience will notice first.

The preview reality check

Every launch post is written in the present tense about a future state. Here is the current state, as of this writing.

The VNet discrepancy, because it matters

Microsoft’s launch post describes virtual network integration and private endpoints as day zero enterprise capability. The same post lists “VNet support and private endpoints” in its coming soon section. An MVP testing the preview reports it as missing.

I am not calling anyone wrong. I am saying that if you work in a regulated sector, this is the one line item you must verify in your own tenant before it appears on any roadmap slide. For a health insurer, “reaching internal systems without exposing them to the internet” is not a feature. It is the precondition for the conversation.

The governance question I opened with

Apps are private by default. That is deliberate and, for personal automations connected to someone’s own mailbox or OneDrive, it is correct. Project Owners and Contributors see app name, owner, creation date and last modified. They cannot read workflow contents, connections or run history.

Now put that in an enterprise. Three consequences follow.

• Auditability. Your compliance function cannot answer “what does this automation do and what does it touch” from the governance view. Someone has to be granted app scope access, per app, by the owner. That is a manual process with no obvious escalation path short of the Project Owner deleting the app.
• Orphaned apps. When an owner leaves, existing collaborators keep access and only the Project Owner can delete the app. Nobody inherits the ability to read it. In a large organisation, that is a slow accumulation of automations nobody can review and nobody dares remove.
• Shadow integration. The value proposition is that business teams build their own automations. The governance model means the platform team cannot see what they built. Both statements are true at once. That is not a bug, but it is a policy decision your organisation has to make deliberately rather than discover eighteen months in.

My working position: treat projects as the tenancy unit and map them to a business domain with a named owner and a named deputy. Require that anything touching regulated data lives in a project where the platform team holds app scope Contributor from day one. Write that down before the first workflow ships, not after.

Logic Apps Automation: What I would ask the product team for

Short list, in priority order, from someone who wants to put this in production.

1. A deployment story. CI/CD and a full project definition as code. Without it, Automation is a place to build, not a place to run a regulated workload. This is the single blocker.
2. An audit read role. A project scope role that can read workflow definitions and connection metadata across apps, without run history or payloads. Privacy by default and auditability are not in conflict if the role model is granular enough.
3. Ownership transfer. Reassigning an owner should not require deleting the app.
4. A published model support matrix for the Automation SKU, with the failure mode visible in the designer rather than at runtime.
5. Clarity on VNet and private endpoints in preview, stated once, in one place, with the region list.
6. Project level connector policy shipped early. Being able to block a connector class across a project is what lets a platform team say yes to self service.

Points 1 and 2 are the difference between an interesting preview and something an enterprise architecture board approves.

Logic Apps Automation: Where this is the wrong answer

Because it will not be the right answer everywhere, and pretending otherwise helps nobody.

• You already run a mature Standard estate. Do not migrate. The engine is the same, the value is the experience, and you would trade a working CI/CD pipeline for one that does not exist yet.
• SAP, EDI or B2B. Standard. Not close.
• Predictable, sustained, high throughput load. Standard is more cost efficient and you keep capacity control.
• Strict data residency or network isolation requirements that you cannot verify today. Wait for the VNet story to settle.
• Your problem is deterministic. If the steps are known up front and you need exact repeatable behaviour, an agent adds latency, cost and a non deterministic failure mode in exchange for flexibility you do not need. Use a plain workflow.
• You need conversational agents. Not in Automation yet. Consumption and Standard have that documented today.

What I would do on Monday

If you are a practitioner: get a project, build the triage scenario above or another scenario, and spend your time in the Chat tab and the retrieval view rather than the designer. The designer is pleasant and unsurprising. The observability is where the new value actually is.

If you are a decision maker: do not fund a migration. Fund one team, one project, one non regulated workflow, and a written answer to the ownership and audit question before the second team asks for access. The technology is further along than the operating model, and the operating model is the part you own.

Automation is in public preview. Treat it exactly like one, and it is the most interesting thing to happen to Logic Apps since Standard.

Sources

• Automation just became a team sport. Meet Azure Logic Apps Automation, Microsoft Community Hub
• What’s new in Azure Logic Apps at Microsoft Build 2026, Microsoft Community Hub
• Logic Apps Automation documentation, Microsoft
• Microsoft Launches Logic Apps Automation at Build 2026, InfoQ
• Logic Apps Automation release, what is it, and how it works?, Adam Marczak
• How to use Azure Logic Apps for workflow automation, GeeksforGeeks
• A comprehensive guide to Azure Logic Apps, DEV Community