Before settings and diagrams, we need a clear picture of what kind of service this is, and where it fits among Azure’s many ways to run logic.

The short definition

Azure Logic Apps is a cloud service for creating and running automated workflows that connect apps, data, services, and systems. A workflow is a series of steps that starts with one trigger, which is the event that begins a run, and then performs actions, which are the steps that do the work. Logic Apps belongs to the family called integration platform as a service, meaning that Microsoft runs the platform, the scaling, and the patching, while you focus on the flow of business logic.

Two things make it special. First, it is designed with a visual designer, so many workflows can be built by dragging steps rather than writing programs. Second, it offers a very large catalogue of connectors, prebuilt pieces that talk to services such as email systems, databases, queues, storage, enterprise applications, social media, and software-as-a-service products. You can often connect two systems in minutes without learning either one’s programming interface.

What kinds of work suit it

Logic Apps is a strong fit when the job is to move, transform, or react to data across systems: processing messages from queues, syncing records between a customer system and a database, sending approvals and notifications, receiving files from partners, calling web interfaces on a schedule, or orchestrating several steps with waits and decisions. It also handles long-running processes, since a workflow can pause for days while waiting for an approval or a reply, without holding a server.

What it is not

Logic Apps is not a general programming platform. Heavy calculation, complex algorithms, and very low-latency request handling belong in code, for example in Azure Functions or a web application. Logic Apps can call such code, and the two are often used together. It is also not a database or a message broker, though it works closely with them. And it is not the same as Power Automate, which is built on the same ideas but is aimed at business users inside Microsoft 365 and the Power Platform, while Logic Apps is aimed at developers and integration teams working in Azure.

Why it matters to the business

Manual hand-offs between systems are slow, error-prone, and invisible. Someone copies data from an email into a spreadsheet, another person re-types it into a finance system, and nobody can say how long it took or where it stalled. Automated workflows shorten that journey, remove typing mistakes, and leave a complete record of every step. Teams recover hours each week, customers get faster answers, and managers gain a clear view of how work actually flows through the organisation.

A handful of terms appear in every conversation about Logic Apps. Learn them once and the rest of the guide becomes easy to read.

The anatomy of a run

Each run begins with the trigger’s output, which becomes data that later steps can read. Every action records what it received and what it returned, and these records form the run history. A step can use the output of any earlier step by name, so data flows down the workflow like water down a series of pools. If a step fails, the run records the failure, and the workflow can be designed to catch it, retry, or take another route.

Designer view and code view

Workflows are stored as a definition in a structured text format. The designer shows that definition as boxes and arrows, and a code view shows the text itself. Most people work visually, while advanced users switch to the code view for precise control, bulk edits, or source control. Because the definition is just a file, it can be reviewed, versioned, and deployed like any other artifact, a point that matters greatly for teams.

Naming that helps the next person

Good names are the cheapest documentation. Name workflows after the business outcome, such as process incoming invoices, not after the tool or the author. Rename each step to say what it does, such as get customer record or send approval request, instead of leaving default labels. Names appear in run history, logs, and alerts, so clear names make troubleshooting faster and let support staff understand a failure without opening the designer.

Under the friendly boxes there is a runtime engine, a connector layer, and a place where state is kept. Knowing these parts explains most behaviour you will see.

The runtime engine

The runtime reads the workflow definition, waits for the trigger, and executes actions in the order and conditions defined. It manages parallel branches, loops, waits, retries, and timeouts. For long waits, it saves its state, releases resources, and resumes when the time comes or the event arrives. This is why a workflow can wait three days for an approval at almost no cost.

The connector layer

Connectors come in two broad families. Built-in connectors run inside the workflow runtime itself, close to the engine, which makes them fast and, in the Standard model, able to use private networks. Managed connectors run as separate shared services hosted and maintained by Microsoft; the workflow calls them over the network using stored connections. Custom connectors let you wrap your own web interface so that it appears like any other connector. Chapter 6 covers the differences.

State and run history

For stateful workflows, the runtime saves the inputs and outputs of each step in storage. In the multitenant model, Microsoft manages this storage. In the Standard model, it uses an Azure Storage account that you provide, which is why storage choices affect cost and performance there. The saved state enables run history, resubmitting failed runs, long waits, and reliable recovery after failures. Stateless workflows skip this and run in memory for speed, which has trade-offs described in Chapter 7.

flowchart TD
    EV[Event or schedule] --> TR[Trigger]
    subgraph RT[Workflow runtime]
        TR --> A1[Action one]
        A1 --> C1{Condition}
        C1 -->|Yes| A2[Action two]
        C1 -->|No| A3[Action three]
        A2 --> SC[Scope with error handling]
        A3 --> SC
    end
    A1 --> BC[Built-in connector in runtime]
    A2 --> MC[Managed connector service]
    A3 --> HTTP[Web interface or custom connector]
    RT --> ST[State and run history storage]
    MC --> EXT[External systems]
    BC --> EXT
    HTTP --> EXT
        

The management layer

Around the runtime sits the Azure management layer. Through Azure Resource Manager you create logic apps, set access roles, configure diagnostic logs, and deploy templates. The same layer controls identity, networking settings, and policy. The designer in the portal, the extension in Visual Studio Code, and automation pipelines all talk to this layer, which is why a workflow built in one place can be edited in another.

How a request travels

