Azure Logic Apps Standard: Stateful Workflows, VNet Integration, and B2B/EDI Integration Accounts

Logic Apps Standard is not “Consumption with a different SKU.” It is a different runtime — the single-tenant Azure Functions host running the Logic Apps engine as an extension — and that one fact drives almost every architectural decision you will make. You get a deployable package of code-like artifacts instead of a portal-bound resource, a dedicated compute plane you can drop into a virtual network, built-in connectors that run in-process, and a flat hosting price instead of per-action billing. The trade is that you now own things the Consumption tier hid from you: the storage account behind run history, the VNet plumbing, the deployment pipeline, and the integration-account lifecycle.

This guide builds a production-grade Standard logic app the way it survives an enterprise: stateful and stateless workflows side by side, locked behind private endpoints, exchanging EDI (AS2/X12/EDIFACT) with trading partners, and shipped through Bicep with deployment slots. The hardest failures in this space are quiet — a logic app that will not start because its storage lost a table private endpoint, a managed connector that silently can’t reach a private SQL server, a poison interchange that hot-loops your consumer. So beyond the prose and the az/Bicep snippets, every section anchors to scannable reference tables: the option matrices you set once, the limits you bump into, and a symptom → cause → confirm → fix playbook you keep open during a cutover.

By the end you will pick stateful versus stateless per workflow deliberately, wire all four storage sub-resources for private access, choose built-in over managed connectors for anything inside your VNet, load and reference B2B artifacts without the old Consumption link step, and ship the whole thing through a staging slot with slot-sticky settings. You will also know exactly which az command or portal blade proves each failure, so a stuck deployment is a ninety-second diagnosis instead of a two-hour one.

What problem this solves

Enterprise integration is where systems that were never meant to talk are forced to. An order placed in a partner’s ERP arrives as an X12 850 over AS2; it must be decoded, validated against an agreement, acknowledged with a 997, transformed, and written to a private order database — durably, with retries, and an audit trail a partner’s dispute can be settled against. Consumption Logic Apps handled the shape of this beautifully but hit two production walls: per-action billing turned high-fan-out EDI into a line item leadership noticed, and the multi-tenant connector model could not reach resources locked behind private endpoints, because connector traffic originates from Microsoft’s network, not yours.

What breaks without Standard’s model: teams either keep paying per-action and accept that a private-only data tier is impossible through managed connectors, or they hand-roll the whole pipeline in Functions and re-implement AS2/EDI from scratch. Both are expensive in different currencies. Standard collapses the gap — in-process B2B operations, VNet-aware built-in connectors, flat compute — but it hands you the operational surface the platform used to hide: storage you must keep reachable, networking you must configure in both directions, and a runtime that simply will not boot if its content share can’t mount.

Who hits this: integration teams moving EDI/B2B workloads off Consumption for cost or network-isolation reasons; platform teams adopting a hub-spoke topology where every PaaS dependency must be private; and anyone who tried to lock down a Standard logic app’s storage by copying an App Service runbook and watched the app refuse to start. The fix is rarely “open it back up” — it’s “find the sub-resource, setting, or DNS zone that’s missing and make the runtime’s dependency reachable.”

To frame the whole field before the deep dive, here is the spread of decisions this article makes concrete, the question each forces, and where the answer lives:

Learning objectives

By the end of this article you can:

• Explain why Logic Apps Standard is the single-tenant Functions host with a Logic Apps extension, and when its flat compute billing beats Consumption’s per-action model (and when it doesn’t).
• Choose stateful vs stateless per workflow from first principles, and design run-history storage as a first-class, retention-bounded dependency.
• Wire VNet integration outbound and a private endpoint inbound, and — the part teams forget — make all four storage sub-resources (blob, file, table, queue) private with vnetContentShareEnabled and the matching private DNS zones.
• Pick built-in (service-provider) connectors for anything in your VNet and reserve managed connectors for public SaaS, and authenticate end-to-end with managed identity instead of keys.
• Stand up AS2/X12/EDIFACT B2B in-process, load partners/agreements/schemas/maps into an integration account of the right SKU, and route functional acks (997/CONTRL) back to partners.
• Build defence in depth for failures with action retry policies, try/catch scopes, and broker-native dead-letter strategy so a poison interchange parks instead of hot-looping.
• Ship the project as a zip to a staging slot, smoke-test, and swap with slot-sticky settings and per-slot VNet integration — and wire Application Insights with the KQL that finds a failing action fast.
• Diagnose the canonical Standard failure modes (won’t start on private storage, managed connector can’t reach private SQL, slot leaked creds) with the exact command or blade that confirms each.

Prerequisites & where this fits

You should be comfortable with the App Service / Functions hosting model — an App Service (or Workflow Standard) plan is the set of VM workers you rent, and the logic app runs on it sharing its CPU and memory — because a Standard logic app is a function app with kind functionapp,workflowapp. You should know how to run az in Cloud Shell, read JSON output, and understand private endpoints, private DNS zones, and managed identity at a working level. Familiarity with EDI concepts (interchange, transaction set, control numbers) helps for the B2B section but is not assumed.

