(Spoiler: It’s Complicated)
Azure Logic Apps is often presented as a way to build integrations with minimal code. You might have been sold the dream of dragging boxes onto a canvas and never touching code again. Then you’ll hit your first @{body(‘Parse_JSON’)?[‘items’][0]?[‘value’]} and wonder where it all went wrong.
TL;DR
Azure Logic Apps is genuinely low-code – it lowers the barrier to building integrations dramatically.
But it’s rarely no-code: the moment you need real-world error handling, data shaping, or proper deployment, you’re writing something that walks and quacks like code.
Here’s where the marketing meets reality, and a straight answer on when to reach for Logic Apps, Function Apps, or combine both when you need the strengths of each.
When Azure Logic Apps really is a 'no-code' dream
Credit where it’s due. For a specific class of problem, Logic Apps absolutely delivers:
- “When an email arrives with an attachment, save it to SharePoint and post to Teams.” Three connectors, zero code, done in ten minutes.
- You have simple, linear trigger-action workflows where connectors do exactly what you need out of the box.
- You’re connecting SaaS platforms with first-party connectors.
- The workflow genuinely looks like a recipe: do this, then this, then this.
The citizen developer dream is real here.
Where Azure Logic Apps quietly becomes code
The trouble is that real-world integration is rarely a clean recipe. The moment you step off the happy path, the abstraction gets thin fast.
1. The expression language is code
The second you need to reshape data, filter an array, or handle a null, you’re writing Workflow Definition Language (WDL) expressions:
@{items('For_each')?['orderId']}
That’s a function language with its own syntax, quirks and learning curve. Try explaining coalesce(), triggerBody(), and the ?[] safe-navigation operator to a “no-code” business user.
2. You will end up in code view
Every Logic App is JSON underneath.
For anything non-trivial – debugging a parameter issue, copying actions or fixing something the designer mangled – you’ll eventually open code view.
And once you’re hand-editing JSON, let’s be honest about what we’re doing.
3. Error handling is an engineering exercise
Retries, runAfter configurations, scopes, try/catch patterns, dead-lettering, idempotency.
Building something resilient isn’t fundamentally different from applying the same engineering principles you’d use in traditional code.
4. Deployment is infrastructure as code
Run a single Logic App manually in the Azure portal and sure, no code.
Run an Enterprise Integration Platform with dozens of Logic Apps across development, test and production environments with CI/CD pipelines and governance requirements? Now you’re managing Bicep templates, API connections, source control, environments, deployments and arguing with pipeline. That’s a DevOps discipline.
5. Data transformation hits a wall
Need to map a complex payload?
You’ll soon be reaching for:
- Liquid templates
- Data Operations
- Integration Accounts
- XML and EDI transformations
At that point, you’re writing syntax and rules that are arguably more abstract than C#.
So, is Azure Logic Apps low-code, no-code or neither?
Low-code is the honest label.
Logic Apps lowers the barrier, but it doesn’t remove it.
It takes integrations that once needed a developer and a week of effort and allows a capable person to deliver them in an afternoon. That’s a genuine, enormous productivity win.
But “no-code” can be a trap.
It encourages organisations to hand production-grade integrations to people without the engineering instincts required to build and maintain them properly. The bill arrives later as a sprawling collection of brittle workflows nobody can debug and nobody placed in source control.
Logic Apps doesn't eliminate engineering. It changes where the engineering effort goes - from writing boilerplate code to designing reliable, observable and deployable workflows.
Azure Logic Apps vs Function Apps: which should you use?
This is the question I get on nearly every engagement.
Here’s the rule of thumb I keep coming back to:
Logic Apps handles the “what happens when”.
Function Apps handle the “how”.
The moment you need both, reach for a hybrid architecture.
When to use Azure Logic Apps
Reach for Logic Apps when:
- You’re orchestrating chaining systems together and the value is in the workflow, not the compute.
- The heavy lifting is already handled by a prebuilt connector (Office 365, Service Bus, SAP, Salesforce, SQL there are 1,400-odd of them).
- The process is event-driven or schedule-driven “when X lands, do Y, then Z.”
- You want the logic to be visible and business-readable someone other than the original author can open the designer and follow it.
- Volume is low-to-moderate.
Think:
- Approvals
- Notifications
- B2B and EDI processes
- System synchronisation
- Long-running workflows with built-in state
When to use Azure Function Apps
Reach for Function Apps when:
- You’re writing genuine custom business logic, an algorithm, a gnarly calculation, parsing something nobody built a connector for.
- You need low latency, performance or high throughput. Functions scale for compute in a way Logic Apps doesn’t.
- The transformation would be painful in WDL but simple in C#, Python or JavaScript.
- You’re dealing with heavy nested looping, calculations or complex processing and multiple downstream services.
Think:
- Custom APIs
- Data processing
- Image processing
- Business rules engines
- Anything you’d want a test suite around
When to combine Logic Apps and Function Apps and go hybrid?
Honestly? Most of the time.
The best Azure integration architectures don’t pick a side, they let each service do what it’s good at:
- Logic App as the conductor: owns triggers, connectors, retries and end-to-end orchestration.
- Function App as the brains: handles complex transformations, calculations and custom logic.
You get business-readable orchestration alongside testable, version-controlled code where it actually adds value.
A common pattern is a Logic App receiving an order, orchestrating approvals and notifications through connectors, and delegating pricing calculations or business rules to a Function App.
Neither tool is being forced beyond its strengths.
| If you need… | Use |
|---|---|
| Connectors, orchestration, visible workflow | Logic Apps |
| Custom code, performance, testability | Function Apps |
| Orchestration and custom business logic | Hybrid (Logic App + Function App) |
Frequently asked questions
Are Azure Logic Apps really no-code?
They can be for straightforward workflows using standard connectors. For enterprise-grade integrations, most teams eventually work with expressions, deployment pipelines and engineering concepts that make Logic Apps a low-code platform rather than a true no-code platform.
When should I use Azure Functions instead of Logic Apps?
Use Function Apps when you need custom code, complex transformations, performance or logic that would be difficult to maintain in Workflow Definition Language expressions.
Can Logic Apps and Function Apps be used together?
Yes. In fact, this is one of the most common Azure integration patterns. Logic Apps handles orchestration while Functions handles specialised business logic.
The bottom line
Are Azure Logic Apps really low-code or no-code?
They’re definitely low-code and only genuinely no-code for simple integrations.
The drag-and-drop designer gets you through the easy 80%. The remaining 20% – expressions, error handling, observability, deployment and governance – is what separates a demo from a production system. And that 20% is unmistakably engineering.
So don’t choose tools based on the marketing label.
Choose them based on the shape of the problem:
- Orchestration leans towards Logic Apps.
- Custom business logic leans towards Functions.
- Most serious integration architectures benefit from both.
Building integration solutions on Azure and not sure where the lines sit? That’s exactly the kind of thing we help clients untangle at Arinco – come say hi.