sequenceDiagram
    participant C as Caller or event source
    participant T as Trigger
    participant R as Runtime
    participant X as Connector
    participant S as Target system
    participant H as Run history
    C->>T: Event or request arrives
    T->>R: Start run with trigger data
    R->>X: Execute action with connection
    X->>S: Call the target system
    S-->>X: Response
    X-->>R: Output data
    R->>H: Record inputs and outputs
    R-->>C: Response, if the design returns one
        

Scaling out and in

The runtime handles load by running many workflow instances at once. In the multitenant model, the platform adds capacity behind the scenes, within published limits. In Standard, instances of the hosting plan are added or removed according to the plan settings and the number of events waiting. Because runs are independent, most workflows scale well, provided their targets can keep up. The limiting factor is usually the slowest system the workflow calls, not the workflow engine itself.

The building blocks look simple, yet the choices you make about them decide how fast, cheap, and dependable your workflow will be.

Choosing a trigger

Every workflow starts with exactly one trigger. Triggers fall into a few styles. A recurrence trigger starts on a schedule, such as every hour, and suits batch jobs. A request trigger gives the workflow its own web address that callers can send messages to, and suits workflows exposed as small interfaces. A polling trigger checks a service regularly for new items, such as new rows in a table or new messages in a mailbox. A push trigger registers with a service and is called when something happens, so there is no waiting and no wasted checks. Wherever possible, prefer push triggers, because polling creates delay and charges for checks that find nothing.

Actions and data

Actions fall into groups: calls to connectors, calls to arbitrary web interfaces, data operations such as composing, parsing, selecting, and filtering, variable operations, and calls to other workflows or to code such as functions. Data operations are especially valuable, because they let you reshape arrays and objects between systems without writing code. Parsing a message against a schema gives later steps friendly named fields instead of raw text.

Control flow

Expressions

Expressions are short formulas written in a workflow language. They combine functions for text, dates, numbers, collections, logic, and conversion, and they can read the outputs of earlier steps. Most workflows need only a handful: formatting a date, checking whether a field is empty, joining pieces of text, or picking the first item from a list. Keep expressions short and readable. If an expression grows long, split it into several named steps or move the logic into code, since the next person to maintain it will thank you.

Loops need care

Loops are powerful and dangerous. A for-each over a list of ten thousand items, each making a web call, can run for a long time, hit rate limits at the target, and produce huge run histories. Limit the size of lists before looping, use parallelism carefully with the target’s limits in mind, and consider handing batches to a queue instead. Always keep in mind the documented ceilings for items per loop and nested depth, which differ between hosting models.

flowchart TD
    T[Trigger: new order message] --> P[Parse message]
    P --> C{Order value above limit}
    C -->|Yes| AP[Send approval and wait]
    C -->|No| OK[Mark as approved]
    AP --> D{Approved}
    D -->|Yes| OK
    D -->|No| REJ[Notify customer and stop]
    OK --> LOOP[For each order line]
    LOOP --> INV[Reserve stock]
    INV --> LOOP
    LOOP --> DONE[Send confirmation]
        

Trigger conditions and early filtering

Not every event deserves a run. Many triggers accept a condition that is checked before a run starts, so messages that do not match are ignored at no action cost and without cluttering history. For example, start only for invoices above a certain amount or only for messages with a particular label. Filtering at the trigger is the cheapest and clearest way to keep workflows focused, and it keeps run counts, bills, and dashboards honest.

The hosting model is the biggest design decision. It shapes cost, networking, tooling, and how many workflows you can run together.

Consumption

In the Consumption model, each logic app contains exactly one workflow and runs on shared, multitenant infrastructure managed by Microsoft. You pay for what runs: executions of triggers and actions, with the price depending on the kind of operation. It scales automatically and needs almost no setup, which makes it excellent for small, occasional, or unpredictable workloads and for quick experiments. Its limits are fewer controls over networking, shared outbound addresses, and one-workflow-per-resource packaging.

Standard

The Standard model hosts many workflows inside one logic app resource, which share the same compute, storage, and network settings. It runs on a single-tenant runtime, meaning your own instances rather than a shared pool. You pay for the hosting plan you choose, not per action, and stateful workflows also incur storage transaction costs. Standard offers dedicated outbound addresses, virtual network integration, private endpoints, local development in Visual Studio Code, a broader set of built-in connectors, and both stateful and stateless workflow types. It suits steady, high-volume, or security-sensitive workloads and teams that treat workflows as software projects.

App Service Environment and hybrid

Standard can also run in an App Service Environment version 3, a fully isolated and dedicated environment in your own virtual network, which suits strict isolation and compliance needs. A hybrid option lets Standard workflows run on infrastructure you operate, such as on-premises or in another cloud, with their own pricing, for cases where data or systems cannot leave a location. The older Integration Service Environment, a dedicated option for the previous generation, was retired on 31 August 2024, and Microsoft directed its customers to Standard.

flowchart TD
    START[New automation need] --> Q1{Private network or fixed addresses needed}
    Q1 -->|Yes| STD[Standard]
    Q1 -->|No| Q2{Many related workflows or high steady volume}
    Q2 -->|Yes| STD
    Q2 -->|No| Q3{Small, occasional, unpredictable}
    Q3 -->|Yes| CON[Consumption]
    Q3 -->|No| Q4{Need local development and CI pipelines}
    Q4 -->|Yes| STD
    Q4 -->|No| CON
    STD --> Q5{Strict isolation or on-premises placement}
    Q5 -->|Isolation| ASE[App Service Environment v3]
    Q5 -->|On-premises| HYB[Hybrid deployment]
        