This sits in the Integration & Networking track. Upstream of it are the platform mechanics in the Azure App Service Deep Dive: Plans, Scaling, Slots, TLS (the plan, slots and VNet integration are shared) and the storage fundamentals in Azure Storage Accounts Deep Dive (run history lives there). It pairs tightly with Azure Service Bus sessions, dedup & dead-letter patterns for the messaging backbone, private endpoint vs service endpoint and private endpoints & private DNS at scale for the network isolation, and Azure Monitor & Application Insights for observability for the telemetry. If you are weighing this against code-first orchestration, Azure Durable Functions orchestration patterns is the sibling decision, and the EDI/B2B integration platform on Logic Apps article goes deeper on the trading-partner side.

A quick map of who owns what during an integration incident, so you call the right person fast:

Core concepts

Six mental models make every later decision obvious.

The resource is a function app wearing a Logic Apps hat. One Standard logic app hosts many workflows, each a workflow.json in its own folder. The resource — not the workflow — is the unit of deployment, scaling, networking, and identity. The az logicapp command group is a thin wrapper over az functionapp; when an operation is missing under logicapp, the functionapp equivalent works because the kind is literally functionapp,workflowapp. Internalise this and the whole platform stops being mysterious: VNet integration, slots, app settings, and Kudu all behave exactly as they do for Functions.

Billing is by allocated compute, not per action. You rent a plan (WS1/WS2/WS3 elastic, or App Service plan, or ASEv3 for full isolation) and pay for vCPU and memory whether it runs one action or ten million. A chatty, high-fan-out workflow is dramatically cheaper here; a workflow that fires ten times a day is cheaper on Consumption. This inversion is the entire economic case for migrating EDI.

Stateful versus stateless is a per-workflow durability contract. Stateful persists every run, every action input/output, and trigger history to external storage — you get durable run history, full inspection, resubmit, and mid-run survival across host restarts. Stateless runs entirely in memory — no persisted history, far lower latency, higher throughput, but no durability and run history off by default. The right pattern is usually both: a stateless front door for low-latency intake calling a stateful core for durable processing.

Built-in connectors run in your process; managed connectors run in Microsoft’s. Built-in (service-provider) connectors — Service Bus, SQL, Blob, Event Hubs, Cosmos DB, and the B2B operations — execute in-process on your plan and therefore honour VNet integration. Managed (API-connection) connectors egress from Microsoft’s multi-tenant connector service, so they cannot reach a private endpoint, and they bill per call. For anything inside your VNet, built-in is not a preference, it’s a requirement.

The storage account is on the hot path of every stateful run. The runtime keeps run history in Azure Storage tables and blobs, mounts its content share from Azure Files, and uses queues for internal dispatch. Lock that storage down wrong and the app won’t even start — it needs blob, file, table, and queue reachable, plus vnetContentShareEnabled to mount the content share over the VNet, plus the four privatelink DNS zones. This is the single most common Standard cutover failure.

B2B operations are in-process, but the artifacts still live in an integration account. In Standard, AS2 (v2), X12, and EDIFACT encode/decode run on your plan — but trading partners, agreements, schemas, maps, and certificates live in an integration account that, unlike Consumption, does not need to be linked to the logic app. Same subscription and region, referenced by name, no link step.

The vocabulary in one table

Before the deep sections, pin down every moving part. The glossary repeats these for lookup; this is the mental model side by side:

Standard vs Consumption: the single-tenant runtime and pricing model

In Consumption, each logic app is one workflow, defined in ARM, billed per action execution, sharing a multi-tenant runtime you do not control. Standard inverts all of that. The clearest way to see the difference is feature by feature:

The decision rule, as a table you can hand to an architect:

A bare-bones provisioning path — App Service (or WS) plan plus the logic app:

RG=rg-integration-prod
LOC=westeurope
PLAN=asp-logicapps-prod
APP=la-orders-prod
SA=stlaordersprod$RANDOM   # storage backs run history + content

az group create -n $RG -l $LOC

az storage account create -n $SA -g $RG -l $LOC \
  --sku Standard_LRS --kind StorageV2 --min-tls-version TLS1_2 \
  --allow-blob-public-access false

# Workflow Standard plan (elastic) for single-tenant Logic Apps
az functionapp plan create -n $PLAN -g $RG -l $LOC \
  --sku WS1 --is-linux false

az logicapp create -n $APP -g $RG -l $LOC \
  --plan $PLAN --storage-account $SA \
  --functions-version 4

The az logicapp command group is a thin wrapper over az functionapp. Many operations you cannot find under az logicapp exist under az functionapp and work fine, because a Standard logic app is a function app with a Logic Apps extension bundle and a kind of functionapp,workflowapp.

Choose the hosting plan deliberately — it sets your compute ceiling, scale behaviour, and isolation:

The local project that this resource deploys is just a folder. func init with the workflow worker, or the VS Code “Azure Logic Apps (Standard)” extension, scaffolds:

my-logic-app/
  host.json                 # runtime settings for the whole resource
  local.settings.json       # local-only app settings (do NOT deploy secrets)
  connections.json          # managed + service-provider connection refs
  parameters.json           # workflow parameters (environment-substitutable)
  Orders-Intake/
    workflow.json           # one workflow definition
  EDI-Inbound/
    workflow.json
  workflow-designtime/       # design-time host used by the designer only
    host.json
    local.settings.json

Each file in that layout has a single job — and a single way it bites you if you get it wrong:

The host.json pins the extension bundle that carries the Logic Apps runtime and all built-in connectors:

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  }
}

Stateful vs stateless workflows and run-history storage design

Every workflow declares a kind: Stateful or Stateless. This is the single most consequential per-workflow choice you make, and it is irreversible only in the sense that switching changes behaviour you may depend on. Lay the two side by side:

A minimal stateful definition header:

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "triggers": { },
    "actions": { },
    "outputs": { }
  },
  "kind": "Stateful"
}

Picking which to use, by trigger and intent:

Run-history storage design is your responsibility now. The storage account is on the hot path of every stateful run; treat it as a first-class dependency. Stateless can enable run history for debugging only, at a throughput cost, via Workflows.<name>.OperationOptions = WithStatelessRunHistory.

• Use a dedicated storage account per logic app (or per environment) so run-history I/O does not contend with application data.
• Keep it in the same region as the plan. Cross-region storage adds latency to every action checkpoint.
• Plan retention. Stateful run history accumulates and counts toward cost. Set retention with the Runtime.Backend.Run.MaxRunHistoryRetentionInDays host setting and let the engine prune:

{
  "version": "2.0",
  "extensionBundle": {
    "id": "Microsoft.Azure.Functions.ExtensionBundle.Workflows",
    "version": "[1.*, 2.0.0)"
  },
  "extensions": {
    "workflow": {
      "settings": {
        "Runtime.Backend.Run.MaxRunHistoryRetentionInDays": "90"
      }
    }
  }
}

What each storage sub-resource is used for, so you know why all four must be reachable when you go private:

The host settings worth knowing for run-history and dispatcher behaviour:

A useful default: make the fast synchronous edges stateless and the orchestration core stateful, and have the stateless front door call the stateful workflow. You get low-latency intake and durable processing without paying the storage tax on every health check.

VNet integration, private endpoints, and access restrictions

Enterprise Standard deployments are almost always private. There are two independent traffic directions, and you configure them separately — confusing them is a top-three mistake.

Outbound (your workflow reaching private resources) uses regional VNet integration — the same mechanism as App Service. Outbound calls to a private SQL, Service Bus, or storage endpoint route through a delegated subnet:

VNET=vnet-integration
SUBNET=snet-logicapps     # delegated to Microsoft.Web/serverFarms, /26 or larger

az functionapp vnet-integration add -g $RG -n $APP \
  --vnet $VNET --subnet $SUBNET

# Force all outbound traffic through the VNet (not just RFC1918)
az functionapp config appsettings set -g $RG -n $APP \
  --settings WEBSITE_VNET_ROUTE_ALL=1

The subnet has hard requirements — get any of these wrong and integration silently fails or starves you of IPs:

Inbound (clients reaching your workflow triggers) uses a private endpoint on the logic app, plus public-access lockdown:

az network private-endpoint create -g $RG -n pe-$APP \
  --vnet-name $VNET --subnet snet-private-endpoints \
  --private-connection-resource-id $(az logicapp show -g $RG -n $APP --query id -o tsv) \
  --group-id sites --connection-name conn-$APP

az functionapp config access-restriction set -g $RG -n $APP \
  --default-action Deny

The storage account is the part teams forget. A Standard logic app cannot start if it cannot reach its own run-history storage. When you lock the storage account behind private endpoints, you must also tell the runtime to mount its content share over the VNet. The modern control is the site property vnetContentShareEnabled (which superseded the WEBSITE_CONTENTOVERVNET=1 app setting). You need private endpoints for all four storage sub-resources — blob, file, table, and queue:

for SUB in blob file table queue; do
  az network private-endpoint create -g $RG -n pe-$SA-$SUB \
    --vnet-name $VNET --subnet snet-private-endpoints \
    --private-connection-resource-id $(az storage account show -g $RG -n $SA --query id -o tsv) \
    --group-id $SUB --connection-name conn-$SA-$SUB
done

# Mount content share over the VNet (required for private storage)
az resource update -g $RG -n $APP \
  --resource-type "Microsoft.Web/sites" \
  --set properties.vnetContentShareEnabled=true

Each storage sub-resource needs its matching private DNS zone linked to the VNet, or name resolution fails before networking does:

When you secure storage this way, every app sharing that account must use the same vnetContentShareEnabled value, and you still need the corresponding private DNS zones linked to the VNet, or name resolution fails before networking does. For the DNS design at scale, see private endpoints & private DNS at scale.

The access-restriction model has more than the binary default action — here is the full surface:

Built-in vs managed connectors and authentication patterns

Standard exposes two connector families, and choosing correctly is both a cost and a networking decision.

Prefer built-in connectors for anything in your VNet. A managed connector cannot reach a private endpoint, because its traffic originates from Microsoft’s connector service, not your integrated subnet. A built-in Service Bus or SQL connector runs on your plan and respects WEBSITE_VNET_ROUTE_ALL. The common targets and which family to use:

Built-in connections are pure config in connections.json, with secrets pulled from app settings:

{
  "serviceProviderConnections": {
    "serviceBus": {
      "parameterValues": {
        "fullyQualifiedNamespace": "@appsetting('SB_NAMESPACE')"
      },
      "serviceProvider": { "id": "/serviceProviders/serviceBus" },
      "displayName": "Orders namespace"
    }
  }
}

