Workflow & iPaaS
Azure Logic Apps
Logic Apps is Azure's integration platform as a service (iPaaS): visually designed, declaratively defined workflows with 1,400+ connectors to SaaS, on-prem and Azure services. It shines wherever the problem is "connect system A to systems B, C and D with business rules in the middle".
How it works
A workflow = trigger (what starts it) + actions (what it does), defined in JSON (Workflow Definition Language) and edited in a visual designer. Connectors package the auth, retries and API details of external systems into reusable triggers/actions.
flowchart LR
T[Trigger
HTTP · schedule · queue message ·
file created · email · event]
T --> A1[Action: get data
SQL · SAP · Salesforce]
A1 --> C{Condition /
switch / loop}
C -->|approved| A2[Action: post to Teams
+ update Dynamics]
C -->|rejected| A3[Action: send email
+ dead-letter to Service Bus]
A2 --> R[Run history
every step logged & replayable]
A3 --> R
Consumption vs Standard
| Consumption (multitenant) | Standard (single-tenant) | |
|---|---|---|
| Pricing | Per action execution | Workflow Service Plan / App Service Environment v3; also hybrid deployment on your own Kubernetes (Arc) |
| Workflows per app | 1 | Many workflows per app |
| State | Stateful only | Stateful or stateless (stateless = much faster, no run history persistence) |
| Networking | Public endpoints | VNet integration + private endpoints |
| Connectors | Managed connectors | Managed + built-in (in-process) connectors — lower latency, no data leaving the app for Service Bus, SQL, etc. |
| DevOps | ARM templates | Project-based: local dev in VS Code, containers, CI/CD like any app |
| Choose when | Simple, low-volume automations | Enterprise integration, predictable perf, private networking, many related workflows |
AI agent workflows
Logic Apps Standard now supports agent workflows: an agent loop action powered by Azure OpenAI / Foundry models that reasons over a goal and chooses among tools you define as workflow actions — meaning every one of the 1,400+ connectors becomes a potential agent tool. Logic Apps can also act as tools for Foundry agents, and as remote MCP servers.
flowchart TB
G[Goal / prompt
e.g. resolve this support ticket] --> AL[Agent loop
Azure OpenAI model]
AL -->|reason + pick tool| T1[Tool: look up order
SQL connector]
AL --> T2[Tool: check shipping
HTTP/partner API]
AL --> T3[Tool: refund
Stripe connector]
AL --> T4[Tool: notify
Teams / Outlook]
T1 --> AL
T2 --> AL
T3 --> AL
T4 --> AL
AL --> Done[Structured outcome
+ full run history of every step]
Enterprise integration & B2B
- Integration account: trading partners, agreements, schemas, maps for B2B.
- EDI: X12, EDIFACT, AS2 message processing.
- XML: validation, XSLT transforms, flat-file encode/decode (mainframe/legacy).
- Rules engine: decouple business rules from workflow logic (BizTalk-style rules in Standard).
- The primary landing zone for BizTalk Server migrations.
Detailed use cases
Order-to-cash orchestration
Order event arrives on Service Bus → validate against SAP → reserve inventory → create invoice in Dynamics → notify customer. Compensating actions on failure; every run auditable.
B2B partner onboarding
AS2/X12 documents from trading partners are validated, mapped to internal JSON, and routed — replacing BizTalk with integration accounts and agreements.
Human-in-the-loop approvals
Expense/access requests trigger adaptive cards in Teams or Outlook approvals; the workflow waits (days if needed), then branches on the response.
Agentic ticket triage
Agent workflow reads new tickets, enriches from CRM + knowledge base, resolves simple cases autonomously via connectors, escalates the rest with a summary.
Scheduled data sync
Nightly sync between SaaS systems (Salesforce ↔ SQL ↔ SharePoint) with paging, retries and error queues — no code to maintain.
Legacy file ingestion
SFTP flat files → flat-file decode → XSLT map → REST calls into modern services; hybrid deployment keeps processing near on-prem systems.
Patterns & pairings
- APIM + Logic Apps: expose workflows as governed, versioned APIs; hide connector complexity behind a clean contract.
- Service Bus + Logic Apps: peek-lock message handling for reliable, ordered, resumable processing (sessions for ordering).
- Functions + Logic Apps: drop to code (Functions) for compute-heavy or algorithmic steps; keep orchestration declarative.
- Choose Durable Functions instead when orchestration logic is genuinely code-first and developer-only; choose Logic Apps when connectors, visibility and mixed audiences matter.