Cost in practice

A rough rule is that Consumption wins at low or spiky volume, because you pay nothing when idle, while Standard wins as volume grows and becomes steady, because fixed hosting cost spreads across many runs. Do the calculation with your real number of actions per month using the official pricing calculator, since prices differ by region and change. Remember to include storage, networking, and monitoring in the Standard comparison.

Moving between models

There is no one-click switch between Consumption and Standard, because the resource models differ. Tools and guidance exist to export workflows and rework connections, but plan the move like a small project and test thoroughly. This is a reason to choose carefully at the start and to keep workflows small and well documented.

Connectors are the reason Logic Apps is quick to use. Knowing the kinds, and how each signs in, saves hours of confusion.

Built-in connectors

Built-in connectors run in the same process as the workflow engine. They are fast, can be more efficient to run, and in the Standard model can reach private resources through the app’s network. Standard offers a rich built-in set, including connectors for blob storage, queues and topics, event streaming, databases, file transfer, and message queuing products, in addition to core operations such as requests, schedules, data operations, and variables. You can even write custom built-in connectors for the Standard runtime when you need more control.

Managed connectors

Managed connectors are hosted by Microsoft as separate shared services. They cover a very wide range of services, from Microsoft 365 and databases to enterprise applications and social tools. Workflows call them over the network using a stored connection that holds the sign-in. Because they run outside your app, they have their own throttling limits, and they may be reached through public paths, which matters for strict networks. Some are labelled standard and some premium, which affects pricing.

Custom connectors

If a service you need has no connector, you can create a custom connector by describing its web interface. Once defined, it appears in the designer like any other, with named operations and parameters. Custom connectors are useful for internal services, because they hide technical details from workflow authors and give them clean, tested building blocks.

How connections authenticate

Each connection stores how the workflow signs in to the service. Options include a user account signing in interactively, a service principal, a managed identity, a shared key or connection string, or an API key. Interactive user sign-in is convenient but ties the workflow to a person, which breaks when that person leaves or their password changes. For production, prefer a managed identity or a service account designed for automation, with the narrowest permissions the workflow needs.

Reusing connections

In the Standard model, connections are shared across the workflows in a logic app, which reduces duplication. Name connections after their purpose and target, and avoid personal accounts. When a connection breaks, every workflow that uses it fails together, so monitor connection health and set alerts on repeated authentication failures.

Choosing connectors wisely

Before using a connector, read its reference page: the operations it offers, the sign-in methods, the throttling limits, the pricing class, and any known issues. Prefer connectors maintained by the service owner, and be careful with preview connectors in production. When a connector lacks a feature you need, a direct call to the service’s web interface using the HTTP action, authenticated with a managed identity, is often a clean alternative.

Systems fail in small ways all the time. A reliable workflow expects failure and has a plan for it.

Stateful and stateless workflows

In the Standard model you choose, when creating a workflow, whether it is stateful or stateless, and you cannot safely change it afterwards. A stateful workflow saves the inputs, outputs, and progress of each step to storage. This gives full run history, the ability to resume after a restart, resubmission of failed runs, long waits, and processing of large messages. A stateless workflow keeps everything in memory, runs faster and cheaper, and does not store history, which makes it best for short, quick, request-and-response flows. Stateless workflows allow only push-style triggers, are best kept under about five minutes and small payloads, and have lower limits for some loops and variables.

Retry policies

Most actions that call other services have a retry policy. The default usually tries a few times with pauses between, so a brief outage of the target passes unnoticed. You can change the policy to none, a fixed interval, or an exponential back-off, with limits on counts and total time. Retry only things that are safe to repeat, and set sensible limits: ten retries with long pauses may keep a failing call alive for hours and hide a real problem.

Idempotency: safe to repeat

Because retries, duplicate triggers, and resubmissions can repeat a step, steps that change data should be idempotent, meaning that doing them twice has the same result as doing them once. Use unique identifiers from the source message, check whether the work was already done, and prefer operations such as upsert over blind insert. This one habit prevents double charges, duplicate emails, and double bookings.

Catching failures: run after and scopes

Each action has a run-after setting that says which results of the previous step trigger it: succeeded, failed, skipped, or timed out. By grouping steps into a scope and adding a following step that runs only when the scope failed, you create the equivalent of a try-and-catch block. In the catch branch you can log the error, send a notification, put the message on a dead-letter queue, or call a compensation workflow. A final step that runs regardless can act as a finally block.

flowchart TD
    T[Trigger] --> TRY[Scope: main work]
    TRY -->|Succeeded| OK[Confirm and finish]
    TRY -->|Failed or timed out| CATCH[Scope: handle error]
    CATCH --> LOG[Log error details]
    LOG --> DLQ[Send message to a holding queue]
    DLQ --> ALERT[Alert the owner]
    OK --> FIN[Final cleanup step]
    ALERT --> FIN
        

Timeouts and long operations

Web calls have time limits, which differ by hosting model, and a caller waiting for a response will give up after its own timeout. For operations that take longer, use an asynchronous pattern: the first call returns quickly with a status address, and the workflow either polls it or receives a callback when the work is done. Workflows themselves can run for many days in stateful mode, but history retention should be kept at least as long as the longest run, or history may vanish before a run ends.

Dead letters and manual repair

Not every failure can be fixed by a machine. Plan a place where failed messages wait for a person: a queue, a table, or a ticket. Give operators a simple way to resubmit a failed run after the cause is fixed. Resubmission from run history is built in for stateful workflows, which is one reason they are the default for important flows.