For authentication, use managed identity end to end. Assign a system- or user-assigned identity to the logic app and grant it data-plane RBAC on the targets — no connection strings, no shared keys to rotate (the broader pattern is in Key Vault secret rotation with managed identity):

az logicapp identity assign -g $RG -n $APP

PRINCIPAL=$(az logicapp identity show -g $RG -n $APP --query principalId -o tsv)
SB_ID=$(az servicebus namespace show -g $RG -n ns-orders --query id -o tsv)

az role assignment create --assignee $PRINCIPAL \
  --role "Azure Service Bus Data Receiver" --scope $SB_ID

The least-privilege data-plane roles you grant the identity, per target:

System-assigned versus user-assigned identity, because the choice affects CI/CD:

The built-in connector then authenticates with the identity by referencing it in the connection’s authentication block, so the only thing in local.settings.json is the fully qualified namespace, never a key.

B2B messaging: AS2, X12, EDIFACT, and integration accounts

This is where Standard genuinely diverges from Consumption, and where a lot of stale documentation will mislead you. In Standard, AS2 (v2), X12, and EDIFACT are built-in operations that run in-process — encode, decode, and the AS2 send/receive pipeline all execute on your plan. But the artifacts those operations need — trading partners, agreements, schemas, maps, and certificates — still live in an integration account. The critical change: in Standard, the integration account does not need to be linked to the logic app resource. You reference it, but the old “link the integration account to the logic app” step from Consumption is gone. It must still be in the same subscription and region as the logic app.

The B2B operations available in-process and what each does:

The artifacts you load into the integration account, and which operation needs each:

Provision the integration account and load artifacts:

az resource create -g $RG -n ia-edi-prod \
  --resource-type Microsoft.Logic/integrationAccounts \
  --location $LOC \
  --properties '{"sku":{"name":"Standard"}}'

# Upload an X12 schema (artifacts: schemas, partners, agreements, certs)
az logic integration-account schema create \
  -g $RG --integration-account ia-edi-prod \
  --schema-name X12_850_Schema \
  --content-type application/xml \
  --schema-type Xml \
  --input-path ./artifacts/X12_00401_850.xsd

Pick the SKU deliberately — this is a hard gate, not a soft preference:

Basic holds artifacts but does not support agreements — so no real X12/EDIFACT trading. B2B tracking for Standard workflows requires a Premium-level integration account — that is the tier gate for getting transaction-level tracking surfaced via Azure Data Explorer.

A decode step references the agreement and validates structure, control numbers, and (for AS2) MIC and signatures:

{
  "Decode_X12_message": {
    "type": "ServiceProvider",
    "inputs": {
      "parameters": {
        "message": "@triggerBody()",
        "agreementName": "Contoso-to-Fabrikam-850"
      },
      "serviceProviderConfiguration": {
        "serviceProviderId": "/serviceProviders/x12",
        "operationId": "decodeX12Message",
        "connectionName": "x12"
      }
    }
  }
}

The decode action returns the parsed payload, a control-number ack disposition, and a generated 997 (X12) or CONTRL (EDIFACT) acknowledgment you route back to the partner. The acknowledgment types and what they mean:

Wire the functional ack into your error path so a partner gets a negative ack on a bad interchange rather than silence.

Error handling, retry policies, and dead-letter strategies

Logic Apps gives you three layers of failure control. Use all three; relying on any one alone leaves a gap.

1. Action-level retry policy. Every action supports a retry policy. Default is exponential, four retries. Tune it explicitly on anything that touches a flaky dependency, and set it to none on non-idempotent operations you do not want re-attempted. The retry-policy options:

{
  "Call_partner_endpoint": {
    "type": "Http",
    "inputs": {
      "method": "POST",
      "uri": "@parameters('partnerUrl')",
      "retryPolicy": {
        "type": "exponential",
        "count": 4,
        "interval": "PT10S",
        "maximumInterval": "PT1H",
        "minimumInterval": "PT10S"
      }
    }
  }
}

When to use which retry type:

2. Scopes with runAfter for try/catch. Wrap a body of actions in a Scope, then add a handler scope that runs only when the first one fails, via runAfter statuses. This is the canonical Logic Apps try/catch. The runAfter statuses you compose with:

{
  "Try": { "type": "Scope", "actions": { "Process_order": { } } },
  "Catch": {
    "type": "Scope",
    "runAfter": { "Try": ["Failed", "TimedOut"] },
    "actions": {
      "Send_to_deadletter": {
        "type": "ServiceProvider",
        "inputs": {
          "parameters": { "entityName": "orders-deadletter", "message": "@result('Try')" },
          "serviceProviderConfiguration": {
            "serviceProviderId": "/serviceProviders/serviceBus",
            "operationId": "sendMessage",
            "connectionName": "serviceBus"
          }
        }
      }
    }
  }
}

@result('Try') returns the full action results inside the failed scope — inputs, outputs, status, error — which is exactly what you want to capture for a dead-letter record.

