Logic Apps
Azure Logic Apps is a low-code workflow engine for integration and automation. A workflow starts on a trigger and runs a sequence of actions drawn from more than a thousand prebuilt connectors — SaaS apps, Azure services, databases, protocols — so connecting systems is configuration rather than glue code. It is how a business process spanning several systems gets orchestrated without writing and operating that orchestration yourself.
Its strength is the connector catalog and the visual, stateful workflow; its limit is that complex logic is awkward to express by clicking. Logic Apps is for integration and orchestration across services; Azure Functions is for arbitrary code. Many designs use both — a Logic App orchestrates, calling Functions for the custom logic the connectors cannot express.
Connectors
Over a thousand managed connectors integrate Office 365, Salesforce, SAP, SQL, Service Bus, storage, and countless SaaS APIs, plus generic HTTP and protocol connectors for anything else. The connector catalog is the reason to choose Logic Apps: the integration that would be days of SDK and auth code becomes a configured action.
Triggers and Actions
A workflow begins with a trigger — a schedule, an incoming HTTP request, a new message, a file arriving — and runs actions in sequence or in parallel, with conditions, loops, and error handling. The workflow is the orchestration: it waits, branches, retries, and coordinates across systems without you running a server to host that logic.
Consumption vs Standard
The Consumption plan is fully serverless and bills per action executed — ideal for event-driven, variable workloads. The Standard plan runs on dedicated, single-tenant hosting with VNet integration and multiple workflows per app, for predictable cost, network isolation, and higher throughput. The choice mirrors the serverless-vs-dedicated trade seen throughout the compute chapter.
Stateful and Stateless
Standard workflows can be stateful (each step's state is persisted, so a long-running workflow survives restarts and is fully auditable) or stateless (lower latency and cost, no per-step persistence, for short synchronous flows). Stateful is the default for durability and traceability; stateless suits high-throughput, short-lived workflows where the persistence overhead is not worth it.
Logic Apps — Low-code workflow orchestration with hundreds of connectors, for IT integration across services. Visual and stateful.
Azure Functions — Arbitrary code triggered by events, for custom logic. Choose it (or call it from a Logic App) when connectors cannot express the logic.
Power Automate — The business-user, self-service face of the same workflow engine, for personal and office automation rather than IT integration.
- Forcing complex, code-heavy logic into a visual workflow instead of calling an Azure Function for the custom part.
- Using a Function to hand-write an integration that an existing Logic Apps connector already provides.
- Choosing the Consumption plan where VNet integration or predictable throughput required Standard.
- Making a long-running workflow stateless and losing durability and the audit trail when it restarts.
- Ignoring built-in retry and error-handling and writing fragile workflows that fail on the first transient error.
- Storing connector credentials insecurely instead of using managed connections and Key Vault.
- Use Logic Apps to orchestrate integrations across services with prebuilt connectors; call Functions for custom logic.
- Choose Consumption for event-driven variable workloads and Standard for VNet integration and predictable throughput.
- Use stateful workflows for durability and auditability; stateless only for short, high-throughput flows.
- Lean on built-in retry policies and error handling rather than assuming actions always succeed.
- Secure connector credentials with managed connections and Key Vault.
- Reach for an existing connector before writing integration code by hand.
Knowledge Check
When should a Logic App call an Azure Function rather than doing the work itself?
- When the logic is complex or code-heavy and awkward to express with visual actions and connectors
- Always, because Logic Apps cannot run conditions, loops, or any logic on its own
- Only when the workflow needs to deploy to a target outside of Azure
- Never, since Functions and Logic Apps run in isolated planes and cannot call or interoperate with each other in any way
What does the Standard plan add over Consumption for Logic Apps?
- Dedicated single-tenant hosting with VNet integration and predictable throughput
- The ability to use connectors at all, which Consumption lacks entirely
- Pay-per-action serverless billing that scales the cost down to zero whenever the workflow sits idle
- Removal of stateful workflows so every run is forced to be stateless
What is the trade-off of a stateless workflow versus a stateful one?
- Lower latency and cost, but no per-step persistence — so it does not survive restarts or give a full audit trail
- Higher durability and a full audit trail at a higher per-run cost
- Access to a broader set of managed and enterprise connectors than stateful workflows allow, unlocking integrations the stateful mode keeps disabled
- Guaranteed exactly-once execution of every step in the workflow
You got correct