Concurrency and ordering

When several messages arrive together, the runtime may process them in parallel, so results can finish out of order. If order matters, such as updates to the same customer, limit concurrency to one for that stream or group related messages by key using sessions. If order does not matter, allow parallel runs for speed. Decide this early and document it, because changing concurrency later can change behaviour in ways that surprise downstream systems.

Most workflows are variations of a few well-known shapes. Recognising the shape tells you the right design immediately.

Pattern 1: Request and response

A caller sends a request, the workflow does a few quick steps, and returns a response. It is best for small interfaces that combine several calls into one. Keep it fast, because callers wait, and use stateless Standard workflows when response time matters most. If the work can take long, switch to the asynchronous pattern.

Pattern 2: Asynchronous request with callback

The caller receives an immediate acknowledgement with a tracking address. The workflow does the work in the background and either lets the caller poll the status or calls a callback address when finished. This avoids timeouts and suits long jobs such as report generation or document processing.

sequenceDiagram
    participant C as Caller
    participant W as Workflow
    participant J as Long job
    C->>W: Submit request
    W-->>C: Accepted with status address
    W->>J: Start background work
    C->>W: Check status
    W-->>C: Still running
    J-->>W: Finished with result
    W->>C: Callback with result or status becomes complete
        

Pattern 3: Queue-based load levelling

Messages arrive in a queue and the workflow processes them at its own pace. The queue absorbs bursts, protects slow targets, and lets failed messages return for another try. This is the most dependable pattern for integration, and Logic Apps has strong connectors for queues and topics. Use sessions or ordering features if order matters, and design for duplicates since most queues deliver at least once.

Pattern 4: Fan-out and fan-in

One message triggers several parallel tasks, such as sending an order to billing, shipping, and analytics, and then a later step collects results. Parallel branches or separate child workflows do the work. Be careful with partial failure: decide what happens if two of three succeed.

Pattern 5: Approval and human in the loop

The workflow sends a request for approval, then waits, possibly for days, until someone responds or a timeout passes. Include a reminder, an escalation, and a default action on timeout. Because stateful workflows release resources while waiting, this costs almost nothing.

Pattern 6: Saga and compensation

When a business process spans several systems that cannot share one database transaction, you cannot simply roll everything back. Instead, each step has a compensating step that undoes its effect, such as cancelling a booking. If a later step fails, the workflow runs the compensations for the earlier ones. This is a saga. It needs careful design, but it is the honest answer to distributed processes.

Pattern 7: Scheduled batch with checkpoint

A recurrence trigger starts a job that processes new records since the last run. A saved checkpoint, such as the time or identifier of the last processed record, ensures nothing is skipped or repeated, even if a run fails and the next one catches up.

Keeping contracts stable

Workflows that call each other, or that expose request interfaces, form contracts with their callers. Define the shape of requests and responses with schemas, version them, and change them in compatible ways: add optional fields, avoid renaming or removing existing ones, and keep old versions alive until callers have moved. A small effort on contracts prevents the chain reactions that happen when one team changes a message and ten other workflows begin to fail.

Logic Apps grew up in enterprise integration. It can exchange formal business documents with partners and bridge old systems with new ones.

Integration accounts and B2B

For business-to-business exchange, Logic Apps uses an integration account, a container for partners, agreements, schemas, certificates, and maps. With it, workflows can receive and send documents in standard formats widely used in trade, such as EDI formats like X12 and EDIFACT, and protocols like AS2. Operations include decoding and encoding messages, validating them against schemas, generating acknowledgements, and tracking message status. The Standard model reduces the need for an integration account for some operations, such as simple XML and Liquid transforms, where artifacts are uploaded directly to the logic app, but a full B2B setup still uses partners and agreements.

Transformations

Systems rarely agree on field names or structure. A map converts a message from one shape to another. XML-based maps use a transformation language, Liquid templates transform JSON and text, and data operations inside the workflow handle simpler reshaping. Keep maps in source control, test them with sample messages, and version them with the workflows that use them, so a change to a map is reviewed like code.

Reaching on-premises systems

Many companies still keep databases and applications in their own data centres. There are several ways in. The on-premises data gateway is an agent installed inside the network that lets managed connectors reach local systems through an outbound secure channel. In the Standard model, virtual network integration with a private route, such as a VPN or dedicated circuit, lets built-in connectors reach local servers directly. Hybrid deployment can run the workflow runtime itself near the systems. Choose by latency, security rules, and operations effort.

flowchart LR
    P1[Partner one via AS2] --> LA[Logic Apps Standard]
    P2[Partner two via file transfer] --> LA
    LA --> DEC[Decode and validate documents]
    DEC --> MAP[Transform with maps]
    MAP --> ERP[On-premises ERP through private network or gateway]
    MAP --> BUS[Message queue for internal systems]
    LA --> ACK[Acknowledgement back to partners]
    ACK --> P1
    ACK --> P2
        

Working with files and large messages

Messages and files have size limits per action, though chunking can raise the practical limit for some connectors. For large files, avoid passing the content through the workflow at all: store the file in blob storage and pass only its address between steps, letting each system fetch it directly. This pattern, sometimes called the claim check, keeps workflows light and avoids memory and limit problems.

Working with other Azure services

Designing for partner change

Partners change their formats, add fields, and switch versions, often with little warning. Protect yourself with strict validation at the border, clear error reports back to the partner, and versioned schemas and maps. Keep a library of real sample documents from each partner, including awkward ones, and run them through your maps whenever anything changes. A short onboarding checklist for new partners, covering identifiers, certificates, formats, and test exchanges, saves weeks of back and forth.