3. Dead-letter the message, not just the run. For event-driven intake (Service Bus, Event Hubs), let the broker’s native dead-letter queue do its job: do not auto-complete a message until processing succeeds, so a thrown exception abandons it back to the queue and, after max delivery count, lands it in the DLQ. Pair that with a separate “DLQ drain” workflow that reads the dead-letter subqueue, enriches with the failure reason, and pushes to a triage topic. The result: a poison EDI interchange parks itself instead of hot-looping your consumer. The Service Bus dead-letter mechanics (deep-dived in Service Bus sessions, dedup & dead-letter):

CI/CD with deployment slots, parameters, and ARM/Bicep packaging

Standard logic apps deploy as a zip of the project folder — the same artifact you run locally. That makes CI/CD genuinely code-like. Three rules govern it:

Provision infrastructure with Bicep, identity-first:

param location string = resourceGroup().location
param appName string
param planId string
param storageName string

resource logicApp 'Microsoft.Web/sites@2023-12-01' = {
  name: appName
  location: location
  kind: 'functionapp,workflowapp'
  identity: { type: 'SystemAssigned' }
  properties: {
    serverFarmId: planId
    vnetContentShareEnabled: true
    siteConfig: {
      vnetRouteAllEnabled: true
      appSettings: [
        { name: 'FUNCTIONS_EXTENSION_VERSION', value: '~4' }
        { name: 'FUNCTIONS_WORKER_RUNTIME', value: 'node' }
        {
          name: 'AzureWebJobsStorage'
          value: 'DefaultEndpointsProtocol=https;AccountName=${storageName};AccountKey=${listKeys(resourceId('Microsoft.Storage/storageAccounts', storageName), '2023-01-01').keys[0].value};EndpointSuffix=core.windows.net'
        }
        { name: 'APP_KIND', value: 'workflowApp' }
      ]
    }
  }
}

The app settings a Standard logic app actually depends on — what each does and the value that bites:

Deploy code with slots for zero-downtime cutover. Push to a staging slot, validate, then swap:

# one-time: create the staging slot
az functionapp deployment slot create -g $RG -n $APP --slot staging

# in the pipeline: zip-deploy the built project to staging
az functionapp deployment source config-zip \
  -g $RG -n $APP --slot staging --src ./output/app.zip

# smoke test the staging hostname here, then swap into production
az functionapp deployment slot swap -g $RG -n $APP --slot staging --target-slot production

Two slot caveats specific to Standard — both are silent until they hurt:

Mark connection-string and endpoint app settings as slot-sticky so a swap does not move staging credentials into production, and remember that a slot needs its own VNet integration — it is not inherited from production, so integrate the slot’s subnet or its outbound calls leave the VNet. The deployment methods compared:

Monitoring with Application Insights and run-time telemetry

Enable Application Insights at creation; the runtime emits structured telemetry for triggers, actions, and the host. Wire it through app settings (the full observability picture is in Azure Monitor & Application Insights):

AI_CONN=$(az monitor app-insights component show -g $RG -a ai-logicapps --query connectionString -o tsv)

az functionapp config appsettings set -g $RG -n $APP \
  --settings APPLICATIONINSIGHTS_CONNECTION_STRING="$AI_CONN"

How workflow telemetry maps to App Insights tables:

Workflow runs surface as requests, and individual action executions as dependencies and traces, each tagged with the workflow and run identifiers. This KQL pulls failed actions in the last day with their error, grouped by workflow:

traces
| where timestamp > ago(1d)
| extend wf = tostring(customDimensions["resource_workflowName"])
| extend action = tostring(customDimensions["actionName"])
| extend status = tostring(customDimensions["status"])
| where status == "Failed"
| summarize failures = count() by wf, action, message
| order by failures desc

For latency, chart the run duration distribution to catch a workflow whose p95 is creeping toward the host timeout:

requests
| where timestamp > ago(7d)
| where name has "workflow"
| summarize p50 = percentile(duration, 50),
            p95 = percentile(duration, 95),
            p99 = percentile(duration, 99)
            by bin(timestamp, 1h), name
| render timechart

The signals worth an alert, and what each catches before a partner notices:

Architecture at a glance

The diagram traces a B2B interchange end to end, left to right, through the real Standard architecture and marks each numbered failure point where a cutover actually breaks. A trading partner sends an X12 850 over AS2 to the logic app’s private trigger endpoint (a private endpoint on sites, with public access set to Deny). Inside the logic app on a WS-series plan, two workflows cooperate: a stateless intake workflow validates and hands off to a stateful EDI core that runs the in-process AS2/X12 decode, references the integration account for the partner agreement and 850 schema, generates the 997 functional ack, and writes order state. Because the workflow uses built-in connectors over VNet integration (WEBSITE_VNET_ROUTE_ALL=1 through a delegated /26 subnet), it reaches the private SQL and Service Bus endpoints that a managed connector never could. Underneath everything sits the run-history storage the runtime cannot live without — all four sub-resources (blob, file, table, queue) reached over private endpoints with vnetContentShareEnabled and the matching privatelink DNS zones.

Read the badges as the failure map for a go-live. Badge 1 is the storage trap: miss the table/queue endpoint or vnetContentShareEnabled and the app won’t start at all. Badge 2 is the managed-connector mistake: point the core at a private SQL through a managed connection and it silently can’t reach it. Badge 3 is the B2B SKU gate: a Basic integration account holds schemas but rejects the agreement, so decode fails. Badge 4 is the poison-message hazard: auto-complete left on means a bad interchange hot-loops instead of dead-lettering. Badge 5 is the slot footgun: swap without slot-sticky settings or per-slot VNet integration and you either leak staging creds into production or push the slot’s egress out of the VNet. The legend narrates each as symptom · confirm · fix.

