Azure Logic Apps: Low-Code Workflow Automation
Azure Logic Apps is a platform for automating workflows between cloud services and on-premises systems using a visual designer and hundreds of pre-built connectors. Where Azure Functions requires you to write code to call an API, parse a response, and route the result, Logic Apps lets you assemble the same workflow by connecting blocks in a designer. This page explains the model, typical use cases, and how to decide between Logic Apps and Functions.
What Logic Apps does well
Logic Apps excels at integration workflows — connecting systems that do not natively talk to each other. Consider this scenario:
A customer submits a support ticket through a web form. You want to: create a Zendesk ticket, send a confirmation email via SendGrid, post a notification to a Slack channel, and create a task in Jira. Writing this in code means writing HTTP clients for four different APIs, handling authentication for each, managing retries and error handling, and deploying and operating the code.
In Logic Apps, this is four connector steps in a visual workflow. Each connector handles authentication, retries, and the API-specific details. You configure inputs and outputs by mapping fields between steps.
Logic Apps has over 400 built-in connectors including:
- Microsoft services: Outlook, Teams, SharePoint, Dynamics 365, Azure services
- Third-party SaaS: Salesforce, ServiceNow, SAP, Workday, Zendesk, Jira, Slack
- Database connectors: SQL Server, Oracle, Cosmos DB, PostgreSQL
- Protocol connectors: HTTP, FTP, SFTP, AS2, EDIFACT, X12 (for EDI/B2B)
Triggers and actions
Logic Apps workflows follow a trigger-action pattern identical in concept to Azure Functions. Every workflow starts with a single trigger — the event that starts the workflow. All subsequent steps are actions.
Common triggers:
- HTTP request received — webhook endpoint that starts the workflow
- Recurrence — runs on a schedule (every hour, every weekday at 9am)
- When a message is received in a Service Bus queue
- When a blob is added or modified (Azure Storage)
- When an email arrives (Outlook, Gmail)
- When a record is created or updated (Salesforce, Dynamics)
Actions can call APIs, send messages, query databases, loop over arrays, apply conditions, call child workflows, and invoke Azure Functions for custom logic that connectors cannot handle.
Consumption plan versus Standard plan
Logic Apps has two deployment models with significant differences:
Consumption (multi-tenant)
Workflows run on shared Microsoft-managed infrastructure. Billing is per action execution — extremely cheap for infrequent workflows. No VNet integration support (cannot access private Azure resources directly). Faster to set up, no infrastructure to manage. Good for low-to-medium frequency workflows accessing public APIs.
Standard (single-tenant)
Workflows run on a dedicated App Service Plan, similar to Azure Functions Premium plan. Billed per vCPU hour. Supports VNet integration for accessing private databases and internal services. Supports multiple workflows in a single Logic App resource. Required for workflows that need private network access, lower latency, or compliance isolation. The Standard plan also supports running Logic Apps locally for development and testing.
For a workflow that needs to query a private Azure SQL Database in a VNet, Standard plan with VNet integration is the right choice. Consumption plan cannot reach private endpoints directly — it can only access publicly reachable endpoints.
A real workflow: file processing automation
Consider a workflow that runs every night: download a report from an SFTP server, parse it, load new records into a SQL database, and email a summary to a distribution list. In code, this is several hundred lines across multiple files. In Logic Apps:
- Trigger: Recurrence — run every day at 2:00 AM UTC
- Action: SFTP connector — list files in
/reports/incoming/, get the latest file - Action: Parse CSV — transform the file content into a JSON array
- Action: For each row — SQL Server connector, insert or update record in the database
- Action: Compose summary — build an email body using Logic Apps expressions
- Action: Office 365 connector — send email to distribution list
The entire workflow is created in the visual designer with no code. Each connector step handles authentication (via configured connections), retries, and API-specific logic. If a step fails, Logic Apps retries automatically and shows the failed run with detailed inputs and outputs for debugging.
Logic Apps versus Azure Functions: the honest comparison
| Logic Apps | Azure Functions | |
|---|---|---|
| Authoring style | Visual designer (JSON definition) | Code in Python, .NET, JavaScript, etc. |
| Pre-built integrations | 400+ connectors | Write your own HTTP calls |
| Custom logic | Limited expression language; embed Functions for complex logic | Full programming language capability |
| Latency | Seconds (connector overhead) | Milliseconds (code execution) |
| Observability | Built-in run history with per-step input/output | Custom logging, Application Insights |
| Best for | Service integration, B2B, scheduled data movement | Custom processing, algorithms, low-latency events |
In practice, Logic Apps and Functions complement each other. Logic Apps orchestrates the workflow; Functions handles the complex processing steps where code is genuinely needed. A Logic Apps workflow triggered by a new Salesforce opportunity could call an Azure Function to score the lead using a custom ML model, then use a Salesforce connector to update the record with the score.
Common Logic Apps mistakes
- Building complex data transformations in Logic Apps expressions. Logic Apps expressions are useful for simple field mapping and string formatting but become unreadable for complex logic. When a transformation requires more than a few expression calls, extract the logic into an Azure Function and call it from Logic Apps — keep Logic Apps for orchestration, not computation.
- Using Consumption plan when private network access is needed. Consumption plan workflows run on shared Microsoft infrastructure with no VNet integration. If your workflow needs to access a private Azure SQL Database or internal service, you need Standard plan with VNet integration or an intermediate HTTP endpoint that bridges the private resource.
- Not monitoring run failures. Logic Apps stores run history (configurable duration, up to 90 days on Consumption). Without alerts on failed runs, a critical nightly workflow can fail for weeks before anyone notices. Set up Azure Monitor alerts on the Logic App’s Failed Runs metric.
Summary
- Logic Apps automates multi-step workflows between cloud services using 400+ pre-built connectors and a visual designer — no custom HTTP client code needed.
- Consumption plan: per-action billing, no VNet integration, great for public API integrations. Standard plan: vCPU-hour billing, VNet integration, required for private Azure resources.
- Logic Apps is best for orchestration and integration workflows. Use Azure Functions when custom code, complex logic, or low-latency processing is needed within a step.
- The two services complement each other: Logic Apps orchestrates the flow, Functions handles the hard parts.
- Set up alerts on Failed Runs from the start — silent failures on scheduled workflows are a common operational blind spot.
Frequently asked questions
What is the difference between Logic Apps and Azure Functions?
Functions is code-first — you write the logic in a programming language. Logic Apps is designer-first — you build workflows visually using pre-built connectors. Functions is better when the logic is complex, requires custom algorithms, or needs low-latency execution. Logic Apps is better when the workflow is a sequence of service calls (call API, transform data, send email) that would be glue code in Functions and is better expressed visually.
Does Logic Apps require coding?
No coding is required for basic workflows. Logic Apps has a visual designer in the Azure portal with hundreds of pre-built connectors (Salesforce, SAP, Office 365, Slack, SQL Server, etc.). For custom transformations, you can write simple expressions using the Logic Apps expression language. For complex logic, embed an Azure Functions call as a step in the workflow.
How is Logic Apps billed?
The Consumption (multi-tenant) plan bills per action execution. Each action (connector call, condition evaluation, loop iteration) costs roughly $0.000025. A simple three-step workflow running 1 million times per month costs about $75. The Standard (single-tenant) plan bills per vCPU hour like App Service — better for high-frequency workflows or workflows that need VNet integration.