Logic Apps now includes ways to let AI models decide what to do next, using the same connectors and safeguards that ordinary workflows use.

What an agent workflow is

In Logic Apps Standard, an agent workflow contains an agent action, often described as an agent loop. The loop connects a language model to a set of tools, which are actions the agent may call. The model reads the goal and the context, chooses a tool, receives its result, and repeats until it decides the goal is met or it needs help. Microsoft announced general availability of Agent Loop in Logic Apps Standard in November 2025, along with further AI features that were in public preview at that time. Features in preview can change, so confirm their status before relying on them.

Autonomous and conversational agents

Autonomous agents start from a trigger, such as a new support ticket or an incoming document, work on their own, and finish with an outcome. Conversational agents interact with a person in a chat, answering questions and carrying out requests using tools. Both can include a human approval step before sensitive actions.

Tools, knowledge, and models

Tools are the actions the agent is allowed to use: look up a customer, create a ticket, send an email, call an internal interface. Each tool is limited by the connection’s permissions, so an agent cannot do more than its tools allow. Models are provided through Azure’s AI services, and your instructions to the agent, called a system prompt, define its role, rules, and tone. Knowledge can be supplied by searching your documents so that answers are grounded in your content instead of guessed.

flowchart TD
    TRG[Trigger: new support ticket] --> AG[Agent loop with goal and instructions]
    AG --> M[Language model decides next step]
    M --> T1[Tool: look up customer]
    M --> T2[Tool: search knowledge base]
    M --> T3[Tool: draft reply]
    T1 --> M
    T2 --> M
    T3 --> M
    M --> H{Sensitive action}
    H -->|Yes| APR[Human approval]
    H -->|No| ACT[Take action]
    APR --> ACT
    ACT --> LOG[Record steps in run history]
        

Safe use of agents

When not to use an agent

If the steps are known and fixed, a plain workflow is cheaper, faster, and more predictable. Use agents where the path varies with the content, such as reading free-form text and deciding the next step. Mix the two: a plain workflow for the reliable skeleton and an agent step where judgement is needed. Also remember that models can make mistakes and that costs depend on usage, so measure quality and cost during a pilot.

Measuring agent quality

An agent is only as good as the evidence that it works. Before launch, build a set of real examples with known good outcomes and run the agent against them, scoring accuracy, tool choices, and tone. After launch, sample live runs for review every week, track how often humans override the agent, and watch cost per case. When quality drifts, adjust instructions, tools, or knowledge sources, and rerun the examples. Treat the agent like a new employee on probation, with supervision that gradually relaxes as trust is earned.

Workflows hold the keys to many systems and handle sensitive data. They deserve the same security care as any production application.

Who can call the workflow

Request-triggered workflows have a web address that includes a signature, a long secret token in the address. Anyone holding the full address can call the workflow, so treat it like a password: do not paste it into chat or code, and rotate it if exposed. For stronger control, restrict allowed caller addresses, require Microsoft Entra authorisation where supported, and place a gateway such as API Management in front to add checks. In the Standard model, some authentication options for request triggers differ from those in the Consumption model, so check the current feature notes.

Who can change the workflow

Azure role-based access control governs who can create, edit, run, and view logic apps. Roles such as Logic App Contributor and Logic App Operator separate people who build from people who only monitor or rerun. Give developers rights in development, but in production allow changes only through pipelines. Restrict who can read run history, since it may expose data.

What the workflow can reach

Managed identities let a workflow authenticate to Azure services and to any interface that accepts Entra tokens, with no stored secret. A system-assigned identity belongs to one logic app, while a user-assigned identity can be shared. Grant the identity only the roles it needs on specific resources. Where a secret is unavoidable, such as a vendor key, keep it in Key Vault and reference it, never typing it into a step. In Standard, app settings that point to Key Vault references keep secrets out of workflow definitions.

Securing inputs and outputs

Each step can be marked to hide its inputs, its outputs, or both from the run history. Use this for steps that handle passwords, tokens, personal data, or payment details. Parameters of type secure string are also hidden. Remember that data passed to later steps can still appear there, so mark each step that touches sensitive values. Also think about logs sent to monitoring: the content that is visible in history may be copied to other stores depending on your diagnostic settings.

Connector governance

Organisations can use Azure Policy to control which connectors are allowed or blocked, so that, for instance, a workflow cannot send data to a social media connector. Combine this with network controls on outbound traffic and with reviews of new custom connectors. Governance is the difference between a platform that empowers people and one that quietly leaks data.

flowchart TD
    CALLER[Caller] --> GW[API gateway with authentication]
    GW --> WF[Workflow]
    WF -->|Managed identity| AZ[Azure services]
    WF -->|Secret from Key Vault| EXT[External service]
    WF --> HIST[Run history with secured inputs and outputs]
    ADM[Administrator through pipeline] --> WF
    POL[Policy] -->|Allowed connectors and settings| WF
    HIST --> LOGS[Logs with restricted access]
        

Many integrations must stay off the public internet. The hosting model you chose decides what network controls you have.

Multitenant: shared addresses

In the Consumption model, outbound calls come from a published range of shared addresses used by many customers. Target systems that want to allow only your traffic must allow that whole range, which is wide. Inbound calls reach a public address. Options for private access are limited, so for strict network needs, Standard is usually the better home.