Real-world scenario

Meridian Freight, a mid-size 3PL, ran EDI intake for retail trading partners on Logic Apps Consumption: AS2 receive, X12 850/856 decode, transform, and a write to an order database. Two engineers owned it; the monthly Logic Apps bill ran about ₹62,000 and nobody loved it. As a large retailer onboarded, two things broke at once. First, per-action billing on high-fan-out 850/856 processing — each interchange fanning into dozens of line-item actions — turned the bill into a number leadership started asking about, projected to roughly triple. Second, a new security baseline mandated that the SQL database holding order state become private-endpoint-only — which the Consumption tier’s managed SQL connector could not reach, because its traffic originates outside the customer’s network.

They migrated to Logic Apps Standard on a WS2 plan inside the platform’s hub-spoke VNet. The structural win was immediate on paper: the built-in SQL and Service Bus connectors run in-process and honour VNet integration, so order writes would flow over the private endpoint with no public exposure, and flat compute billing made the high-action EDI parsing essentially free at the margin. They kept their existing integration account (now unlinked, per the Standard model) for partner agreements and X12 schemas and moved AS2 decode in-process. They split the design: a stateless intake workflow for the AS2 receive and validation, calling a stateful core for decode, transform, ack generation, and the durable order write.

Then cutover went sideways in exactly the way this article warns about. The logic app would not start in the locked-down subscription — it sat in a restart loop with no useful application error. The storage account had been put behind private endpoints to meet the same baseline, but only the blob and file sub-resources had endpoints — the team had followed an App Service runbook. The Logic Apps runtime also needs table and queue storage for run history, and without vnetContentShareEnabled the content share would not mount. The fix was two pieces of infrastructure: private endpoints for all four sub-resources, and the site property flipped on.

// All four storage sub-resources need private endpoints for a Standard logic app
var storageGroups = [ 'blob', 'file', 'table', 'queue' ]

resource pe 'Microsoft.Network/privateEndpoints@2023-11-01' = [for g in storageGroups: {
  name: 'pe-${storageName}-${g}'
  location: location
  properties: {
    subnet: { id: privateEndpointSubnetId }
    privateLinkServiceConnections: [{
      name: 'conn-${g}'
      properties: {
        privateLinkServiceId: storageAccountId
        groupIds: [ g ]
      }
    }]
  }
}]

A second, subtler failure surfaced a week later during a routine deploy: a swap moved the staging Service Bus connection string into production because the setting was not marked slot-sticky, and for twenty minutes production wrote acks to the staging topic. No data was lost — the messages sat in staging — but a partner’s 997s were delayed and the incident bridge convened. The fix was to mark every connection and endpoint app setting as a deployment-slot (sticky) setting and to add VNet integration to the staging slot’s own subnet, which had also been missed.

With all four storage endpoints, the matching privatelink DNS zones linked, vnetContentShareEnabled=true, slot-sticky settings, and the slot integrated, the platform stabilised. Post-migration, EDI processing cost dropped by roughly two-thirds (to about ₹21,000), the private-network audit finding closed, and the next peak onboarding ran without a billing spike. The lesson the team wrote on the wall: “On Standard, the runtime’s own storage is a dependency you provision — and a slot is a second environment, not a copy.”

The cutover as a timeline, because the order of failures is the lesson:

Advantages and disadvantages

The single-tenant model both enables private, cost-efficient B2B and hands you the operational surface Consumption hid. Weigh it honestly:

The model is right for high-volume, private, B2B and event-driven integration where you want code-like CI/CD and durable processing. It is the wrong tool for a handful of runs a day against public SaaS — that’s Consumption’s home. The disadvantages are all manageable, but only if you know they exist before cutover, which is the entire point of the storage and slot sections above.

Hands-on lab

Stand up a Standard logic app, prove it’s a workflow app (not a plain function app), assign a managed identity, and confirm the runtime storage and VNet wiring — all scriptable in Cloud Shell (Bash). Teardown at the end. This uses a WS1 plan; for a zero-cost dry run you can substitute an existing dev subscription’s free credits.

Step 1 — Variables and resource group.

RG=rg-logicapps-lab
LOC=westeurope
PLAN=plan-la-lab
APP=la-lab-$RANDOM            # globally-unique hostname
SA=stlalab$RANDOM            # storage backs run history
az group create -n $RG -l $LOC -o table

Step 2 — Create the storage account and WS1 plan.

az storage account create -n $SA -g $RG -l $LOC \
  --sku Standard_LRS --kind StorageV2 --min-tls-version TLS1_2 \
  --allow-blob-public-access false -o table

az functionapp plan create -n $PLAN -g $RG -l $LOC --sku WS1 --is-linux false -o table

Expected: a plan row with sku.name = WS1.

Step 3 — Create the logic app and confirm its kind.

az logicapp create -n $APP -g $RG -l $LOC \
  --plan $PLAN --storage-account $SA --functions-version 4 -o table

az logicapp show -g $RG -n $APP --query kind -o tsv
# expect: functionapp,workflowapp

