Azure Logic Apps is Microsoft’s cloud integration and workflow automation service on the Azure platform. It lets teams design workflows visually, or as JSON definitions, from triggers, actions and connectors, and it runs them on managed infrastructure that scales automatically.
Among automation platforms, Logic Apps occupies the enterprise integration end of the market. It is aimed at developers and integration specialists who connect cloud services, on-premises systems and business partners, and it shares its workflow engine with Power Automate, the citizen-developer product in the same family.
How Azure Logic Apps executes workflows
Every workflow starts with exactly one trigger, such as an HTTP request, a schedule, a new message in a queue or a new file in storage. When the trigger fires, the engine creates a workflow run and executes the following actions according to their dependencies, in sequence or in parallel branches.
The workflow is stored in the Workflow Definition Language, a JSON schema that describes triggers, actions, parameters and expressions. The designer in the Azure portal or in Visual Studio Code edits this JSON, so workflows can be kept in source control and deployed with infrastructure-as-code templates.
Stateful workflows save the inputs and outputs of each action to storage. That enables a detailed run history, resubmission of failed runs and long waits of days or weeks. Stateless workflows, available in the Standard model, keep data in memory, which lowers latency and cost but loses the detailed history.
Actions can reference the outputs of earlier steps through expressions, such as functions for string handling, date arithmetic and JSON parsing. Control-flow actions provide conditions, switches, for-each loops and until loops. By default, for-each loops run iterations in parallel with a configurable degree of concurrency, which speeds up processing but requires care when iterations update shared variables or call rate-limited services.
Hosting models and pricing
Logic Apps comes in two hosting models that differ in isolation, billing and features. The choice matters early because moving between them requires rework of the deployment pipeline.
| Aspect | Consumption | Standard |
|---|---|---|
| Tenancy | Multi-tenant shared service | Single-tenant, dedicated resources |
| Billing | Per trigger and action execution | Hosting plan with reserved capacity |
| Workflows per resource | One | Many |
| Stateless workflows | Not available | Available |
| Private network access | Limited | Virtual network integration |
| Local development | Portal-centered | Full local runtime in Visual Studio Code |
Consumption suits low or unpredictable volumes because idle workflows cost nothing. Standard runs on the same runtime as Azure Functions and suits steady, high-volume workloads, private networking and teams that want to develop and test locally. The older Integration Service Environment has been retired in favor of Standard.
Connectors, built-in operations and B2B integration
The service offers a catalog of more than a thousand connectors for Microsoft and third-party services, databases, file systems and protocols. Connectors fall into two groups with different performance characteristics, as the table below explains.
| Connector type | Where it runs | Typical use |
|---|---|---|
| Built-in operations | Inside the Logic Apps runtime | HTTP, schedules, variables, control flow |
| Managed connectors | Microsoft-hosted shared infrastructure | SaaS apps such as CRM and office tools |
| Custom connectors | Defined from an API description | Internal or niche APIs |
| On-premises data gateway | Agent inside the private network | SQL Server, file shares, SAP |
For business-to-business scenarios, an integration account stores partners, agreements, schemas and maps. It enables EDI standards such as X12 and EDIFACT, the AS2 transport protocol and XML transformations, which makes Logic Apps a common replacement for older on-premises integration servers.
Azure Logic Apps compared with other platforms
Logic Apps competes with general automation tools and with workflow orchestrators. Its strengths are deep Azure integration, enterprise security and B2B features, while its weaknesses are Azure dependence and a steeper learning curve than consumer-oriented tools.
| Platform | Primary audience | Key difference |
|---|---|---|
| Azure Logic Apps | Integration developers | Azure-native, B2B and private networking |
| Power Automate | Business users | Same engine, Microsoft 365 licensing |
| AWS Step Functions | Cloud developers on AWS | State machine orchestration of AWS services |
| Zapier | Non-technical users | Simplest editor, SaaS-only focus |
| n8n | Technical teams | Self-hostable, open source license |
| Temporal | Software engineers | Workflows written as code |
A practical rule within Microsoft environments is to use Power Automate for personal and team productivity and Logic Apps for system-to-system integration that needs monitoring, deployment pipelines and network isolation.
Reliability, monitoring and common pitfalls
Logic Apps provides retry policies on actions, with exponential backoff as the default for transient failures, and scopes with run-after conditions that act like try-and-catch blocks. Run data can be sent to Azure Monitor and Application Insights for alerting and dashboards.
- Underestimating Consumption costs: loops over large arrays bill every iteration as separate action executions.
- Throttling by connectors: managed connectors enforce call limits per connection, so high-volume flows need batching or several connections.
- Large payloads: messages above the action size limits require chunking or passing a storage reference instead of the content.
- Secrets in definitions: credentials belong in Azure Key Vault and managed identities, never in workflow parameters.
- No error branch: without run-after handlers, a single failed call silently ends the run.
Good practice is to treat each workflow as a deployable software artifact: parameterize environment-specific values, keep separate development, test and production resources, and review run history after every release. Teams that follow this discipline usually find Logic Apps easier to operate than custom integration code, because retries, logging and connector authentication are already provided by the platform.
Stripped to the essentials
Azure Logic Apps is a Microsoft cloud service that connects different systems and moves data between them automatically. You describe a chain of steps: when this happens, do that, then do the next thing.
Think of it as a reliable clerk who never sleeps. It watches for new orders, emails or files. It then passes the information to the right systems in the right format. Each run is recorded, so you can see what happened and fix what failed.
Where it is applied
A mid-sized manufacturer receives purchase orders from about 30 retail partners as EDI documents. Its old on-premises integration server is out of support, and the IT team needs a replacement that also talks to the company’s ERP system inside the corporate network.
The team builds Standard Logic Apps workflows connected to the private network. An AS2 trigger receives each order, an integration account validates and decodes the X12 message, a map converts it to the ERP format, and a built-in connector writes it to the ERP database. A run-after scope sends failed documents to a support queue with the original file attached.
Workflows are deployed from source control through a release pipeline. After migration, the team reports full visibility of every order in run history and fewer manual interventions, because transient partner errors are now handled by automatic retries.