Standard: dedicated and private

Standard offers virtual network integration for outbound traffic, so workflows can reach resources inside your network and through it to on-premises systems. Private endpoints for inbound traffic let callers inside your network reach the workflow on a private address, with public access disabled. A network address translation gateway can give outbound traffic a fixed public address that targets can allow. Built-in connectors respect these settings, while managed connectors run outside the app and follow their own paths.

flowchart LR
    subgraph VN[Your virtual network]
        CL[Internal caller] --> PE[Private endpoint]
        PE --> LA[Logic Apps Standard]
        LA --> SUB[Integration subnet]
        SUB --> DB[Database with private endpoint]
        SUB --> ST[Storage with private endpoint]
    end
    LA -->|Fixed outbound address| EXT[Partner service allowing that address]
    ONP[On-premises systems] -->|VPN or private circuit| SUB
    NET[Public internet] -.->|Blocked| LA
        

Storage and dependencies

Standard needs an Azure Storage account for workflow state. If you lock down that account with a firewall or private endpoints, the logic app must be able to reach it through its network integration. Many first-time deployment failures come from forgetting this, or from private DNS zones that do not resolve storage names properly. Plan the storage account, its endpoints, and its DNS together with the logic app.

Reaching on-premises

Name resolution and testing

Private connectivity depends on correct name resolution. If the name of a service resolves to its public address from inside the network, traffic may be blocked or leave the network. Test from within the same network and integration subnet, and record the expected address for each dependency. Document the path of each dependency end to end, so the next person can debug it.

Documenting the network path

For every dependency of a logic app, write down the name, the expected private address, the route, the firewall rules, and the DNS zone involved. Keep this beside the infrastructure code. When a connection fails at night, the on-call engineer can follow the document from the workflow to the target and find the break quickly. The same document helps security reviewers confirm that no hidden public path exists and helps new team members understand how the pieces connect.

Workflows are software. Treat them with source control, review, testing, and automated release, and they become much safer to change.

Where you build

The portal designer is great for learning and quick edits. For serious work, teams use Visual Studio Code with the Azure Logic Apps extension for the Standard model. It allows local building, running, and debugging on a developer’s machine, with breakpoints on actions, and keeps all files in a normal project folder suitable for source control. Consumption workflows can also be built in Visual Studio Code or exported as templates for source control.

Parameters and environments

The same workflow must run in development, test, and production with different addresses, names, and secrets. Use parameters and app settings for such values and keep environment-specific values outside the workflow definition. In Standard, connection details and settings can be defined per environment and supplied by the pipeline. Avoid hard-coding addresses inside steps, because a copy to production then silently calls the test system.

Infrastructure as code and release pipelines

In Standard, infrastructure and application are deployed separately. Templates in languages such as Bicep or ARM, or tools such as Terraform, create the logic app, storage, networking, identity, and monitoring. The workflow files are then packaged and deployed to the app through a pipeline. In Consumption, a single template deploys the logic app and its definition together. In both cases, store everything in version control, review changes by pull request, and promote through environments using the same artifact.

Testing workflows

Test at several levels. Unit-style tests run single workflows with mocked responses from connectors, which is possible with testing features for Standard. Integration tests call real test systems. Load tests check behaviour under volume. Contract tests ensure that changes in maps and schemas do not break partners. Keep sample messages in the repository, including malformed ones, because real traffic eventually sends them.

Safe release techniques

Because a trigger starts runs automatically, deploying a new version while runs are in flight needs thought. Stateful runs in progress continue with the definition they began with in many cases, but changes that affect shapes of stored data can break them. Disable the trigger briefly, let inflight runs finish, deploy, and then enable. For critical flows, run old and new side by side with a queue split, or use deployment slots in the Standard model where supported, and keep a rollback plan.

Managing connections in pipelines

Connections are a frequent source of release problems, because they hold sign-in details that differ per environment. Define connections as code, use managed identities so that no secret needs to move, and have the pipeline create or update them in each environment before workflows are deployed. After deployment, run a smoke test that calls each connection once. Catching an unauthorised connection during release is far better than discovering it when the first real message arrives.

A workflow that fails quietly is worse than one that fails loudly. Build visibility in from the first day.

Run history

The first place to look is the run history, which lists runs with status, start time, and duration. Opening a run shows each step with its inputs and outputs, in green for success and red for failure, so you can see where data went wrong. For stateful workflows you can resubmit a failed run from the history once the cause is fixed. History is kept for a limited time, commonly ninety days by default, and the retention can be adjusted within limits, so export what you need for longer.

Diagnostic logs and metrics

Diagnostic settings send detailed workflow logs and metrics to Log Analytics, storage, or an event hub. Records show runs, triggers, and actions with their status and timing, and can carry tracked properties that you define, such as an order number, so you can search for all activity related to one business item. Metrics show counts of runs, failures, latency, and throttled calls, which feed charts and alerts.

Application Insights for Standard

Standard integrates with Application Insights, which collects telemetry from the runtime, including requests, dependencies, exceptions, and performance counters. It helps find slow connectors, retries, and memory pressure, and it can follow a request through several workflows and functions using correlation. Enable it at creation, and watch the volume, since detailed telemetry costs money.

flowchart LR
    WF[Logic app workflows] --> RH[Run history]
    WF --> DS[Diagnostic settings]
    WF --> AI[Application Insights]
    DS --> LA[Log Analytics workspace]
    AI --> LA
    LA --> AL[Alert rules]
    LA --> WB[Workbooks and dashboards]
    AL --> AG[Action groups to teams and tickets]
    RH --> RES[Resubmit failed runs]
        