If you see functionapp without ,workflowapp, the workflow extension didn’t attach — recreate with --functions-version 4 and the workflow plan.

Step 4 — Assign a managed identity and grant it a data-plane role.

az logicapp identity assign -g $RG -n $APP -o table
PRINCIPAL=$(az logicapp identity show -g $RG -n $APP --query principalId -o tsv)
echo "Identity principalId: $PRINCIPAL"
# Grant it read on its own storage as a demonstration of keyless RBAC
az role assignment create --assignee $PRINCIPAL \
  --role "Storage Blob Data Reader" \
  --scope $(az storage account show -g $RG -n $SA --query id -o tsv) -o table

Step 5 — Force outbound through a VNet (the integration wiring).

az network vnet create -g $RG -n vnet-lab --address-prefixes 10.40.0.0/16 \
  --subnet-name snet-logicapps --subnet-prefixes 10.40.1.0/26 -o table

az network vnet subnet update -g $RG --vnet-name vnet-lab -n snet-logicapps \
  --delegations Microsoft.Web/serverFarms -o table

az functionapp vnet-integration add -g $RG -n $APP --vnet vnet-lab --subnet snet-logicapps -o table
az functionapp config appsettings set -g $RG -n $APP --settings WEBSITE_VNET_ROUTE_ALL=1 -o table

Step 6 — Verify the deployment behaves as designed.

# 1. Workflow app, not a plain function app
az logicapp show -g $RG -n $APP --query kind -o tsv                       # functionapp,workflowapp
# 2. Managed identity present
az logicapp identity show -g $RG -n $APP --query principalId -o tsv       # a GUID
# 3. Outbound routes through the VNet
az functionapp config appsettings list -g $RG -n $APP \
  --query "[?name=='WEBSITE_VNET_ROUTE_ALL'].value" -o tsv                # 1
# 4. VNet integration is attached
az functionapp vnet-integration list -g $RG -n $APP -o table             # one row

Step 7 — Teardown.

az group delete -n $RG --yes --no-wait

What each verification proves and what a failure means:

Common mistakes & troubleshooting

These are the failures that actually cost a Standard cutover its weekend. Scan the playbook, then read the detail for whichever row matches. The exact confirm command or blade is in the table — keep it open during go-live.

Cause 1 — The runtime can’t reach its own storage

The signature is a logic app stuck in a restart loop with no meaningful application error — because the failure is below your code. The runtime needs blob, file, table, and queue reachable. Teams that follow an App Service runbook create only blob and file and the app never starts.

Confirm. Count the private endpoints against the storage account:

az network private-endpoint list -g $RG \
  --query "[?contains(name,'$SA')].name" -o tsv   # expect 4 entries
az resource show -g $RG -n $APP --resource-type "Microsoft.Web/sites" \
  --query properties.vnetContentShareEnabled -o tsv  # expect: true

Fix. Create all four private endpoints, link the four privatelink DNS zones to the VNet, and set vnetContentShareEnabled=true. This is the two-line infrastructure fix from the scenario.

Cause 5 — A managed connector against a private target

A managed connector’s traffic originates from Microsoft’s connector service, not your integrated subnet, so it cannot reach a private endpoint — and the failure is a timeout, not a clear “blocked” message, which sends people hunting in the wrong place.

Confirm. Inspect connections.json — a managedApiConnections entry pointing at a private host is the smoking gun. Fix. Replace it with the built-in (service-provider) connector, which runs in-process and honours VNet integration. For SQL, Service Bus, Blob, Event Hubs, and Cosmos DB, a built-in exists.

Cause 8 — A poison message that won’t die

With auto-complete left on, an exception still completes the message in some flows, or — worse — the message is re-delivered and re-fails forever, pinning your consumer. The DLQ stays empty while the loop runs, which makes it look like nothing is wrong.

Confirm. Watch the Service Bus DLQ depth (zero while the loop runs) and the consumer’s failure rate (climbing). Fix. Turn off auto-complete so an exception abandons the message back to the queue; after max delivery count it lands in the DLQ, where a drain workflow triages it. This converts a hot loop into a parked message.

Best practices

Crisp, production-grade rules, each earned the hard way:

Security notes

The security posture for a private B2B pipeline has several non-negotiables:

Two specifics that bite: a managed connector that egresses from Microsoft’s network punches a hole in a “private-only” claim, so audit your connections.json for managed entries against private hosts; and a storage account left with allow-blob-public-access true undermines the whole private posture even with private endpoints in place — set it false explicitly. For the egress-control pattern, see Azure Firewall forced tunneling & hub-spoke routing.

Cost & sizing

The bill is driven by allocated compute, not actions — which is the whole reason high-fan-out EDI migrates here. The cost levers:

Right-sizing the plan by workload shape:

Indicative figures (West Europe; INR ≈ USD × 86, directional only):

The economic crossover versus Consumption: if your interchanges fan into many cheap actions, flat compute wins decisively (the scenario cut ~two-thirds). If you run a handful of times a day, Consumption’s per-action billing is cheaper — don’t pay for an idle WS plan. There is no free tier for production B2B; the Free integration-account SKU and dev plans are for experiments only.

Interview & exam questions

Model answers in 2–4 sentences. These map to AZ-305 (designing integration), AZ-204 (developing solutions), and integration-architect interviews.

