DEV Community: Daniel Jonathan

The Green Screen That Wouldn't Let Go

Daniel Jonathan — Fri, 09 Oct 2026 17:25:02 +0000

How we taught a robot to rescue 15 plus years of accounting data from a 1990s computer — and then taught other robots to babysit it

Picture an accounting system older than the web. No mouse. No windows. Just a black screen with green text where you type short codes and press Enter, all day.

A client was finally leaving that system. But first they needed its history out: reports for over a thousand companies, each spanning multiple years. For every company and year, someone had to produce a yearly journal report, twelve monthly VAT reports, and a summary. That added up to tens of thousands of exports — with no export button, no API, and no bulk extraction tool.

So we built a robot that types like a human. This is the story of making it run unattended for days — told in seven pictures. Every picture exists because something broke.

The map

Here is the complete self-healing architecture:

At the bottom: the AS/400 accounting system. Above it: two macro robots running in parallel (one for yearly reports, one for monthly VAT reports). Above them: a supervisor that watches their activity, restarts failed sessions, and dismisses frozen error popups. Off to the side: alert emails fired as events happen, and a daily audit report.

The entire stack is built from exactly two kinds of parts: terminal macros (EXTRA! Basic — the robots that do the typing) and PowerShell scripts (everything that watches, restarts, reconciles, and reports). No RPA platform, no framework, no license fees — two scripting languages, one of them frozen in 1995, and a lot of respect for failure modes.

Full disclosure: an AI coding assistant pair-programmed much of it with me — writing and revising the macros and PowerShell, and helping diagnose the failure signatures you're about to read from their log traces. There's something fitting about a modern AI patiently writing 1995-era Basic for a 1990s green screen.

Every layer follows one fundamental rule:

A robot cannot be trusted to report its own death.
Every layer exists to catch a failure the layer below it cannot see.

Act 1: You can't automate what you can't see

Our first prototype simulated keypresses aimed at the terminal window. It worked in a demo, but failed in production: it was typing blind, unable to read screen state or error popups.

Switching to Attachmate EXTRA!'s macro engine (EXTRA! Basic) gave us direct COM access to the terminal's 80x24 screen memory buffer. The robot got eyes.

Lesson 1 — Being able to see matters more than having nice tools.

Act 2: Reading a screen like it's 1979

Reading an 80x24 screen means processing 1,920 raw characters with no DOM, links, or page load events. The robot must deduce its screen state before acting.

This state check carries a critical navigation trap, because two different screens sit one letter apart:

Identificatie — the login screen: the module selector you land on right after logging in. Typing the module code opens the company list.
Indentificatie — the post-login screen: the company list header, inside the module. Note the extra n: nearly the same word, but it marks a completely different state.

If the robot mistakes the company list for the login screen and re-sends the module code, those keystrokes land straight in the company search field, corrupting the search and derailing the loop.

So the robot checks for the post-login Indentificatie first, and only then for the login screen's Identificatie — that one-letter label is each screen's unique fingerprint, and the check order is what keeps navigation commands out of data input fields.

The whole thing runs as one loop: navigate to the company list, type the company name, reach its main menu, export that year's reports, write the result in the ledger — then repeat for the next company and year. When a company turns out not to exist in the system (or hides behind a password popup), the robot doesn't die: it dismisses the popup, logs the skip, returns to the company list, and carries on with the next one.

Even a screen the robot cannot recognize isn't an immediate stop. It saves a snapshot, logs the error, and tries to find its way back to the company list to carry on with the next company. Only when that recovery also fails does the log stop moving — and a log with no fresh entries is exactly what the supervisor treats as a hang signal (Acts 4 and 6). The loop never ends with a shrug: it either continues, skips, or hands over to the watchdog.

Lesson 2 — State recognition is everything. Never send navigation commands into a data input field.

Act 3: The crash that hid inside its own evidence

The AS/400 host needs time to draw screens. We initially waited 1.5 seconds after keystrokes, then cut it to 500ms to speed up tens of thousands of runs.

That triggered a race condition: popups render onto the terminal screen after network traffic goes quiet. At 500ms, the robot checked early, saw no message, and panicked. Worse, its diagnostic screen dump — the full 1,920 characters written to an error file — captured the screen a few milliseconds later, after the popup arrived, hiding the crash inside its own evidence.

We settled on a 1-second host settle time (g_HostSettleTime), backed by multi-pass retries on late-drawing screens.

Lesson 3 — With old systems, patience isn't a weakness. It is the protocol.

Act 4: The error window the robot cannot see

When the macro engine encounters a fatal runtime exception, it displays a modal popup — instantly freezing the script. The robot cannot detect its own crash or write a log entry. You cannot ask an unconscious patient to take their own pulse.

The watchdog lives inside the supervisor and is almost embarrassingly small: on every poll, a Win32 call looks for the dialog by its exact window title, and if found, posts an Enter keystroke straight to that window handle — no focus stealing, nothing typed into whatever window happens to be active:

# every supervisor poll — exact title only, never a pattern
$hwnd = [Win32]::FindWindow($null, "Extra! Basic Error")
if ($hwnd -ne [IntPtr]::Zero) {
    [Win32]::PostMessage($hwnd, $WM_KEYDOWN, $VK_RETURN, [IntPtr]::Zero)
    [Win32]::PostMessage($hwnd, $WM_KEYUP,   $VK_RETURN, [IntPtr]::Zero)
}

Two rules make it safe:

Exact window title matching. FindWindow with a broad or generic title could post Enter into an unrelated application. One confirmed title, nothing else.
Audit-logged alerts. Every intervention is written to the supervisor's own dated log and triggers an email alert attempt — failed deliveries are themselves logged, never swallowed.

Dismissing the error window only clears the process. The real health check is: did the robot's log resume updating afterward?

Lesson 4 — Anything that can't watch itself needs an outside watcher. Clearing a modal doesn't mean the process survived.

Act 5: The day the computer lied about the time

The supervisor treats a log with no new entry for five minutes as a hang signal.

Initial versions checked the file's LastWriteTime, producing false alarms: with a log held open for appending for hours, that metadata goes stale — entries land on disk while the recorded timestamp lags behind. Worse, the watcher's own read of the file incidentally forced the metadata to refresh, so every false "stalled" alert was followed by a false "recovered" exactly one poll later. The watcher was curing the stall it had just reported.

The fix: make the log's content the primary signal. Every log entry starts with a timestamp the robot wrote itself, so the supervisor reads the tail and trusts the newest one it can parse:

$tail = Get-Content -Path $Path -Tail 5
for ($i = $tail.Count - 1; $i -ge 0; $i--) {
    if ($tail[$i] -match "^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2})") {
        return [datetime]::ParseExact($Matches[1], "yyyy-MM-dd HH:mm:ss", $null)
    }
}
return $Fallback   # LastWriteTime — only for a brand-new log with no parseable line yet

Lesson 5 — Judge whether something is alive by what it says, not by the label on its folder.

Act 6: Nobody wants to restart a robot at 3 a.m.

To eliminate manual midnight interventions, we created a supervisor script — a single PowerShell process running 24/7 — enforcing a tiered escalation ladder:

Targeted Restart — after 5 minutes of log silence: kill only the frozen session, give the host a ~25-second cooldown, reopen, log back in, relaunch the macro. The parallel session keeps exporting throughout.
Full Environment Reset — after 3 consecutive failed targeted restarts of the same session: both sessions come down and back up.
Human Escalation — after 3 failed full resets: the supervisor stops retrying and fires an emergency alert, because at that point something is wrong that a relaunch won't fix.

The supervisor manages queue advancement, process lifecycles, and clean shutdown upon completion.

Lesson 6 — Don't just automate the work. Automate the person who babysits the work.

Act 7: A report doesn't exist until it's checked, filed, and written down

Generated reports undergo automated pipeline verification before queue status updates:

File Growth Stability: Polls each exported report — XLS and PDF alike — comparing file size at one-second intervals until it stops changing, before moving it.
Monotonic Queue Advancement: Updates queue files (companies_yearly.txt / companies_btw.txt) so crashes resume at the exact pending step.
Daily Reconciliation Audit: A 07:00 AM scheduled task reconciles disk files against logged status, reporting missing deliverables or unrecorded files.

Lesson 7 — Compare beliefs with facts daily. Let an audit confess the difference.

What this old machine taught us

Seven lessons, but really three themes:

Observe everything. Pick the runtime that can see (Act 1), recognize state before acting (Act 2), and judge liveness by what a thing says, not what its metadata claims (Act 5).
Distrust everything. Timing (Act 3), your own crash evidence (Act 3), a dismissed error dialog (Act 4), and even your own ledger (Act 7) — each lied to us at least once.
Automate the response, not just the work. An outside watcher for what can't watch itself (Act 4), an escalation ladder instead of a pager (Act 6), and bookmarks that make any crash cost one report, not one night (Act 7).

None of these lessons are really about old computers. An unreliable partner, no shared clock, failures that make no sound, progress that must survive a crash — that's the everyday physics of any two systems working together. Modern platforms just hide it well enough that you can pretend otherwise.

The old green screen refuses to let you pretend.

Building with TypeSafe AI's Jev in Logic Apps: from triage to a router agent

Daniel Jonathan — Wed, 07 Oct 2026 10:45:41 +0000

TypeSafe AI's Jev model answers only in a shape you define. You send it state (your text) and a set of typed questions, and it returns typed values with calibrated probabilities instead of free text to parse. I wired it into two Logic Apps Standard workflows: a triage demo that turns typed answers into a routing decision, and a router agent that uses the same idea to pick which of two existing agents should handle a task. This post covers both, the real mistakes along the way, and the runs that prove they work.

What Jev answers with