Alerts worth having

Troubleshooting checklist

Tracked properties and business visibility

Technical logs tell engineers what happened, but business teams ask different questions: where is order 4512? Add tracked properties such as customer or order numbers to key steps and build a workbook that lets support staff search by those numbers. This turns the run history from an engineer’s tool into a shared view of the process and reduces interruptions.

Building a runbook

Write a short runbook for each important workflow. It should name the owner, say what the workflow does, list its triggers and targets, show where to find its run history and logs, explain the top three failure causes and their fixes, describe how to resubmit failed runs safely, and say whom to call when the fix is not obvious. Review the runbook after every incident. A good runbook turns a stressful guess at two in the morning into a calm checklist.

Logic Apps scales well, but every part of the chain has limits. Knowing them early prevents painful surprises.

Where limits come from

Limits arise at four levels: the workflow itself, the hosting platform, each connector, and the target systems. The documentation lists values for each hosting model. Examples at the time of writing include a default of ninety days for run duration and history retention in stateful workflows, a cap of five hundred actions per workflow, a nesting depth of eight, a limit of one trigger per workflow in the designer, and a cap of one hundred thousand items for a for-each loop in stateful and multitenant workflows, with a much lower cap for stateless ones. Message sizes are capped at about one hundred megabytes for ordinary content, with chunking available for some operations. Web call timeouts are around two minutes for multitenant and a little under four minutes by default for single-tenant. Always check the current limits page before designing for large scale.

Concurrency control

Triggers can start many runs at once, and loops can process items in parallel. By default, concurrency settings are conservative or off. You can raise the number of parallel runs or iterations, within limits, to increase throughput, but you must make sure the targets can cope. Turning on trigger concurrency is a one-way change for that trigger, and it cannot simply be turned back off, so test first. For ordered processing, keep concurrency at one and use message sessions.

Throughput in the multitenant model

Consumption has platform-wide throughput limits per workflow, counted in action executions and content volume per five-minute window, with a high-throughput mode available as a preview option for workloads that need more. Calls to the same connector connection are throttled separately. If you approach these limits, split the workload across several logic apps, use queues to smooth bursts, or move to Standard.

Scaling in Standard

Standard scales by adding instances of the hosting plan. Depending on the plan type, scale can be automatic, driven by the number of events waiting, or manual. Stateful workflows depend on the storage account for throughput, so a busy app may need a premium or well-provisioned storage account and separate storage for heavy workloads. Monitor instance counts, processor use, memory, and storage latency. Workflows in the same app share resources, so one very busy workflow can slow its neighbours. Put critical or noisy workflows in separate apps.

flowchart TD
    SLOW[Throughput too low] --> A{Where is the bottleneck}
    A -->|Target system slow| T1[Add caching, queues, or limit concurrency]
    A -->|Connector throttled| T2[Spread across connections or reduce call rate]
    A -->|Workflow serial| T3[Enable parallelism or split into child workflows]
    A -->|Platform limits| T4[Split workflows across apps or move to Standard]
    A -->|Storage latency in Standard| T5[Use faster storage or separate storage accounts]
        

Performance habits

At scale, Logic Apps needs budgets, naming, ownership, and a plan for change. This chapter ties those together.

How the bill is made

In Consumption, you pay per execution: each trigger check and each action has a small price, with different rates for built-in, standard connector, and enterprise connector operations, and extra charges for storage of run data and retention beyond the included period. Polling triggers cost money even when they find nothing, so frequent polling of busy systems adds up. In Standard, you pay for the hosting plan, billed by compute resources over time, plus storage transactions for stateful workflows, plus networking and monitoring. Hybrid deployments have their own pricing. Agent workflows add model usage costs. Prices differ by region and change over time, so use the official pricing page and calculator.

Governance basics

Name logic apps, workflows, and connections consistently, including purpose, environment, and owner. Tag resources with owner, cost centre, and criticality. Use Azure Policy to require diagnostic settings, restrict locations, enforce managed identities, limit allowed connectors, and require private networking for production. Keep an inventory of workflows, their triggers, their targets, and who is on call for each. Disable or delete workflows that are no longer used, because forgotten polling workflows keep costing money and keep holding credentials.

Managing change and retirements

The platform evolves. The Integration Service Environment, the dedicated option for the earlier generation, was retired on 31 August 2024 and customers were directed to Standard. Connectors are added, updated, and sometimes deprecated. Features such as high-throughput mode and many AI capabilities start in preview, and preview features can change or lack support guarantees. Assign someone to follow announcements, review connector deprecation notices, test against new runtime versions in non-production, and plan upgrades. Treat dates in any guide, including this one, as pointers and confirm them on official pages.

Showing teams their own spend

Cost falls when owners can see it. Use tags and cost reports to show each team what its workflows cost each month, broken down by logic app and by environment. Highlight the top ten spenders and ask their owners whether the spend is justified. Often a forgotten test workflow, a polling trigger set too fast, or a verbose telemetry setting accounts for most of the surprise. A short monthly review prevents small leaks from becoming large bills.

Patterns are proven answers to repeated problems. This chapter gathers the ones seen in almost every well-run estate, with traps to avoid and a checklist for reviews.

Helpful patterns

