In July, I wrote a preview assessment of Logic Apps Automation. One row in my reality-check table read: “Pricing: not finalised.” I declined to quote meters, because third-party posts were running ahead of Microsoft.
That row is now closed. On October 7, the Logic Apps team announced pricing together with a monthly free grant. This post covers what the numbers say, and which parts of my July advice they confirm or correct.
One note on terms first. In July I described the hierarchy as Project, Application, Workflow. The documentation now says Environment, App, Workflow. I use the new names here.
What you get for free
Every Azure subscription receives the following:
Component
Free grant
Managed environment
One environment, free for the first 60 days only
Workflow runtime
108,000 execution-seconds per month (about 30 hours)
$0.000024 per vCPU-second, $0.000003 per GiB-second
The runtime meter counts execution-seconds on a baseline of 1 vCPU and 2 GiB of memory. Consumption, in contrast, counts actions. Standard charges for reserved capacity. As a result, a slow workflow now costs more than a fast one, regardless of its action count.
AI usage is billed in AACs, converted from tokens based on the model you select. In July, I called the agent iteration bound “your cost fuse”. That fuse now protects a number: 1,100 AACs per month. Moreover, if you bring your own model, Automation does not charge the token usage at all.
What happens on day 61
The environment fee is the part that matters most. At $0.042 per hour, an environment costs about $30.66 per month, whether or not anything runs.
Compare that with the grant. By my arithmetic, the monthly usage grants are worth roughly $21 at list rates: $8.64 of runtime, about $11 of AI usage, and under $2 for everything else. The AI figure assumes one AAC equals one cent, which I derive from the knowledge storage line. Microsoft does not state it.
So from day 61, the fixed fee exceeds the value of everything the grant gives you. The grant lowers the bill. It does not make the platform free.
One correction to my July post
My decision table placed “long idle periods with traffic spikes” on Automation, because the runtime scales from 0 to N. The compute still does. However, the environment fee does not scale to zero.
Therefore, I would now move very sporadic, low-volume work back to Consumption, which has no fixed fee. Automation remains the better fit for bursty AI and agent workloads that justify roughly $30 a month as a baseline.
The grant has an owner problem
My main concern in July was governance: who owns a workflow, and what happens when that person leaves. The grant adds a billing version of the same question.
The grant applies to the first environment you create in a subscription. Delete that environment and you lose the grant for good. A new environment does not restore it. In addition, existing preview users must create a new environment to receive it.
Consequently, the first person to click “create” decides where the subscription’s free grant lives. The documentation itself names “billing context” as a reason to separate environments. My July advice was a named owner and a named deputy. Apply the same rule here.
Where this is the wrong answer
Sustained load. Running the baseline continuously consumes about 2.6 million execution-seconds, or roughly $210 per month, plus the environment. A Logic Apps Standard WS1 plan costs about $175. So my July claim holds: predictable 24×7 load belongs on Standard.
EU data residency. The preview runs in Australia East, East Asia, North Central US, Southeast Asia, Sweden Central, UK South, and West US. West Europe and North Europe are missing. Inside the EU, Sweden Central is the only option.
Note: How my list compares with the announcement
Region
Announcement and docs
MY portal
Australia East, East Asia, North Central US, Southeast Asia, UK South, West US
Yes
Yes
Sweden Central
Yes
No
Brazil South, West Central US
No
Yes
Central US EUAP, East US 2 EUAP
No
Yes
Budgets that need certainty. The published rates are East US estimates, and East US is not a preview region. Furthermore, Microsoft says the new pricing rolls out in phases and may change before general availability.
Anyone counting on 30 free hours of production. The documentation states that the runtime host also runs during portal authoring. Designing in the portal draws on the same grant.
What stays open
Pricing closes one item. The others from July remain: CI/CD and environment-as-code, an audit read role, ownership transfer, a model support matrix, and a clear statement on VNet and private endpoints. Knowledge bases and sandboxes are still labelled preview, although the grant already covers both.
What I would do on Monday
My July advice to decision makers was: fund one team, one environment, one non-regulated workflow. That advice now costs close to nothing for 60 days. Three additions follow from the pricing.
First, create the free environment deliberately, in the subscription and region you intend to keep. Second, check the Free Grants tab under Settings weekly during the first month. Third, put day 61 in the calendar, and decide before that date whether the workload is worth $30 a month.
The technology is still further along than the operating model. Now the bill is, too.
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.
Figure 1. Project, Application, Workflow, plus the two permission scopes that sit on top of them. Project admins see app metadata for governance, not workflow contents, connections, or run history.
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.
Figure 2. Automation is not a replacement for Standard. It fills the gap between a productivity tool and an integration platform: single-tenant isolation, but Microsoft manages the capacity.
A short decision table, and I am reading direction here rather than quoting a Microsoft matrix:
Scenario
Where I would put it today
SAP, EDI, B2B, high throughput API orchestration
Standard
Central integration platform, predictable 24×7 load
Standard
Simple event driven automation, low volume
Consumption
AI and agent workloads with bursty traffic
Automation
Long idle periods with traffic spikes
Automation
Departmental workflow owned by a business team
Automation, with the caveats in section 5
Personal productivity inside Microsoft 365
Power Automate
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.
Figure 3. The loop, the tools, the grounding, and the lane where you debug all of it. Branch on the agent’s structured output, not on its prose answer.
Two expression details worth memorising, because they are the seams where things break:
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.
Figure 4. A demo that shows the loop, the grounding, and the deterministic guardrails around both. The convincing run is the one where the agent declines to invent an answer.
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.
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.
Area
Status today
CI/CD and deployment pipelines
Missing. There is no deployment story yet.
Export the whole solution as code
Missing. Versioning exists, but at workflow level.
ARM export
Workflow code does not appear in the ARM template, and Export Template fails in the Azure portal. You can copy and paste workflow code from the Automation portal.
Conversational workflows
Not supported in Automation today, although they are documented for Consumption and Standard in Logic Apps Labs.
VNet integration and private endpoints
Contested. See below.
Knowledge bases
Private preview. Document upload limits, per source token budgets and granular permissions are all still moving.
Sandbox input files
.txt and .md only in private preview. CSV needs a contentType set by hand in code view.
Code Interpreter
JavaScript only. No network. No filesystem. Per execution timeout. Sized for transformation, not compute.
Model support
Not every model works yet. Marczak reports workflows failing on GPT 5.1 that ran on 4.1, and the same workflows working on Standard.
Pricing
Not finalised. Third party posts quoting specific meters are running ahead of what Microsoft has published.
Regions
An initial set at launch, with more rolling out. Check before you promise anything.
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.
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.
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.
Ownership transfer. Reassigning an owner should not require deleting the app.
A published model support matrix for the Automation SKU, with the failure mode visible in the designer rather than at runtime.
Clarity on VNet and private endpoints in preview, stated once, in one place, with the region list.
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.