The System One API (POST https://api.typesafe.ai/v1/systemone) takes three question types, confirmed against the docs and a live call:

Type	You give it	It returns
`noul`	a yes/no question, with `criteria` describing true and false	a single number from 0 to 1 — the probability of "true"
`choice`	named options with descriptions	the picked option key, plus `probabilities` and `confidence`
`score`	an ordered list of levels	a numeric `score`, a `legend`, and `probabilities` per level

A real request, testing a billing complaint, returned:

{"answers":{
  "urgent":{"type":"noul","noul":0.98},
  "category":{"type":"choice","choice":"billing","confidence":1.0,
    "probabilities":{"technical":0.0,"billing":1.0,"account":0.0,"general":0.0}},
  "sentiment":{"type":"score","score":0.0,"confidence":1.0,
    "legend":{"0":"Negative…","1":"Neutral…","2":"Positive…"}}
}}

Every value is one of the three typed shapes above. There's no free text to parse, and nothing it can hallucinate outside the schema.

Part 1: Triage

The project already had a starting point: a single Http action calling Jev with one noul question and returning the raw response. I built it out to ask three questions in one call — urgent (noul), category (choice), and sentiment (score) — then added a Compose_Triage action that turns the typed answers into an actual decision:

"priority": "@if(greater(body('Call_TypeSafeAI')?['answers']?['urgent']?['noul'], 0.5), 'High — needs immediate attention', 'Normal')",
"team": "@if(equals(body('Call_TypeSafeAI')?['answers']?['category']?['choice'], 'billing'), 'Billing', if(...))",
"suggestedReplyOpener": "@if(less(body('Call_TypeSafeAI')?['answers']?['sentiment']?['score'], 0.5), 'I''m sorry to hear about the trouble you''ve had.', if(...))"

score comes back as a float that matches the legend index exactly — 0.0 for Negative, 1.0 for Neutral, 2.0 for Positive in our test calls — which is what makes a plain less(..., 0.5) a safe way to test for "Negative" specifically, rather than needing to round or compare against an integer.

That's the point of asking typed questions instead of a free-text prompt: the workflow can branch on urgent.noul and category.choice directly, with no parsing step in between.

It runs

This is the published triage workflow running in Logic Apps Automation, after both fixes: RcvMsg → Call_TypeSafeAI (809 ms) → Compose_Triage (77 ms) → Response (179 ms), succeeded in 2.4 seconds total. Most of the time is the Jev call itself; the triage logic on top of it costs under 100 ms.

Part 2: A router agent

The obvious next step: use the same typed classification to decide which agent handles a task, instead of one do-everything agent or parsed free text. RouterAgent takes {"task": "..."} and does three things:

Classify. Ask Jev a single choice question — is this math or general?
Switch. Branch on the answer.
Dispatch. Call the agent that matches: BodmasAgent for math, a new GeneralAgent for everything else.

"taskType": {
  "type": "choice",
  "instructions": "What kind of task is this? Pick math only when it needs a precise numeric calculation.",
  "criteria": {
    "math": "A specific arithmetic expression or calculation to compute — numbers with +, -, *, /, ^, or a word problem that reduces to one",
    "general": "Anything else: questions, explanations, writing, conversation, or requests that are not a calculation"
  }
}

GeneralAgent is new: a tool-free, single-turn agent that answers directly and returns synchronously, built specifically so the router has a general-purpose target that doesn't need MCP tools or an agent loop.

Call workflow doesn't work in Automation — use Http instead

Logic Apps Standard has a built-in action for calling another workflow in the same app directly (inputs.host.workflow.id), no URL or SAS signature needed. It's the obvious choice for dispatching to BodmasAgent and GeneralAgent, both in the same app as RouterAgent. It didn't work here. Automation's workflows are proper Standard workflows, but they don't carry over every Standard-only capability, and this is one of them. The fix is the same Http pattern this project already uses elsewhere: POST straight to the target workflow's own trigger URL.

It works — both branches

This run took the default (general) branch: ReqTask → Classify_Task (808 ms) → Route_By_Task_Type → Dispatch_To_GeneralAgent (7.9 s) → Response_General (132 ms), succeeded in 10 seconds total. The Case_Math branch — Dispatch_To_BODMASAgent and Response_Math — is greyed out and dashed, because the Switch only runs the branch that matches.

The math branch works too, tested separately:

Math: (12 + 8) * 3 - 5 / 5 → classified math (confidence 1.0) → dispatched to BodmasAgent → "Answer: 59". Correct.
General: Why is the sky blue? → classified general (confidence 1.0) → dispatched to GeneralAgent → a real explanation of Rayleigh scattering.

Conclusion

Jev's typed answers turned out to be useful for more than one thing in Logic Apps: first as a triage step that feeds straight into @if branches with no parsing in between, then as the classifier behind a router that picks which existing agent handles a task. Both ran as real workflows against the real API, not as a sketch — the triage run and the router run shown above are both actual, successful executions in Logic Apps Automation.

The one platform gap worth remembering: the built-in "call workflow in this app" action doesn't work there, even though Automation runs on the same Standard engine. A plain Http call to the target workflow's own trigger URL is the reliable way to dispatch between workflows in an Automation app today.

Logic Apps Automation runs on Container Apps: what the portal doesn't tell you

Daniel Jonathan — Mon, 05 Oct 2026 16:25:26 +0000

Logic Apps Automation is in preview. This post explains how an automation app gets created in a managed environment, what that creates underneath, and how its versions and scaling work. I created a project and two apps in UK South to check this against Azure's resources.

The short version

You create a project, then add apps to it. Each app becomes its own Azure Container App.
Every change to an app's revision creates a new version. The active version takes the traffic.
Each app has its own scale settings, so each scales on its own rules. The docs for Container Apps describe this design. I haven't measured it on Automation yet.
The runtime is a tagged image on Microsoft Container Registry. You choose the tag in the portal, or point at a custom image.

How you create an app

Microsoft's project quickstart covers creating a project, and the application quickstart covers creating an app from the Apps page.

Create a project. Azure creates a resource of type Microsoft.Logic/automationProjects in the resource group you choose. In my case that was la-auto-rg in UK South.
Create an app in the project. The app is a Microsoft.Logic/automationProjects/applications resource. It takes about 1.5 minutes to go from Provisioning to Succeeded, which matches the docs' "a minute or two".
Add workflows. Adding a workflow to the app changes it, so it creates a new version.

The project resource has no plan or networking properties of its own. The docs say a project has "its own compute, networking, security, and governance," but they don't say where that compute is.

The portal and the docs use different names for the same thing. The docs say "project", while the portal's breadcrumb reads Environment > App > Workflow. The Azure portal shows the project as Automation Environment, and its blade lists the apps. The Azure portal also gives it Properties, Locks, Alerts, Metrics and Logs, so you can monitor and lock it like any other Azure resource.

Each app becomes a Container App

The app's appResourceId points to a Container App, not to a Standard site on an App Service Plan:

Microsoft.App/containerapps/autoapp-f9e90f8b1cb2      (hello-world)
Microsoft.App/containerapps/autoapp-234077aeb7bd      (my2-app)
  resource group: la-auto-demo-rg-625cf32
  subscription:   30a69ef7… (not the project's subscription)

Each app gets its own Container App, with its own name and managed identity. Both container apps are in the same resource group, la-auto-demo-rg-625cf32, which is in a subscription other than the project's. I read this from the two resource IDs. I can't open that subscription to see what else is in it.

The overview compares an application to a Standard logic app.

Marczak compares the visual designers of Automation and Standard, and finds the UI different but the options mostly the same. His hosting comparison describes Automation as Microsoft-managed hosting capacity, against customer-provisioned capacity for Standard. InfoQ's coverage says each project gets an isolated compute boundary, and presents that as a current feature.

Versions are revisions

Each app's Container App keeps its versions as revisions. A change to a revision's scale rules or image creates a new revision, and the old revision stays in place, so you can roll back by moving traffic (Container Apps scaling docs). Not every setting creates a revision. The revision change types page lists which ones do.

In the app's Configuration tab, the portal hides zero-replica revisions by default. Select Showing all revisions to see them all. hello-world has 14 revisions, and the active one is autoapp-f9e90f8b1cb2--0000013.

The first revision has a random suffix, cdkde5s. The later ones are numbered from 0000001, and every one uses the stable04 image.

Each app has its own scale settings

The Configuration tab sets each app's scale limits and timing:

Setting	Value
Minimum replicas	0
Maximum replicas	10
Cooldown period	300 seconds
Polling interval	30 seconds

In Container Apps, scale rules are set per revision, so each app's rules apply only to its own revisions. Each app here has its own Container App, so it should scale independently. Microsoft's comparison page says Automation's compute "scales to zero", and these settings are what control that.

I tested the scaling with 15 parallel requests to each app, one app at a time:

hello-world (agent workflow): all 15 returned 200, taking 75 to 102 seconds each. Its replicas went from 2/2 to 9/9, out of a maximum of 10.
my2-app (a 9-second workflow): all 15 returned 200 in about 9 seconds each. Its replicas stayed at 2/2.

Runtime version

The app's Configuration tab lists the runtime versions. Each one is a tagged image on Microsoft Container Registry under azurelogicapps/otto-base:

Version	Image	Status
`stable04`	`mcr.microsoft.com/azurelogicapps/otto-base:stable04`	Current
`1.211.3563.1`	`mcr.microsoft.com/azurelogicapps/otto-base:1.211.3563.1`	Available
`1.211.3557.2`	`mcr.microsoft.com/azurelogicapps/otto-base:1.211.3557.2`	Available
`1.211.3541.4`	`mcr.microsoft.com/azurelogicapps/otto-base:1.211.3541.4`	Available
Custom image	Any full `registry/repository:tag` reference	Available

The registry also has stable05, latest and validation, which the portal doesn't list. stable05 is newer than stable04. I haven't tested those three. The portal doesn't check custom images, so confirm the tag exists on MCR first.

A quick check that it runs

I built a small BODMAS agent in the automation designer, with an arithmeticmcp tool on gpt-5-mini. It solved (2 ^ 3) + 10 through the app's HTTP trigger, with HTTP 200 and the answer 18.

Most of the time goes to the model, not the tool. The two MCP tool calls took 835 ms and 494 ms. Each of the three iterations took 3.3 to 4.8 seconds. When you measure cold start, measure it apart from model latency.

Analytics: hello-world, last 24 hours

The app's Analytics tab reports these figures for the last 24 hours:

Metric	Value
Total runs	44, none in progress
Succeeded	41
Failed	3
Success rate	93.2%
Run latency	p50 42.0 s, p95 1 min 31 s, p99 1 min 32 s

The failures show as one spike on the Execution trends chart, at about 12 PM on the chart's time axis. The chart doesn't state its time zone, so I haven't matched the spike to a specific run. The 44 runs include my load tests and agent test runs, so these totals mix test and non-test traffic. The 60-run batch ran on a different app, so it isn't counted here. The summary cards may lag the chart, which shows more activity than the 44 runs suggest.

What the docs don't cover

The docs state that the compute is dedicated and scales to zero. They don't cover:

Which Container Apps back each app, and the resource group and subscription they sit in.
How long a cold start takes, and how long an idle app takes to scale to zero.
Revisions, traffic splitting, and the fact that the portal hides zero-replica revisions.
Runtime image names, tags and how to choose one.
The managed identities on the project and app.

Securing Shared API Connections in Azure Logic Apps Standard with Access Policies

Daniel Jonathan — Tue, 14 Jul 2026 05:55:32 +0000

The Problem

In an enterprise integration platform built on Azure Logic Apps Standard, you will almost always end up with multiple Logic Apps in the same resource group — each handling a different integration domain. It is also common to share infrastructure: a single Office 365 managed connection, a single on-premises data gateway connection, or a set of SFTP connections that several Logic Apps legitimately need.

This creates two design tensions:

Security: You do not want Logic App A to be able to use a managed connection intended only for Logic App B.
Operability: You do not want to provision a separate copy of every connection for every Logic App — that duplicates infrastructure and doubles your maintenance burden.

The answer is API Connection Access Policies combined with Managed Identity. You provision each managed connection once, shared, and then control which Logic App can authenticate to it at the ARM level — not at the network or key level.

Background: How Managed API Connections Work in Logic Apps Standard

Logic Apps Standard uses two kinds of connections:

Type	Example	Authentication
Managed API connection (`Microsoft.Web/connections`)	Office 365, SFTP, on-premises filesystem	OAuth / Managed Identity via ARM
Service provider connection (built-in)	Service Bus, Azure Blob, FTP	App settings (connection string or credential)

This article focuses on managed API connections. These are full ARM resources in your resource group. When a Logic App calls a managed connector at runtime, it presents the Managed Identity token of the Logic App app service and ARM validates whether that identity is authorised to use that specific connection. This is controlled by an access policy — a child resource of Microsoft.Web/connections.

If no access policy exists for the calling identity, the connection call fails at runtime even if the connection itself is healthy.

The Pattern: One Connection, Multiple Logic Apps, Granular Access

Architecture Overview

Resource Group
│
├── office365-conn          (Microsoft.Web/connections)
│   └── accessPolicies/
│       └── policy-logicapp-billing    ← only billing LA can call this
│
├── sftp-partner-conn       (Microsoft.Web/connections)
│   └── accessPolicies/
│       ├── policy-logicapp-inbound    ← inbound LA can call this
│       └── policy-logicapp-outbound   ← outbound LA can call this
│
├── logicapp-billing        (Microsoft.Web/sites, kind: workflowApp)
│   └── System-assigned identity: xxxxxxxx
│
├── logicapp-inbound        (Microsoft.Web/sites, kind: workflowApp)
│   └── System-assigned identity: yyyyyyyy
│
└── logicapp-outbound       (Microsoft.Web/sites, kind: workflowApp)
    └── System-assigned identity: zzzzzzzz

Key points:

office365-conn is shared infrastructure — provisioned once.
sftp-partner-conn is also shared but accessible by two Logic Apps.
Each Logic App has its own system-assigned Managed Identity.
Access policies tie a specific identity to a specific connection. The billing Logic App cannot call the SFTP connection because there is no access policy for it on that connection.

Provisioning Connections (Shared Infrastructure)

Connections are provisioned via Bicep and deployed once, idempotently. Because multiple Logic Apps may need the same connection, this step is decoupled from individual Logic App deployments — it runs as a shared infrastructure step.

resource office365Conn 'Microsoft.Web/connections@2016-06-01' = {
  name: 'office365-conn'
  location: location
  properties: {
    displayName: 'office365-conn'
    api: {
      id: subscriptionResourceId('Microsoft.Web/locations/managedApis', location, 'office365')
    }
    parameterValues: {
      // credentials injected from pipeline variable group
    }
  }
}

All connections in the platform are provisioned in a single Bicep deployment with --mode Incremental — meaning re-running it is safe and does not disrupt existing connections or their existing access policies.

Assigning Access Policies Per Logic App

This is the key step that enforces isolation. Each Logic App deployment pipeline runs the following sequence as part of its deployment.

Step 1 — Fetch the Logic App's Managed Identity

The Logic App must be provisioned first so that Azure has assigned it a system-assigned Managed Identity. Because the identity may take a few seconds to propagate after provisioning, the pipeline polls with retries:

$maxAttempts = 10
$delaySeconds = 15
$laPrincipal = $null

for ($i = 1; $i -le $maxAttempts; $i++) {
  $laPrincipal = az logicapp show `
      -g $resourceGroup `
      --name $logicAppName `
      --query identity.principalId `
      --output tsv

  if (-not [string]::IsNullOrWhiteSpace($laPrincipal)) { break }

  Write-Host "Attempt $i/$maxAttempts — identity not yet available, retrying in ${delaySeconds}s..."
  Start-Sleep -Seconds $delaySeconds
}

if ([string]::IsNullOrWhiteSpace($laPrincipal)) {
  Write-Error "Managed identity did not become available after $($maxAttempts * $delaySeconds)s."
  exit 1
}

This principal ID is the object ID of the Logic App's Managed Identity in Azure AD. It is passed forward as a pipeline variable for the next step.

Step 2 — Prepare the Access Policy Body

The access policy document is stored as a template file, with the principal ID and tenant ID injected by the pipeline's token replacement task:

{
  "type": "Microsoft.Web/connections/accessPolicy",
  "location": "#{var_location}#",
  "properties": {
    "principal": {
      "type": "ActiveDirectory",
      "identity": {
        "objectId": "#{laPrincipal}#",
        "tenantId": "#{var_tenant}#"
      }
    }
  }
}

Tokens (#{...}#) are replaced at pipeline runtime before the file is used in the PUT call.

Step 3 — PUT the Policy on the Relevant Connections

Two approaches exist depending on how connections are named in the resource group.

Approach A — All connections

Assign the policy to every Microsoft.Web/connections in the resource group. This works well when all connections in the resource group belong to a single Logic App's domain:

$connections = az resource list `
    -g $resourceGroup `
    --resource-type Microsoft.Web/connections | ConvertFrom-Json

$maxAttempts = 10
$delaySeconds = 15

foreach ($conn in $connections) {
  $url = "https://management.azure.com/subscriptions/$subscriptionId" +
         "/resourceGroups/$resourceGroup" +
         "/providers/Microsoft.Web/connections/$($conn.name)" +
         "/accessPolicies/policy-$logicAppName" +
         "?api-version=2018-07-01-preview"

  # Idempotency: skip if the correct policy already exists
  $existingPrincipal = az rest --method get --url $url `
      --query "properties.principal.identity.objectId" --output tsv 2>&1
  if ($existingPrincipal -eq $laPrincipal) {
    Write-Host "Policy already correct on $($conn.name), skipping."
    continue
  }

  # ARM returns HTTP 500 if the same principal already has a policy under a different name.
  # Delete any stale policy for this principal before creating the new one.
  $staleIds = az rest --method get `
      --url "https://management.azure.com/subscriptions/$subscriptionId/resourceGroups/$resourceGroup/providers/Microsoft.Web/connections/$($conn.name)/accessPolicies?api-version=2018-07-01-preview" `
      --query "value[?properties.principal.identity.objectId=='$laPrincipal'].id" `
      --output tsv 2>&1

  $deleted = $false
  foreach ($policyId in ($staleIds -split "`n" | Where-Object { $_ -ne '' })) {
    az rest --method delete `
        --url "https://management.azure.com${policyId}?api-version=2018-07-01-preview" 2>&1 | Out-Null
    Write-Host "Deleted stale policy on $($conn.name): $policyId"
    $deleted = $true
  }
  if ($deleted) { Start-Sleep -Seconds 2 }  # Allow ARM to process deletion

  # PUT the new policy with retry
  $success = $false
  for ($i = 1; $i -le $maxAttempts; $i++) {
    $result = az rest --method put --url $url --body @accessPolicyProperties.json 2>&1
    if ($LASTEXITCODE -eq 0) { $success = $true; break }
    Write-Host "Attempt $i/$maxAttempts for $($conn.name) failed: $result"
    if ($i -lt $maxAttempts) { Start-Sleep -Seconds $delaySeconds }
  }

  if (-not $success) {
    Write-Error "Failed to set access policy on $($conn.name) after $maxAttempts attempts."
    exit 1
  }
}

Approach B — Prefix filtering + explicit shared connections

When the resource group contains connections for multiple Logic Apps — named with a prefix convention such as lawf-io-*, lawf-order-* — you can filter the connection list by prefix. This avoids assigning access policies across unrelated connections.

# Only the connections owned by this Logic App
$connections = az resource list `
    -g $resourceGroup `
    --resource-type Microsoft.Web/connections `
    --query "[?starts_with(name, 'lawf-io-')]" | ConvertFrom-Json

foreach ($conn in $connections) {
  # ... same PUT logic as Approach A
}

Some connections may be shared across Logic Apps and not carry any particular prefix (e.g. office365-conn, onpremfs-conn). These are passed in as an explicit parameter — either from the pipeline call or from a variable group — and processed separately:

# sharedConnections: space or comma-separated list from pipeline parameter or variable group
$sharedParam = $sharedConnectionsParam.Trim()
if ([string]::IsNullOrWhiteSpace($sharedParam) -or $sharedParam -eq 'none') {
  $sharedParam = $env:VAR_SHARED_CONNECTIONS.Trim()
}

foreach ($connName in ($sharedParam -split '[,\s]+' | Where-Object { $_ -ne '' })) {
  $exists = az resource list `
      -g $resourceGroup `
      --resource-type Microsoft.Web/connections `
      --query "[?name=='$connName'].name" -o tsv 2>&1

  if (-not $exists) {
    Write-Host "Shared connection '$connName' not found in $resourceGroup, skipping."
    continue
  }

  $url = "https://management.azure.com/subscriptions/$subscriptionId" +
         "/resourceGroups/$resourceGroup" +
         "/providers/Microsoft.Web/connections/$connName" +
         "/accessPolicies/policy-$logicAppName" +
         "?api-version=2018-07-01-preview"

  az rest --method put --url $url --body @accessPolicyProperties.json
}

This approach keeps the default access surface minimal — only named shared connections are granted, not everything in the resource group.

Generating connections.json

Logic Apps Standard requires a connections.json file alongside the workflow definitions. This file maps connection reference names (used in workflow.json) to the actual ARM resource IDs and live runtime URLs of the managed connections.

Rather than maintaining this file manually — which would require hard-coded subscription IDs and environment-specific runtime URLs — the pipeline generates it dynamically from Azure at deploy time using a script.

What the script does

The script queries the resource group for:

Managed API connections (Microsoft.Web/connections) — reads each connection's ARM properties to get its api.id, resource id, and connectionRuntimeUrl. The connectionRuntimeUrl is the endpoint Logic Apps Standard uses at runtime to route calls through the managed connector; it is only available from ARM after the connection is provisioned.
Function app connections (Microsoft.Web/sites with HTTP-triggered functions, when -withFunctions is passed) — reads each function app, lists its HTTP-triggered functions, and fetches the host key used for authentication.

Function Get-ApiConnections {
  $apiConnections = @{}

  $resources = Get-AzResource -ResourceGroupName $resourceGroup -ResourceType Microsoft.Web/connections

  # Optional: filter by name prefix when multiple Logic Apps share the same resource group
  if ($connectionNamePrefix) {
    $resources = $resources | Where-Object { $_.Name.StartsWith($connectionNamePrefix) }
  }

  $resources | ForEach-Object {
    $name = $_.Name
    $connectionResource = Get-AzResource -ResourceId $_.Id

    $apiConnections[$name] = @{
      "api"                  = @{ "id" = $connectionResource.Properties.api.id }
      "connection"           = @{ "id" = $_.Id.ToLower() }
      "connectionRuntimeUrl" = $connectionResource.Properties.connectionRuntimeUrl
      "authentication"       = @{ "type" = "ManagedServiceIdentity" }
    }
  }

  return $apiConnections
}

Function Get-FunctionConnections {
  $functionConnections = @{}

  $sites = Get-AzResource -ResourceGroupName $resourceGroup -ResourceType Microsoft.Web/sites
  foreach ($site in $sites) {
    # Enumerate HTTP-triggered functions via ARM (no func CLI required)
    $funcList = Invoke-AzRestMethod `
        -Path "$($site.Id)/functions?api-version=2022-03-01" -Method GET
    if ($funcList.StatusCode -ne 200) { continue }

    $functions = ($funcList.Content | ConvertFrom-Json).value |
                 Where-Object { $_.properties.invoke_url_template }
    if (-not $functions) { continue }

    # Get the host key for authentication
    $keysResp = Invoke-AzRestMethod `
        -Path "$($site.Id)/host/default/listkeys?api-version=2022-03-01" -Method POST -Payload '{}'
    $keysObj  = $keysResp.Content | ConvertFrom-Json
    $hostKey  = $keysObj.functionKeys.default ?? $keysObj.masterKey

    foreach ($func in $functions) {
      $funcName = $func.id.Split('/')[-1]
      $functionConnections[$funcName] = @{
        "function"       = @{ "id" = $func.id }
        "triggerUrl"     = $func.properties.invoke_url_template
        "authentication" = @{ "type" = "QueryString"; "name" = "Code"; "value" = $hostKey }
        "displayName"    = $funcName
      }
    }
  }

  return $functionConnections
}

Output structure

The script writes a compressed single-line JSON that the pipeline then uses directly:

{
  "managedApiConnections": {
    "office365-conn": {
      "api": { "id": "/subscriptions/.../managedApis/office365" },
      "connection": { "id": "/subscriptions/.../connections/office365-conn" },
      "connectionRuntimeUrl": "https://xxxxx.common.logic-westeurope.azure-apihub.net/apim/office365/yyy",
      "authentication": { "type": "ManagedServiceIdentity" }
    },
    "sftp-partner-conn": {
      "api": { "id": "/subscriptions/.../managedApis/sftpwithssh" },
      "connection": { "id": "/subscriptions/.../connections/sftp-partner-conn" },
      "connectionRuntimeUrl": "https://xxxxx.common.logic-westeurope.azure-apihub.net/apim/sftpwithssh/zzz",
      "authentication": { "type": "ManagedServiceIdentity" }
    }
  },
  "functionConnections": {
    "ParseDocument": {
      "function": { "id": "/subscriptions/.../functions/ParseDocument" },
      "triggerUrl": "https://my-fa.azurewebsites.net/api/parsedocument",
      "authentication": { "type": "QueryString", "name": "Code", "value": "<host-key>" },
      "displayName": "ParseDocument"
    }
  }
}

Calling the script in the pipeline

Simple (all connections in the RG):

.\Generate-Connections.ps1 `
    -resourceGroup $resourceGroup `
    -outputLocation connections.json `
    -withFunctions

With prefix filtering and shared connections (Approach B):

.\Generate-Connections.ps1 `
    -resourceGroup $resourceGroup `
    -outputLocation connections.json `
    -connectionNamePrefix "lawf-io-" `
    -withFunctions
# Shared connections not matching the prefix are handled separately
# by passing -sharedConnectionNames to a modified version of the script,
# or by running the script a second time against a second resource group.

Key constraint: The key in managedApiConnections is the ARM resource name of the connection. This must exactly match the referenceName used in workflow.json. If the resource is named office365-conn but the workflow references office365, the runtime connection lookup will fail silently.

Injecting service provider connections

Managed API connections are generated from Azure. Service provider connections (built-in) are not ARM resources and cannot be queried — they are injected into the generated file by the pipeline via sed before it is deployed:

# Inject serviceProviderConnections block into the generated connections.json
sed -i 's/"functionConnections"/"serviceProviderConnections": {
  "spc-servicebus": {
    "displayName": "spc-servicebus",
    "parameterValues": {
      "connectionString": "@appsetting('\''serviceBusConnection'\'')"
    },
    "serviceProvider": { "id": "\/serviceProviders\/serviceBus" }
  }
},"functionConnections"/g' connections.json

The final connections.json therefore contains all three sections — managed API connections (from Azure), service provider connections (injected), and function connections (from Azure) — assembled by the pipeline before deploy.

Shared vs. Logic-App-Specific Connections

The pattern supports both types transparently:

Connection type	Provisioning	Access policy
Shared (e.g. Office 365, on-prem gateway)	One Bicep deployment for the whole platform	Each Logic App gets its own named policy
Logic-App-specific (e.g. a partner SFTP only one LA uses)	Still provisioned in the same shared Bicep step	Only the owning Logic App gets a policy

The access policy layer is what enforces the distinction at runtime — there is no need to use separate resource groups or separate ARM deployments.

Service Provider Connections: No Access Policies Needed

Built-in service provider connections (Service Bus, Azure Blob, FTP, etc.) do not create an ARM resource — they are configured entirely inside connections.json using app setting references:

"serviceProviderConnections": {
  "spc-servicebus": {
    "parameterValues": {
      "connectionString": "@appsetting('serviceBusConnection')"
    },
    "serviceProvider": { "id": "/serviceProviders/serviceBus" }
  }
}

The actual connection string is stored as a Logic App app setting, injected by the pipeline at deploy time. No access policy is needed because authentication is handled by the connection string itself — the Logic App owns it directly.

The trade-off: managed API connections give you identity-based, policy-controlled access at the ARM level. Service provider connections are simpler to set up but rely on secrets stored in app settings.

End-to-End Pipeline Flow

1. provisionApps  →  Bicep deploys Logic App + all shared connections (Incremental)
2. provisionConns →  Bicep deploys any missing managed API connections
3. fetchIdentity  →  Poll for Logic App managed identity principal ID
4. injectTokens   →  Replace #{laPrincipal}# and #{var_tenant}# in access policy template
5. assignPolicies →  PUT access policy for this Logic App on each relevant connection
                     (idempotent: skip if correct, delete stale, retry on failure)
6. mergeAppSettings → az webapp config appsettings set (connection strings, keys)
7. generateConns  →  Generate-Connections.ps1 queries ARM → writes connections.json
8. injectSPCs     →  sed injects serviceProviderConnections into connections.json
9. zipDeploy      →  ArchiveFiles + AzureFunctionApp@1 deploys workflow zip to Logic App

Summary

Concern	How it is addressed
Shared connection infrastructure	Single Bicep deployment, `--mode Incremental`, one resource per external system
Logic App isolation	ARM access policy per Logic App identity on each connection
Precise access scoping	Connection prefix filter + explicit shared connection list (Approach B)
Stale policy conflicts	Pipeline detects and removes stale policies before re-assigning, with retries
Dynamic runtime URLs	`connections.json` generated from ARM at deploy time — never committed
Service provider connections	App settings injection + `sed` into generated `connections.json`
Function connections	Discovered from ARM, host key fetched and embedded automatically

The result is a platform where connections are provisioned once, runtime URLs are always current, and each Logic App can only authenticate to the connections it is explicitly authorised to use — enforced at the Azure control plane, not in application code.

Forget Sampling — This One host.json Setting Cuts Logic Apps Telemetry Costs by 80%

Daniel Jonathan — Sun, 10 May 2026 06:12:21 +0000

If you're running Logic Apps Standard with Application Insights enabled, there's a good chance you're paying more than you need to. Getting this right means crossing multiple doc pages, filtering out configurations that silently do nothing, and eventually landing on a setting most people never reach.

I ran a controlled experiment across three configurations over 36 hours to find out exactly what works — and what doesn't. Here's what the data showed.

The Problem

Logic Apps Standard emits a lot of telemetry. Every workflow run, every action, every outbound HTTP call — all of it flows into Application Insights by default. At scale, that adds up fast.

The official docs tell you to look at host.json for telemetry control, but the Logic Apps Standard reference page doesn't enumerate the applicationInsights properties — it defers to the Azure Functions host.json reference. That's actually correct (Logic Apps Standard runs on the Functions v4 host), but it leaves a gap where you're piecing together settings from two different doc pages, community blogs, and Stack Overflow answers.

The Experiment

I set up a Logic Apps Standard instance (logicappshub, West Europe) with a timer workflow firing every 5 minutes. Each run made 7 parallel HTTP calls — a mix of valid endpoints, 404s, 500s, DNS failures, and a call that cascaded into a second stateful workflow. This generated realistic, high-volume telemetry similar to what you'd see in a busy integration environment.

I then ran three phases (compared over equal 9-hour windows):

Phase	Schema	Sampling	Config
1 — Baseline	v1 (default)	Off	Bare `host.json`
2 — Full config	v2	On	Sampling + dependency tracking off
3 — Schema only	v2	Off	v2 schema only, nothing else

All three phases used the same workflow, same infrastructure, same traffic pattern. The only variable was host.json.

The Numbers

Billable ingestion — equal 9-hour windows per phase

To ensure a fair comparison, each phase was queried over an identical 9-hour window:

Phase	Window (UTC)
Phase 1	2026-05-08 20:00 → 2026-05-09 05:00
Phase 2	2026-05-09 10:00 → 2026-05-09 19:00
Phase 3	2026-05-09 22:30 → 2026-05-10 07:30

Data Type	Phase 1 (v1, no sampling)	Phase 2 (v2 + sampling)	Phase 3 (v2, no sampling)
`AppTraces`	0.135 GB	0.004 GB	0.003 GB
`AppDependencies`	0.101 GB	0.000 GB	0.004 GB
`AppMetrics`	0.049 GB	0.010 GB	0.007 GB
`AppRequests`	0.018 GB	0.039 GB	0.039 GB
`AppPerformanceCounters`	0.006 GB	0.004 GB	0.002 GB
`AppExceptions`	0.000 GB	0.001 GB	0.001 GB
Total	0.309 GB	0.058 GB	0.056 GB
vs baseline	—	-81%	-82%

Phase 2 and Phase 3 are essentially identical — 0.058 GB vs 0.056 GB — despite Phase 3 having no sampling at all.

That's the headline finding.

Finding 1: v2 Schema Does Most of the Work

Switching Runtime.ApplicationInsightTelemetryVersion from v1 (the default) to v2 reduced ingestion by ~80% on its own. No sampling required.

v2 is the GA-recommended telemetry schema and emits fewer duplicate rows across the Traces and Requests tables. The difference in practice was dramatic:

Item Type	Phase 1 (v1)	Phase 3 (v2, no sampling)
`traces` per 5-min window	414–2,328	6–12
`dependencies` per 5-min window	452–3,385	28–45

Traces dropped from thousands per window to single digits. Dependencies dropped by two orders of magnitude. Just from a schema flag.

The config:

{
  "extensions": {
    "workflow": {
      "Settings": {
        "Runtime.ApplicationInsightTelemetryVersion": "v2"
      }
    }
  }
}

One setting. No trade-offs. Do this first.

Finding 2: `enableDependencyTracking: false` Eliminates `AppDependencies` Completely

AppDependencies was 33% of total ingestion in Phase 1 (0.101 GB). Phase 3 (v2 schema alone) brought it down to 0.004 GB. Disabling dependency tracking entirely dropped it to zero.

"applicationInsights": {
  "enableDependencyTracking": false
}

The trade-off: You lose all HTTP call detail in App Insights — no URL, no duration, no status code per outbound call. If you need that data for day-to-day monitoring, keep it on. If you're only looking at run-level success/failure, turn it off.

Important: This setting must be a sibling of samplingSettings, not nested inside it. Several community blog posts (AzureTechInsider among them) show it nested inside samplingSettings. The Functions host silently ignores unknown properties inside samplingSettings, so the setting does nothing — which is why you see "I disabled dependency tracking and it didn't work" reports. The correct placement:

"applicationInsights": {
  "samplingSettings": { "isEnabled": true, "maxTelemetryItemsPerSecond": 5 },
  "enableDependencyTracking": false   // ← sibling, not inside samplingSettings
}

Finding 3: Sampling Adds Only Marginal Extra Reduction

Phase 2 (v2 + sampling) vs Phase 3 (v2, no sampling): 0.058 GB vs 0.056 GB. A difference of just 0.002 GB — essentially the same cost.

Sampling does reduce AppTraces and AppRequests slightly further, but the cost is real: detailed action-level logs get dropped. You'll know a workflow run failed, but you may not know which action failed or what the input was. That makes root cause analysis harder.

If you do enable sampling, always exclude exceptions:

"samplingSettings": {
  "isEnabled": true,
  "maxTelemetryItemsPerSecond": 5,
  "excludedTypes": "Exception"
}

This ensures errors are never dropped. We confirmed in Phase 2 that exceptions bypass sampling correctly — 43–77 exceptions per 5-minute window were captured consistently despite the sampling cap.

Warning: Don't touch initialSamplingPercentage, minSamplingPercentage, or maxSamplingPercentage unless you know what you're doing. A community report (Azure/logicapps Discussion #682) showed setting those values together caused all telemetry to vanish from App Insights entirely. Stick to maxTelemetryItemsPerSecond and excludedTypes.

Finding 4: Some Telemetry Bypasses Sampling — By Design

AppRequests actually increased as a percentage of total ingestion after enabling sampling. In Phase 1 it was 6% of total; in Phase 2 it was 67%.

This isn't a bug. Logic Apps Standard emits certain records — Host.Results for /flowruns, Host.Workflow for /flowhistories — directly from the Logic Apps extension rather than through the Functions host's logger pipeline. Those records carry no LogLevel property and are not subject to samplingSettings or logLevel filters.

Treat samplingSettings as controlling ~80–90% of telemetry, not 100%. There's currently no host.json knob to suppress these extension-emitted records.

Finding 5: `enablePerformanceCountersCollection: false` Had Minimal Effect

We expected this to eliminate AppPerformanceCounters entirely. Instead it went from 0.007 GB → 0.004 GB — a real but marginal reduction. Not a significant cost lever in this environment. Your mileage may vary depending on scale.

Finding 6: Disabling Dependency Tracking Changes How Errors Appear

In Phase 1, failed HTTP calls (404, 500, DNS failures) appeared as failed dependencies. In Phase 2 with dependency tracking disabled, those same failures appeared as exceptions instead.

This is worth knowing before you make the change. If you have dashboards or alerts based on AppDependencies failure rates, those will need updating. The failure data is still there — it's just in AppExceptions now.

The Right host.json — Ordered by Impact

Apply these changes one at a time so you can measure each one's effect.

Step 1 — Switch to v2 schema (do this first, always)

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  },
  "extensions": {
    "workflow": {
      "Settings": {
        "Runtime.ApplicationInsightTelemetryVersion": "v2"
      }
    }
  }
}

Expected result: ~80% ingestion reduction. No troubleshooting impact.

Step 2 — Disable dependency tracking if you don't need per-call detail

"applicationInsights": {
  "enableDependencyTracking": false
}

Expected result: AppDependencies drops to zero. Trade-off: no HTTP call detail.

Step 3 — Add sampling only if further reduction is needed

"applicationInsights": {
  "samplingSettings": {
    "isEnabled": true,
    "maxTelemetryItemsPerSecond": 5,
    "excludedTypes": "Exception"
  },
  "enableDependencyTracking": false,
  "enablePerformanceCountersCollection": false,
  "enableLiveMetrics": true
}

Expected result: additional ~10% reduction. Trade-off: action-level traces may be dropped.

The complete cost-control host.json

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  },
  "logging": {
    "logLevel": {
      "default": "Warning",
      "Workflow.Host": "Warning",
      "Workflow.Jobs": "Warning",
      "Workflow.Runtime": "Warning",
      "Workflow.Operations.Runs": "Information",
      "Workflow.Operations.Actions": "Information",
      "Workflow.Operations.Triggers": "Information",
      "Host.Aggregator": "Error"
    },
    "applicationInsights": {
      "samplingSettings": {
        "isEnabled": true,
        "maxTelemetryItemsPerSecond": 5,
        "excludedTypes": "Exception"
      },
      "enableDependencyTracking": false,
      "enablePerformanceCountersCollection": false,
      "enableLiveMetrics": true
    }
  },
  "extensions": {
    "workflow": {
      "Settings": {
        "Runtime.ApplicationInsightTelemetryVersion": "v2"
      }
    }
  }
}

Troubleshooting Without Redeployment

When you need full telemetry to debug an issue, disable sampling instantly via an app setting — no redeployment needed:

AzureFunctionsJobHost__logging__applicationInsights__samplingSettings__isEnabled = false

Set it in the Azure portal, reproduce the issue, capture what you need, then remove it. The setting overrides host.json at runtime because Logic Apps Standard uses the standard ASP.NET Core configuration system where environment variables take precedence.

Now What — 3 Queries for the Trade-offs

1. After disabling dependency tracking, find failed outbound calls in AppExceptions

Failed HTTP calls (404, 500, DNS errors) move from AppDependencies to AppExceptions when enableDependencyTracking: false. Update any existing failure alerts to look here instead:

exceptions
| where timestamp > ago(1h)
| project timestamp, outerMessage, type, operation_Id
| order by timestamp desc

2. Confirm failed runs are always captured despite sampling

Run-level records bypass samplingSettings — you should always see failed runs even with aggressive sampling on:

requests
| where timestamp > ago(1h)
| where success == false
| project timestamp, name, resultCode, duration, operation_Id
| order by timestamp desc

3. Measure your actual cost reduction (Log Analytics)

Allow 1-2 hours after a config change for the Usage table to aggregate, then compare before and after:

Usage
| where TimeGenerated > ago(6h)
| where IsBillable == true
| summarize IngestedGB = round(sum(Quantity) / 1024, 3) by DataType
| order by IngestedGB desc

Summary

Change	Expected reduction	Risk
Switch to v2 schema	~80%	None
`enableDependencyTracking: false`	Eliminates `AppDependencies`	Lose per-call HTTP detail
Add adaptive sampling	Additional ~10%	May lose action trace detail

The surprise finding: adaptive sampling is the least impactful of the three. Most teams should stop at Step 1 (v2 schema) and only go further if their bill still warrants it. v2 schema alone cuts 80% of ingestion with zero observability trade-off — that's the change to make today.

Logic Apps Agent Loop + MCP: Two Bugs Worth Knowing About

Daniel Jonathan — Sun, 03 May 2026 22:35:02 +0000

I spent the long weekend pushing Logic Apps MCP server capabilities further than I had before — and hit two bugs worth documenting. Both are filed. If you're building in this space, save yourself the debugging time.

Context

If you've been following along, the MCP server and BODMAS Agent are covered in the previous posts. This post is just about what broke when I wired them together.

Bug 1 — Intermittent duplicate key error at tool registration

What happens

The Agent Loop fails with a BadRequest before making a single MCP call:

HTTP request failed: 'An item with the same key has already been added. Key: {tool_name}'.

Both the tool names and the MCP server names are unique in the workflow definition — no duplicates anywhere in the JSON.

What makes it particularly frustrating to diagnose

It is intermittent. Some runs fail, others succeed with identical configuration and identical input. No changes between a failing and a succeeding run — same workflow, same expression, same everything.

Load test

I ran three test patterns across 60 total requests — all using expressions covering power, square root, and division.

Test	Requests	Succeeded	Failed	Failure Rate
Fully parallel	30	17	13	~43%
Pairs of 2 (10s gap)	20	14	6	~30%
Sequential (15s gap)	10	7	3	~30%
Total	60	38	22	~37%

Failure rate drops when concurrency is reduced but never goes away — even fully sequential calls at 15-second spacing still hit ~30%.

View from Dev Tools:

Resubmitting the failed runs from the portal confirms the intermittent nature — the same expression that failed goes through successfully after one or more resubmits, with no changes to the workflow or inputs.

What you can't do

The Agent action has a default retry policy, but it does not help here. A BadRequest (400) is not treated as a transient error — the retry policy targets server-side failures (5xx), not client errors. So even with retries configured, the duplicate key error causes an immediate terminal failure. There is no clean in-workflow workaround.

Bug 2 — MCP Connector does not support OAuth

What happens

Both the MCP server and the MCP client are Logic Apps Standard. When OAuth is configured on the MCP server side, the workflow doesn't trigger at all — it never reaches the Logic App. The connection gets corrupted at design time with the OAuth setup, and no run is created.

Tools don't load but you can save the workflow.

You get a 502 bad gateway error when you push a request.

The same endpoint called directly from Postman with a valid bearer token works fine.

Why it matters

To get the Agent Loop working, the MCP server has to run with either anonymous authentication or key-based authentication. OAuth simply does not work with the built-in MCP client connector.

Current state

Both issues are filed on the Logic Apps GitHub repo:

Agent Loop: "An item with the same key has already been added" when using McpClientTool

The issue covers both bugs with full workflow JSON, reproduction steps, and screenshots. If you've hit either of these, add a reaction or comment — the more signal on the issue, the better.

What works in the meantime

Set "type": "anonymous" in the McpServerEndpoints authentication block in host.json — removes the OAuth blocker for dev and demo use
Accept the intermittent failure rate on the Agent Loop and re-trigger manually when it hits — not a fix, but the success rate is high enough to keep building and testing

Both issues are filed. If you hit either of them, the GitHub issue is the right place to add signal.

Running Multiple MCP Servers with Azure Logic Apps

Daniel Jonathan — Fri, 01 May 2026 23:31:46 +0000

Model Context Protocol (MCP) has become the standard way to expose tools to AI agents.

With Azure Logic Apps, you can create and run multiple MCP servers and let an agent consume them together — cleanly and modularly.

In this post, we'll build:

A Basic Arithmetic MCP server
An Extended Arithmetic MCP server
And connect an agent to both

The Scenario

We'll create two MCP servers using Logic App workflows and expose them to an agent.
Both servers share Anonymous authentication.

Step 1 — Create and Group MCP Workflows in Logic Apps

Each operation is implemented as a Logic App workflow and exposed as an MCP tool.

Each workflow:

Accepts inputs (typically two numbers and an operation)
Executes the required logic
Returns a structured response

You then group these workflows into MCP servers:

Basic Arithmetic Server

Add
Subtract
Multiply
Divide

Extended Arithmetic Server

Power
Square Root
Modulo

How This Is Stored (mcpservers.json)

Once workflows are grouped into MCP servers, the configuration is automatically persisted in the mcpservers.json file.

This file contains:

MCP server definitions
Workflow (tool) mappings

💡 Key idea: What you define as MCP servers (grouped workflows) is what gets written to mcpservers.json — automatically.

MCP Server Endpoints

Once registered, each MCP server is reachable at a predictable URL following this pattern:

https://<your-logic-app>.azurewebsites.net/api/mcpservers/<ServerName>/mcp

For example:

Basic server → /api/mcpservers/BasicArithmetic/mcp
Extended server → /api/mcpservers/ExtendedArithmetic/mcp

💡 The server name in the URL matches exactly what you defined when grouping your workflows — no extra configuration needed.

Step 2 — Connect the Agent to Both Servers

The agent connects to both MCP servers using separate MCP client connections.

This allows the agent to:

Use basic operations from one server
Use advanced operations from another

👉 Clean separation — no need for a single large service.

Step 3 — Execution Result

When the agent runs, it invokes operations across both MCP servers.

The result:

Multiple MCP servers used seamlessly
Operations resolved correctly
Agent behaves as if using a unified toolset

Why This Matters

Running multiple MCP servers from a single Logic Apps instance gives you separation of concerns, modular extensibility, and independent scalability — without changing your agent design.

Key Takeaway

Workflows group into MCP servers, each exposed via a predictable endpoint
Configuration is automatically managed in mcpservers.json
Agents can connect to multiple MCP servers simultaneously — no extra wiring required

This pattern enables a modular, composable tool ecosystem for AI agents using Azure Logic Apps.

Logic Apps Local Dev Tools — Now with ACA and Azure Sign-in Support

Daniel Jonathan — Thu, 30 Apr 2026 08:16:14 +0000

The Logic Apps Local Dev Tools VS Code extension started as a local dev tool — connect to a Logic Apps container running via Docker and browse run history without leaving the editor.

This update adds two new connection types: ACA support via direct FQDN and Azure Sign-in for cloud-hosted Logic Apps Standard. If you used the original version for local Docker, everything still works — you just have more options now.

One dashboard, three connection types

The extension now supports three types of Logic Apps instances in a single panel:

Runtime — direct HTTP endpoint, works for local Docker (localhost:7074) or an ACA FQDN
AZ-LA — Azure Sign-in, connects to Logic Apps Standard via your subscription
EasyAuth — ACA endpoint secured with Azure AD ingress auth; the extension handles the Bearer token using a Service Principal

All instances appear side by side in the Logic Apps Instances view:

Managing connections

Click Connections to add, edit, or remove any instance. Each connection has a label, type, and endpoint or Azure resource identifier:

Runtime connections take a plain URL — ACA FQDN or localhost for Docker
AZ-LA connections use Azure Sign-in: select subscription, resource group, and Logic App — no endpoint URL needed
EasyAuth connections take the ACA FQDN plus a Service Principal (client ID + secret) — the extension acquires a Bearer token automatically on each request

EasyAuth — connecting to a protected ACA endpoint

If your Logic Apps container on ACA has Azure AD ingress auth enabled (unauthenticatedClientAction: Return401), the Runtime type won't work — requests without a Bearer token get a 401 before reaching the container.

Use EasyAuth instead: provide the ACA FQDN and a Service Principal with access to the app registration. The extension acquires a token via client credentials flow and attaches it to every request. SAS payload fetches (run history inputs/outputs) pass through the ACA platform exemption for /runtime/webhooks/* without needing a token.

When to use each type:

Scenario	Connection type
Local Docker (`localhost`)	Runtime
ACA container, no auth	Runtime
ACA container, ACA Easy Auth enabled	EasyAuth
Cloud Logic Apps Standard (App Service)	AZ-LA

ACA workflow view

Clicking View Workflows on an ACA instance shows the full workflow list with kind, status, health, and trigger. From here you can get the callback URL or jump straight into run history:

The run history panel works the same as local — full input/output per action, no Azure Portal needed.

Install from the VS Code Marketplace:
Logic Apps Local Dev Tools

For the original local dev walkthrough — Docker setup, Azurite, and the design → test loop:
Logic Apps Local Dev Tools — Visual Walkthrough

Host LogicApps as an MCP Server on Azure Container Apps

Daniel Jonathan — Thu, 30 Apr 2026 07:43:25 +0000

Run Logic Apps Standard as an MCP server in a Docker container on Azure Container Apps — then call it from another Logic App using the built-in MCP client connector inside an agent loop.

This post connects two earlier pieces:

MCP server setup: Logic Apps ❤️ MCP — Expose Arithmetic Tools — enabling the /api/mcp endpoint and testing the tools
Running on ACA: Logic Apps Standard on ACA — we take the same MCP server principles and host it as a Docker container on Azure Container Apps

If you haven't read those, here's what's already running before this post starts.

What's already deployed

Seven arithmetic workflows — add, sub, mul, div, mod, pow, sqrt — each an HTTP trigger workflow that takes inputs and returns a result. They're baked into a Docker image and running as a single container on ACA.

Running locally first

Before pushing to ACA you can run the same image locally. docker-compose up starts the Logic Apps runtime on port 7074 backed by Azurite for blob and queue storage. The MCP endpoint is immediately available at:

http://localhost:7074/api/mcp

No auth is needed locally — the "type": "anonymous" setting in host.json covers both local dev and the ACA demo deployment. This is the right place to verify tool schemas, test workflow logic, and confirm the runtime discovers all seven tools before you deploy anything to the cloud.

One block in host.json enables the MCP endpoint:

"workflow": {
  "McpServerEndpoints": {
    "enable": true,
    "authentication": { "type": "anonymous" }
  }
}

The runtime exposes each workflow as an MCP tool automatically. No extra code, no separate service — the container itself is the MCP server, reachable at:

https://la-arithmeticmcp.<env>.westeurope.azurecontainerapps.io/api/mcp

All seven tools are immediately discoverable:

Consuming it from another Logic App

A second Logic App — BODMASAgent — receives a math expression via HTTP and uses an Agent action (Azure OpenAI) to solve it. The agent has one tool available: the MCP server connector pointing at the endpoint above.

When you add the MCP server action inside the Agent loop and connect it to the endpoint, the designer auto-discovers all tools and lets you pick which ones the agent can call:

POST (2 + 3) * 4^2 / 2 and the agent works through BODMAS order on its own, calling one tool per step:

✅ Step 1: (2 + 3) = 5   → wf_arithmetic_add
✅ Step 2: 4² = 16        → wf_arithmetic_pow
✅ Step 3: 5 × 16 = 80    → wf_arithmetic_mul
✅ Step 4: 80 ÷ 2 = 40    → wf_arithmetic_div
✅ Final Answer: 40

No orchestration code in the consuming Logic App. The agent decides the order and arguments; each tool call triggers a real workflow run on the server container and returns the result.

Securing the MCP endpoint on ACA

The host.json above sets "type": "anonymous" — fine for local dev and demos, but for production you want the endpoint protected.

ACA doesn't have App Service Easy Auth built in, but it has its own ingress-level authentication that works the same way: the ACA runtime validates the Azure AD Bearer token before the request reaches the container. The Logic App MCP endpoint stays anonymous internally; ACA acts as the auth gateway.

Setup — two steps:

Create an Azure AD app registration (la-arithmeticmcp-auth) and create a service principal for it in the tenant:

az ad sp create --id <app-id>

Enable ACA auth via ARM REST — do not use az containerapp auth update, it has a known CLI bug that silently strips the first and last character of excludedPaths values, producing invalid config:

az rest --method PUT \
  --url "https://management.azure.com/subscriptions/<sub>/resourceGroups/<rg>/providers/Microsoft.App/containerApps/la-arithmeticmcp/authConfigs/current?api-version=2024-03-01" \
  --body '{
    "properties": {
      "globalValidation": {
        "unauthenticatedClientAction": "Return401",
        "excludedPaths": ["/runtime/webhooks/workflow/scaleUnits/*"]
      },
      "platform": { "enabled": true },
      "identityProviders": {
        "azureActiveDirectory": {
          "registration": {
            "clientId": "<app-id>",
            "openIdIssuer": "https://sts.windows.net/<tenant-id>/"
          },
          "validation": {
            "allowedAudiences": ["api://<app-id>"]
          }
        }
      }
    }
  }'

The excludedPaths entry for scaleUnits/* is required. ACA enforces Bearer token validation on all paths by default — including /runtime/webhooks/*. The scaleUnits subtree hosts SAS-authenticated payload fetch URLs (run inputs/outputs) that the Logic Apps runtime generates per run action. Excluding it lets those requests pass through on SAS params alone.

Do not set WORKFLOWAPP_AAD_CLIENTID or WORKFLOWAPP_AAD_TENANTID on the container. These env vars activate DirectApi Azure AD token validation inside the Logic Apps runtime. Any client in EasyAuth mode sends a Bearer token on every request — including to the SAS-authenticated scaleUnits URLs. When both a Bearer token and SAS params are present on the same request, the runtime rejects with DirectApiRequestHasMoreThanOneAuthorization. ACA validates the Bearer token; the runtime validates the SAS params. They operate independently — don't configure them to overlap.

Getting a token (client credentials):

curl -X POST "https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token" \
  --data-urlencode "grant_type=client_credentials" \
  --data-urlencode "client_id=<app-id>" \
  --data-urlencode "client_secret=<secret>" \
  --data-urlencode "scope=api://<app-id>/.default"

Result:

# No token
HTTP 401  ← blocked by ACA ingress

# Valid Bearer token → initialize session
HTTP 200  {"protocolVersion":"2025-06-18","serverInfo":{"name":"Logic Apps Remote MCP Server",...}}

# Session established → tools/list
HTTP 200  {"tools":[{"name":"wf_arithmetic_div",...},{"name":"wf_arithmetic_add",...}]}

What ACA auth actually protects:

Path	Auth
`/api/mcp`	✅ Bearer token required
`/runtime/webhooks/workflow/api/management/*`	✅ Bearer token required
`/runtime/webhooks/workflow/scaleUnits/*`	❌ Excluded — SAS params only

The MCP client (Postman, Logic App connector, or any client) just needs to include Authorization: Bearer <token> on every request.

Validating with VS Code Copilot

VS Code Copilot can talk to any HTTP MCP server directly from the IDE. Add the secured endpoint to .vscode/mcp.json in your workspace:

{
  "servers": {
    "la-arithmeticmcp": {
      "type": "http",
      "url": "https://la-arithmeticmcp.<env>.westeurope.azurecontainerapps.io/api/mcp",
      "headers": {
        "Authorization": "Bearer <token>"
      }
    }
  }
}

On workspace open, Copilot sends initialize → tools/list and populates its tool list from the response. The screenshot below shows the result — all 7 arithmetic tools returned from the live ACA endpoint, confirming that the Bearer token clears ACA ingress and the MCP session handshake completes successfully end to end.

Running Azure Logic Apps Standard on Azure Container Apps

Daniel Jonathan — Wed, 29 Apr 2026 14:16:18 +0000

Should you use Logic Apps Standard on ACA instead of n8n?

n8n is popular for workflow automation — Docker-native, visual editor, hundreds of integrations. But if you're already in Azure, it means running and paying for another self-hosted service on top of your existing infrastructure.

Logic Apps Standard on ACA is a cost-effective alternative if your workflows stay within the built-in connector set: Azure Blob, Queue, Service Bus, Event Hubs, HTTP, OpenAI, AI Search. No extra services, no OAuth setup. Durable run history, GitOps-friendly JSON definitions, and event-driven triggers — all included at container economics instead of an always-on App Service plan.

Hard limits — know them before you start:

Not a supported scenario. This is not an officially supported deployment model. Microsoft support will not cover issues in this configuration — scaling and observability features are unavailable. Use for dev/test and experimentation only — production use is at your own risk.
No managed connectors. Gallery connectors (O365, SharePoint, SQL, etc.) require an App Service MSI endpoint that ACA doesn't provide.
No XSLT maps. The Transform XML action uses NetFxWorker.exe — a Windows-only .NET Framework binary that won't run on Linux. Liquid/JSON transforms work fine (they run in-process).
Rebuild to deploy. Workflows are baked into the image. Any change = Docker build + push + ACA update.
Visual designer needs local Docker. Design and test locally, then deploy.
Cold starts. Scale-to-zero means latency after idle — matters for synchronous HTTP workflows.

If any of those are blockers, use App Service Standard instead. If they're not — keep reading.

One thing that doesn't change moving to ACA: workflow state and run history are still backed by Azure Table Storage, the same as App Service. Durability is unchanged — the container is just the runtime host.

What we're building

Six workflows deployed as a single Docker container on ACA:

Workflow	Trigger	Purpose
wf1	HTTP GET	Stateful HTTP request/response
wf2	Azure Blob Storage	Fires on blob upload, reads metadata
wf3	Azure Queue Storage	Processes queue messages
wf4	Azure Service Bus	Processes messages from wf4queue
wf5	Azure Service Bus	Receives SB message, calls external HTTP endpoint
wf6	HTTP POST	JSON-to-JSON transform via Liquid map

The Docker image

No official pre-built image exists for Logic Apps Standard — you build your own with the Functions Core Tools and your workflow files baked in:

FROM mcr.microsoft.com/dotnet/sdk:8.0

ENV DEBIAN_FRONTEND=noninteractive
WORKDIR /home/site/wwwroot

RUN apt-get update && \
    apt-get install -y curl gnupg unzip coreutils && \
    curl -fsSL https://deb.nodesource.com/setup_18.x | bash - && \
    apt-get install -y nodejs && \
    npm install -g azure-functions-core-tools@4 --unsafe-perm=true && \
    apt-get clean && rm -rf /var/lib/apt/lists/*

COPY . .

ENV FUNCTIONS_WORKER_RUNTIME="node"
ENV FUNCTIONS_WORKER_RUNTIME_VERSION="~4"
ENV AzureWebJobsFeatureFlags="EnableMultiLanguageWorker"
ENV AzureWebJobsSecretStorageType="Files"
ENV APP_KIND="workflowapp"

EXPOSE 7074
ENTRYPOINT ["func", "start", "--verbose", "--port", "7074"]

Workflow JSON files are baked in at COPY . .. The runtime reads and executes them — no compilation step.

Project structure

LABasicDemo/
├── host.json                  # Extension bundle declaration
├── connections.json           # Service provider connections
├── Dockerfile
├── Artifacts/Maps/            # Liquid maps (wf6)
├── wf1/workflow.json ... wf6/workflow.json

connections.json maps each connection name (e.g. servicebus) to a serviceProviderId and a connection string via @appsetting(...). The runtime resolves these at startup — no ARM roundtrip.

Bicep infrastructure

The sections below highlight the non-obvious parts. ACR, Log Analytics, and ACA Environment are standard boilerplate.

Service Bus — Basic SKU is enough

Basic SKU covers queues. Standard is only needed for topics or managed API connections — which don't work in ACA anyway.

The critical env vars — stability fixes

The Logic Apps runtime generates a 15-character LAIdentifier hash to namespace all Azure Table Storage tables for run history. By default the hash is derived from the host ID — if that changes on restart, run history appears lost.

Three env vars pin the identity across pod restarts:

{ name: 'AzureFunctionsWebHost__hostid', value: appName }
{ name: 'WEBSITE_HOSTNAME',              value: '${appName}.${acaEnv.properties.defaultDomain}' }
{ name: 'WEBSITE_CONTENTSHARE',          value: contentShareName }

Without AzureFunctionsWebHost__hostid, every restart generates a new host ID, a new LAIdentifier, new storage tables — and prior run history is effectively orphaned.

Azure Files mount — critical path

Mount at .azure-webjobs-hosts, not at /home/site/wwwroot. Mounting at the root wipes all workflow files baked into the image.

volumeMounts: [{ volumeName: 'content-share', mountPath: '/home/site/wwwroot/.azure-webjobs-hosts' }]

This directory holds blob trigger checkpoints and distributed locks — persisting it prevents replaying already-processed blobs after a restart.

Full env var list

env: [
  { name: 'AzureWebJobsStorage',                      secretRef: 'storage-connection-string' }
  { name: 'WORKFLOWS_STORAGE_CONNECTION_STRING',      secretRef: 'storage-connection-string' }
  { name: 'AzureBlob_connectionString',               secretRef: 'storage-connection-string' }
  { name: 'azurequeues_connectionString',              secretRef: 'storage-connection-string' }
  { name: 'servicebus_connectionString',              secretRef: 'servicebus-connection-string' }
  { name: 'FUNCTIONS_WORKER_RUNTIME',                 value: 'node' }
  { name: 'FUNCTIONS_WORKER_RUNTIME_VERSION',         value: '~4' }
  { name: 'AzureWebJobsFeatureFlags',                 value: 'EnableMultiLanguageWorker' }
  { name: 'APP_KIND',                                 value: 'workflowapp' }
  { name: 'WEBSITE_SITE_NAME',                        value: appName }
  { name: 'APPINSIGHTS_INSTRUMENTATIONKEY',           value: appInsightsKey }
  { name: 'WEBSITE_CONTENTAZUREFILECONNECTIONSTRING', secretRef: 'storage-connection-string' }
  { name: 'WEBSITE_CONTENTSHARE',                     value: contentShareName }
  { name: 'WEBSITE_HOSTNAME',                         value: '${appName}.${acaEnv.properties.defaultDomain}' }
  { name: 'AzureFunctionsWebHost__hostid',            value: appName }
  { name: 'WEBSITE_RESOURCE_GROUP',                   value: resourceGroup().name }
  { name: 'WEBSITE_OWNER_NAME',                       value: '${subscription().subscriptionId}+${resourceGroup().name}-WestEuropewebspace' }
]

Deployment

deploy.sh — provision infrastructure

az deployment group create \
  --resource-group LogicAppHubRG \
  --template-file infra/main.bicep \
  --parameters infra/main.bicepparam \
  --output table

build-push.sh — build and deploy the image

ACA caches the image digest at revision creation time — deploying with :latest may leave the container on a stale image. Always pin the exact digest:

az acr build --registry labasicdemoacr --image logicapp-basicdemo:latest \
  --file ../LABasicDemo/Dockerfile ../LABasicDemo

DIGEST=$(az acr repository show-manifests --name labasicdemoacr \
  --repository logicapp-basicdemo --orderby time_desc --query "[0].digest" -o tsv)

az containerapp update --name la-basicdemo --resource-group LogicAppHubRG \
  --image "labasicdemoacr.azurecr.io/logicapp-basicdemo@$DIGEST"

az acr build runs the Docker build in the cloud — no local Docker daemon needed.

What lands in Azure

The Service Bus namespace and storage account live in a separate shared resource group.

Notable workflows

wf5 — Service Bus → HTTP action

wf5 originally used a managed API connection for Service Bus. It was redesigned to use the service provider connector (connection string auth) + a built-in HTTP action after managed connections proved unworkable. The service provider trigger polls wf5queue; on receipt it fires a GET to an external endpoint.

wf6 — Liquid JSON transform

Liquid maps work in Linux containers — processed in-process with no external binary. Map stored in Artifacts/Maps/PersonToContact.liquid:

{
  "fullName": "{{content.firstName}} {{content.lastName}}",
  "email": "{{content.email}}"
}

Action in workflow.json:

{
  "type": "Liquid",
  "kind": "JsonToJson",
  "inputs": {
    "content": "@triggerBody()",
    "map": { "source": "LogicApp", "name": "PersonToContact.liquid" }
  }
}

Test: POST {"firstName":"John","lastName":"Doe","email":"john@example.com"} → {"fullName":"John Doe","email":"john@example.com"}

Agentic flows work out of the box

One capability worth calling out explicitly: AI agent workflows are fully supported in ACA containers. Azure OpenAI and Azure AI Search are both built-in service provider connectors — they authenticate via API key in app settings, no ARM token required. This means you can build agentic patterns (LLM calls, RAG pipelines, tool-use loops) directly in Logic Apps Standard and deploy them to ACA with no additional setup.

This is a meaningful advantage over n8n, which relies on community nodes for OpenAI integration. Logic Apps gives you native stateful orchestration, durable run history per step, and retry policies — all built into the agent workflow without extra infrastructure.

The connector boundary

Logic Apps connectors come in two families:

Service provider connectors (built-in) — authenticate via connection strings, no ARM roundtrip. Work in containers:
Azure Blob, Azure Queue, Azure Service Bus, Azure Event Hubs, HTTP/HTTPS, Azure OpenAI, Azure AI Search.

Managed API connections (Microsoft.Web/connections) — the 400+ gallery connectors. Require an ARM token acquired via the App Service MSI endpoint (IDENTITY_ENDPOINT + IDENTITY_HEADER). App Service injects this automatically; ACA does not.

We tried two approaches: service principal via WORKFLOWAPP_AAD_CLIENTID / TENANTID / CLIENTSECRET, and user-assigned managed identity via AZURE_CLIENT_ID. Neither worked — the WORKFLOWAPP_AAD_* variables are only active in the Hybrid Deployment Model (Arc-enabled AKS + ACA Logic Apps extension), not the custom image approach.

XSLT maps also don't work: the Transform XML action delegates to NetFxWorker.exe — a Windows PE32 binary that the Linux kernel refuses to execute.

Feature	ACA (Linux)
Service provider connectors	✅
Liquid / JSON transforms	✅
Managed API connections	❌ No MSI endpoint
XSLT maps	❌ Windows-only binary

Verifying stability across restarts

The key test: trigger each workflow, stop and restart the container, then check that the same run IDs are still visible in history.

The easiest way to inspect run history is the Logic Apps Run History View Tool VS Code extension — connect it to the deployed ACA endpoint and browse runs per workflow directly in the editor, with full input/output per action visible.

Before the AzureFunctionsWebHost__hostid fix, run history was orphaned on every restart. After the fix it survives indefinitely.

Cost comparison vs n8n

	n8n (self-hosted)	Logic Apps Standard on ACA
Compute	Fixed VM/container cost	Serverless, scale to 0
State storage	SQLite / Postgres	Azure Table Storage (~pennies)
Built-in connectors	400+ community nodes	Service providers + HTTP
Managed connectors (O365 etc.)	✅	❌ App Service only
XSLT maps	✅	❌ Windows only
Liquid transforms	✅	✅
Run history	Basic	Full input/output per action
Visual designer	✅	✅ VS Code (local)
GitOps / IaC	Manual	Native JSON + Bicep

Sweet spot: Azure-native event-driven pipelines — blob, queue, Service Bus, outbound HTTP — where you want durable run history and GitOps deployment without an always-on App Service plan.

What's next

For local development — running the same container with Docker, Azurite, and the Logic Apps VS Code extension — see:

Logic Apps Local Dev Tools — Visual Walkthrough

That post covers the full design → test → deploy loop without repeating what's here.

Event Debouncing with Logic Apps and Azure Table Storage

Daniel Jonathan — Mon, 20 Apr 2026 17:58:35 +0000

Forwarding every webhook event directly to a downstream API is a recipe for throttling and duplicate processing. This post walks through how to fix that with three Logic Apps and one Azure Table Storage table.

Debouncing is a term from frontend development — wait for the noise to stop, then act once.

In integration, this pattern is better described as event buffering with deduplication: absorb bursts, collapse repeated updates per entity, and process only the final state.

In this implementation, Azure Table Storage is not the source of truth — it acts as a deduplication index. We store only the entity ID, and at processing time we re-fetch the authoritative state from the source system before calling downstream APIs.

The Problem

Source systems fire event bursts — hundreds of events at once during bulk imports, and multiple rapid updates for the same entity. You don't need to process every intermediate state — only the final one per entity.

A burst of 200 events may touch 50 entities, each updated multiple times. Every entity should be processed once, with its latest state — and the downstream API called once per entity.

The Pattern

Source System Webhook
        │
        ▼
  rcv-events  (HTTP trigger)
        │  upsert each event → EventBuffer table
        ▼
  Azure Table Storage: EventBuffer
        │  PartitionKey: "relation-events"  RowKey: entityId  Status: "Pending"
        ▼
  prc-events  (Timer: every 5 min)
        │  query Pending rows older than X min → dispatch each
        ▼
  prc-process-single-event
        │  mark Processing → fetch fresh from source → call downstream
        │  delete on success  /  reset to Pending on failure
        ▼
  Downstream API

Step 1 — Receive

rcv-events accepts a batch of events via HTTP and upserts each one into the buffer table. No queue, no broker — the HTTP trigger is the ingress.

Each row looks like this:

{
  "PartitionKey": "relation-events",
  "RowKey": "<entityId>",
  "Event": "updated",
  "EntityType": "Record",
  "Status": "Pending",
  "ReceivedAt": "2026-04-20T14:30:00Z"
}

RowKey = entityId is the key insight. No matter how many events arrive for the same entity, there is always exactly one row. The tenth update overwrites the ninth. Deduplication is a schema decision, not code.

Step 2 — Wait

prc-events runs on a timer (every 5 minutes) and queries rows where Status eq 'Pending' and LastUpdated <= utcNow() - X minutes. The time window is your debounce threshold — nothing gets processed until the burst settles.

Step 3 — Process

For each pending row, prc-process-single-event:

Marks the row Processing — prevents double-processing if the timer fires again mid-run
Fetches the current state from the source system — never trusts the buffered payload, which may already be stale
Calls the downstream API with fresh data
Deletes the row on success / resets to Pending on failure

This gives at-least-once delivery with automatic retry — no custom infrastructure needed.

Status Lifecycle

Pending  →  Processing  →  [deleted]
                 │
                 └──(on failure)──→  Pending

Three states, one field. Fully visible in Azure Storage Explorer during an incident.

Why It Works

Deduplication for free — one row per entity, always the latest
No ordering concerns — you fetch fresh data at processing time, so intermediate states are irrelevant
Respects downstream rate limits — 20 updates in 30 minutes still results in one API call to the downstream system
Parallel processing — prc-events fans out each pending row as an independent call, so entities are processed concurrently with isolated retry state
Operationally transparent — query the table, see exactly what's pending or stuck
No broker needed at low-to-moderate scale — if your HTTP trigger can handle the inbound burst and your timer cadence keeps up with the queue depth, you don't need Service Bus

Consider adding Service Bus only if you need strict ordering, dead-lettering, or multiple consumers on the same stream.

When Not to Use This Pattern

Avoid it when you need strict event ordering, every event preserved independently, near-real-time latency, multiple consumers, or very high throughput. In those cases, reach for Service Bus or Event Hubs instead.

No Service Bus. No custom retry logic. No ordering guarantees needed. Just a table, a timer, and one row per entity.

Debugging XSLT vs Liquid in VS Code

Daniel Jonathan — Fri, 03 Apr 2026 09:39:35 +0000

Both the XSLT Debugger and DotLiquid Debugger let you step through a template and inspect variables. But they work differently under the hood — and those differences affect what you can do while debugging.

The Fundamental Difference

XSLT debugging is live. The XSLT Debugger supports two engines, each with its own instrumentation strategy:

Saxon (XSLT 2.0/3.0) — exposes a TraceListener interface with Enter and Leave callbacks that fire as each instruction executes. The engine cooperates natively.
.NET XslCompiledTransform (XSLT 1.0) — has no TraceListener, so the debugger rewrites the stylesheet at load time, injecting <dbg:probe> extension calls into every template, if, for-each, and when block. A registered extension object handles each probe and pauses execution on a TaskCompletionSource until you click Step.

Both approaches genuinely pause execution. You're inspecting a running process.

Liquid debugging is replay. DotLiquid has no such API — Template.Render() runs the whole template and returns. The extension records a trace during that render, then lets you step through the recording. By the time you click Step, the template has already finished.

Capability Comparison

	XSLT Debugger	DotLiquid Debugger
Step model	Live pause/resume	Trace replay
Breakpoints	Yes — set and hit mid-execution	No
Backward stepping	No	Always — it's just a recording
Variable state	Live, from the running engine	Recorded snapshot at each step
Modify and continue	No	No — edit and re-render
Conditional breakpoints	No	No
Filter chain tracing	N/A	Yes — each filter is a step
Branch visibility	Taken branch only	Taken branch only
Re-render cost	Steps are free (engine is paused)	One render upfront, steps are free after

What This Looks Like in Practice

Setting a breakpoint:
In the XSLT debugger you can set a breakpoint on a specific <xsl:template> or <xsl:for-each>, hit F5, and the debugger stops there — even if that template fires 50 iterations in. You never see the first 49.

In the DotLiquid debugger there are no breakpoints. You start at step 1 and click forward. For a template with many iterations you can drag the step slider to jump ahead quickly, but you can't say "stop when item.qty > 10".

Backward stepping:
The DotLiquid debugger supports backward stepping — you're just moving a cursor through a recording. The XSLT Debugger does not support step back.

Modifying state:
Neither debugger supports modify-and-continue. In both cases you edit the template or input and re-render from scratch.

Filter chain tracing:
This is where the DotLiquid debugger has an advantage. Because every filter application is recorded as a separate step, you can step through name | Upcase | Truncate: 10 | Append: "…" and see the value after each filter. XSLT doesn't have filter chains — XPath functions are composed inline and there's no equivalent granularity.

Why the Difference Exists

Both XSLT engines provide a path to genuine pause/resume — either through a native TraceListener (Saxon) or through stylesheet rewriting at load time (.NET XSLT 1.0). The key is that XSLT execution is structured: templates fire, instructions execute in sequence, and there are clear entry/exit points to hook into.

DotLiquid was designed as a simple, safe rendering library. It has no extension points for interrupting execution, and its render loop is a single synchronous call with no observable mid-execution state. The replay approach is the only option available without forking the engine.

Which Should You Use?

If you're debugging XSLT maps — especially complex structural transformations, apply-templates logic, or recursive templates — the live debugger is significantly more powerful. Breakpoints and live state make it practical to debug templates that are hundreds of lines long. Use the compiled engine for XSLT 1.0 (including inline C#); use Saxon for XSLT 2.0/3.0. The full series is covered in XSLT Debugging in Logic Apps.

If you're debugging Liquid maps — filter results, conditional branches, loop variable values — the replay model covers the common cases well. The main limitation is the absence of breakpoints; for most Liquid templates this is a minor inconvenience rather than a real blocker. For a deeper look at Liquid templates and the debugger extension, see DotLiquid Debugging in Logic Apps.

DEV Community: Daniel Jonathan

The Green Screen That Wouldn't Let Go

How we taught a robot to rescue 15 plus years of accounting data from a 1990s computer — and then taught other robots to babysit it

The map

Act 1: You can't automate what you can't see

Act 2: Reading a screen like it's 1979

Act 3: The crash that hid inside its own evidence

Act 4: The error window the robot cannot see

Act 5: The day the computer lied about the time

Act 6: Nobody wants to restart a robot at 3 a.m.

Act 7: A report doesn't exist until it's checked, filed, and written down

What this old machine taught us

Building with TypeSafe AI's Jev in Logic Apps: from triage to a router agent

What Jev answers with

Part 1: Triage

It runs

Part 2: A router agent

Call workflow doesn't work in Automation — use Http instead

It works — both branches

Conclusion

Logic Apps Automation runs on Container Apps: what the portal doesn't tell you

The short version

How you create an app

Each app becomes a Container App

Versions are revisions

Each app has its own scale settings

Runtime version

A quick check that it runs

Analytics: hello-world, last 24 hours

What the docs don't cover

Securing Shared API Connections in Azure Logic Apps Standard with Access Policies

The Problem

Background: How Managed API Connections Work in Logic Apps Standard

The Pattern: One Connection, Multiple Logic Apps, Granular Access

Architecture Overview

Provisioning Connections (Shared Infrastructure)

Assigning Access Policies Per Logic App

Step 1 — Fetch the Logic App's Managed Identity

Step 2 — Prepare the Access Policy Body

Step 3 — PUT the Policy on the Relevant Connections

Approach A — All connections

Approach B — Prefix filtering + explicit shared connections

Generating connections.json

What the script does

Output structure

Calling the script in the pipeline

Injecting service provider connections

Shared vs. Logic-App-Specific Connections

Service Provider Connections: No Access Policies Needed

End-to-End Pipeline Flow

Summary

Forget Sampling — This One host.json Setting Cuts Logic Apps Telemetry Costs by 80%

The Problem

The Experiment

The Numbers

Billable ingestion — equal 9-hour windows per phase

Finding 1: v2 Schema Does Most of the Work

Finding 2: enableDependencyTracking: false Eliminates AppDependencies Completely

Finding 3: Sampling Adds Only Marginal Extra Reduction

Finding 4: Some Telemetry Bypasses Sampling — By Design

Finding 5: enablePerformanceCountersCollection: false Had Minimal Effect

Finding 6: Disabling Dependency Tracking Changes How Errors Appear

The Right host.json — Ordered by Impact

Step 1 — Switch to v2 schema (do this first, always)

Step 2 — Disable dependency tracking if you don't need per-call detail

Step 3 — Add sampling only if further reduction is needed

The complete cost-control host.json

Troubleshooting Without Redeployment

Now What — 3 Queries for the Trade-offs

1. After disabling dependency tracking, find failed outbound calls in AppExceptions

2. Confirm failed runs are always captured despite sampling

3. Measure your actual cost reduction (Log Analytics)

Summary

Logic Apps Agent Loop + MCP: Two Bugs Worth Knowing About

Context

Bug 1 — Intermittent duplicate key error at tool registration

What happens

What makes it particularly frustrating to diagnose

Load test

What you can't do

Finding 2: `enableDependencyTracking: false` Eliminates `AppDependencies` Completely

Finding 5: `enablePerformanceCountersCollection: false` Had Minimal Effect