1. Why is Logic Apps Standard not just “Consumption with a different SKU”? Standard runs the Logic Apps engine as an extension on the single-tenant Azure Functions host, so one resource hosts many workflows, billing is by allocated compute rather than per action, and built-in connectors run in-process. That gives you VNet integration, private inbound, slots, and code-like deployment — none of which Consumption’s multi-tenant model offers.

2. When does Consumption beat Standard on cost? When the workload runs infrequently — a handful of executions a day. Consumption’s per-action billing is near-free at low volume, whereas Standard charges for an always-allocated plan. Standard wins when high-fan-out workflows fire many cheap actions, because the marginal action is free.

3. Explain stateful vs stateless and when to use each. Stateful persists every run and action I/O to storage, giving durability, inspection, resubmit, and survival across host restarts — use it for orchestration, async, and EDI cores. Stateless runs in memory for low latency and high throughput with no durability — use it for short synchronous validate-and-forward edges, ideally fronting a stateful core.

4. Your Standard logic app won’t start in a locked-down subscription. First thing you check? Whether the runtime can reach its own storage. It needs private endpoints for all four sub-resources — blob, file, table, queue — plus vnetContentShareEnabled=true and the four privatelink DNS zones linked. Teams who provision only blob/file (an App Service habit) hit exactly this.

5. Why can’t a managed connector reach a private SQL database? Managed connectors execute on Microsoft’s multi-tenant connector infrastructure and egress from there, not from your integrated subnet, so they have no route to a private endpoint. Use the built-in (service-provider) SQL connector, which runs in-process on your plan and honours VNet integration.

6. How do you configure outbound vs inbound private connectivity? Outbound uses regional VNet integration through a delegated /26+ subnet, with WEBSITE_VNET_ROUTE_ALL=1 to route all egress (not just RFC1918). Inbound uses a private endpoint on the logic app’s sites group plus an access restriction with --default-action Deny.

7. What changed about integration accounts in Standard? The integration account no longer needs to be linked to the logic app — you reference partners, agreements, and schemas by name, and the old link step is gone. It must still be in the same subscription and region, and you must pick a SKU that supports agreements (Standard), since Basic holds artifacts but can’t trade.

8. Describe the three layers of error handling. Action-level retry policies handle transient dependency blips (tune them, set non-idempotent ops to none); try/catch via Scope + runAfter handles logical failures and compensation within a run; and broker-native dead-lettering handles poison messages across retries, parking a bad interchange instead of hot-looping the consumer.

9. What are the two slot footguns specific to Standard, and how do you avoid them? A swap moves app settings, so unmarked connection/endpoint settings can leak staging credentials into production — mark them slot-sticky. And a slot does not inherit VNet integration, so its outbound calls leave the VNet — integrate the slot’s own subnet.

10. How do you authenticate built-in connectors without secrets? Assign the logic app a managed identity and grant it least-privilege data-plane RBAC on each target (e.g. Service Bus Data Receiver, Storage Blob Data Contributor). The connection references the identity, so local.settings.json holds only endpoints — no keys to rotate.

11. Where do workflow runs and actions appear in Application Insights? Workflow runs surface as requests; individual actions appear as dependencies and traces, each tagged with the workflow and run identifiers via customDimensions. You query traces for failed actions and requests for run-latency percentiles.

12. What integration-account tier do you need for B2B transaction tracking? A Premium-level integration account. Standard supports full agreements and trading, but transaction-level B2B tracking surfaced through Azure Data Explorer is gated behind the Premium tier.

Quick check

1. Which two storage sub-resources do teams commonly forget to make private, causing a Standard logic app to fail to start?
2. What single app setting forces all outbound traffic (not just RFC1918) through the VNet?
3. Why can a managed connector not reach a private-endpoint-only Service Bus namespace?
4. Which integration-account SKU is the minimum for real X12/EDIFACT trading, and why isn’t Basic enough?
5. After a slot swap, production starts using the staging connection string. What did you forget to do?

Answers

1. table and queue. The runtime needs all four of blob, file, table, queue plus vnetContentShareEnabled=true; provisioning only blob/file (an App Service habit) leaves the app unable to start.
2. WEBSITE_VNET_ROUTE_ALL=1. With it at 0, only RFC1918 destinations route through the VNet and public targets bypass it.
3. Because a managed connector’s traffic originates from Microsoft’s multi-tenant connector infrastructure, not your integrated subnet, so it has no route to a private endpoint. Use the built-in Service Bus connector instead.
4. Standard. Basic stores artifacts (schemas, maps) but does not support agreements, and you cannot decode/encode X12/EDIFACT against a partner without an agreement.
5. You forgot to mark the connection/endpoint app settings as slot-sticky (deployment-slot settings), so the swap moved staging’s value into production.

Glossary

Next steps

• Go deeper on the messaging backbone in Azure Service Bus sessions, dedup & dead-letter patterns.
• Compare this with code-first orchestration in Azure Durable Functions orchestration patterns.
• Master the private-networking layer in private endpoints & private DNS at scale and private endpoint vs service endpoint.
• Tie keyless auth together with Azure Key Vault secret rotation with managed identity.
• Build the trading-partner side end to end in the EDI/B2B integration platform on Logic Apps.