flowchart LR
    SRC[Source system] --> Q[Queue]
    Q --> WF[Workflow with scope and retries]
    WF -->|Success| TGT[Target system]
    WF -->|Failure after retries| DLQ[Dead-letter queue]
    DLQ --> OPS[Operator review and resubmit]
    WF --> LOG[Logs with tracked properties]
    LOG --> ALR[Alerts]
        

More anti-patterns

Common mistakes and their fixes

A pre-launch checklist

Every service has strengths and costs. Here is an honest look at what Logic Apps gives you, what it asks in return, and where neighbouring services fit better.

Choosing among neighbouring services

Working together

The best designs mix these. A typical pattern uses Event Grid or a queue to start a workflow, Logic Apps to orchestrate and call connectors, Functions for tricky code, API Management for a safe front door, and Monitor for visibility. Do not force one tool to do every job. Pick each for its strength and keep the contracts between them clear.

Deciding with a simple test

When unsure whether Logic Apps is right, ask four questions. Is the main job connecting systems and coordinating steps? Does it benefit from built-in retries, waits, and history? Can the heavy logic live elsewhere? Can the team support it with source control and monitoring? Four yes answers point to Logic Apps. A no on the first suggests code or another service, and a no on the last suggests investing in practices before building more workflows.

These short stories show how the concepts fit together in situations you may recognise.

flowchart TD
    N[Need arises] --> T{Type of need}
    T -->|Connect systems on events| A[Push triggers, queues, connectors]
    T -->|Human decisions| B[Approval patterns with reminders and escalation]
    T -->|Partner documents| C[Integration account, schemas, maps, AS2]
    T -->|Judgement on free text| D[Agent loop with limited tools and approvals]
    T -->|Private and regulated| E[Standard with private endpoints and hybrid options]
    A --> G[Monitor, alert, and review regularly]
    B --> G
    C --> G
    D --> G
    E --> G
        

What these stories have in common

In every scenario, success came from decisions made early and habits kept over time. Teams that chose events over polling saved money and time. Teams that added error branches and alerts found problems before customers did. Teams that used identities instead of passwords avoided expiry surprises. Teams that kept workflows small and versioned could change them confidently. None of this needed exotic features, only clear ownership, sensible defaults, and regular review.

Short, direct answers to questions that beginners and busy teams often ask.

Consumption runs one workflow per logic app on shared infrastructure and charges per execution. Standard hosts many workflows in one app on dedicated compute, with stronger networking, local development, and plan-based billing.

They share many ideas and connectors, but Power Automate is aimed at business users in the Power Platform, while Logic Apps is aimed at developers and integration teams working in Azure, with more control over hosting, networking, and deployment.

It was retired on 31 August 2024. Microsoft directed customers to Standard, which offers dedicated, network-integrated hosting.

Stateful workflows save step data and history, support long waits and resubmission, and suit business processes. Stateless workflows run in memory, are faster, and suit short request-response flows. The type is chosen when you create the workflow in Standard.

Prefer built-in where available because they run inside the runtime and can use private networking in Standard. Use managed connectors for the wide range of services that have no built-in version.

Design the work to be idempotent using unique identifiers and checks, and use concurrency and message features carefully. Duplicates can come from retries and at-least-once delivery, so assume they will happen.

Wrap the main work in a scope, add a following scope that runs on failure to log, alert, and park the message, use sensible retry policies, and add alerts for failures and for missing runs.

Mark steps that handle sensitive data to hide their inputs and outputs, use secure parameters, store secrets in Key Vault, prefer managed identities, and restrict who can read history.

Yes, through the on-premises data gateway for managed connectors, through virtual network integration with a VPN or dedicated circuit in Standard, or through hybrid deployment near the systems.

Web calls have time limits that differ by hosting model, roughly two minutes in multitenant and a little under four minutes by default in single-tenant. Use an asynchronous pattern for longer work.

The documented limit has been five hundred actions per workflow, with a nesting depth of eight. Split large processes into child workflows, and check the current limits page.

They add an agent loop to Standard workflows. A language model receives a goal and a set of tools, chooses which to use, and repeats until done, with options for human approval. Agent Loop in Standard was announced as generally available in November 2025, with some further AI features in preview.

Keep workflow files and infrastructure templates in source control. In Standard, deploy infrastructure first and then package and deploy the workflows, supplying environment settings from the pipeline. In Consumption, deploy a template that contains the definition.

Replace polling with push triggers, filter early, avoid huge loops, use built-in actions, choose stateless where history is not needed, right-size Standard plans, limit monitoring volume, and cap agent iterations.

Alert on the absence of expected runs as well as on failures. Silence is often the first sign of a disabled workflow, an expired connection, or a broken trigger.

There is no one-click switch because the resource models differ. Export or rebuild workflows in Standard, rework connections, and test carefully. Choose the model with growth in mind to avoid rework.

Azure Logic Apps is Microsoft’s managed service for building automated workflows that connect systems. A workflow starts with one trigger and continues through actions, conditions, loops, and scopes, using connectors to reach hundreds of services. The hosting model is the biggest choice: Consumption for small, occasional, pay-per-run automations, and Standard for steady, high-volume, networked, and team-built solutions, with App Service Environment and hybrid options for special needs. Reliable workflows use queues, retries, idempotent steps, error scopes, and dead-letter handling. Secure ones use managed identities, secured history, restricted callers, and private networking. Agent workflows add AI judgement on top of the same safeguards. Good teams treat workflows as code, monitor failures and silence, manage cost by avoiding needless polling, and keep up with change, such as the retirement of the Integration Service Environment and the evolving status of preview features.