Azure Functions vs Logic Apps is primarily a choice between custom execution and managed integration. Use Functions for event-driven application code, Logic Apps for connector-rich business workflows, and Durable Functions when Functions needs persistent, code-based orchestration. Durable Functions extends Azure Functions; it is not a separate hosting plan. Both Logic Apps and Durable Functions can coordinate long-running processes and human decisions. A hybrid can separate connectivity from domain logic, but adds operational boundaries. Compare the exact hosting plan, connector behavior, security requirements and cost per completed transaction before deciding. Neither performance nor price has a universal winner.

Key takeaways

• Begin with one business transaction and its failure paths, not a product preference.
• Compare Functions hosting separately from workflow design and durable storage.
• Choose Logic Apps Consumption or Standard deliberately; managed connector charges can remain in Standard.
• Persist waiting workflows instead of holding an HTTP request or worker open.
• Measure accepted outcomes, retries, operator effort and total cost together.

What is Azure Functions?

Azure Functions runs application code in response to an event. A function app groups functions with shared configuration and a hosting environment. Each function has a trigger: an HTTP request, queue message, scheduled timer or storage event, for example. Bindings provide supported connections to data and messaging services. C#, JavaScript, Python and other supported language stacks let developers own parsing, computation and application rules. See the Functions overview.

Typical starting points include webhook validation, lightweight APIs, file processing, scheduled cleanup and queue consumers. An ordinary Function can participate in a larger workflow through messages and application state without using Durable Functions. The team then owns that coordination. Do not hold one invocation open for a multi-day business process: worker restarts, HTTP timeouts and lost progress require a different design.

What is Azure Logic Apps?

Logic Apps connects systems using workflows built from triggers, actions, conditions and connector operations. It suits Microsoft 365, Dynamics, ERP and partner integration when managed connectivity removes repeated authentication and protocol work. The visual designer is one authoring surface; workflow definitions, custom code and deployment pipelines are also available. Integration accounts and B2B artifacts may be relevant to partner agreements, schemas, maps and EDI requirements. They are not mandatory for every workflow. See the Logic Apps overview.

Consumption provides a multitenant workflow resource. Standard provides a single-tenant runtime with multiple workflows and stateful or stateless execution choices. A connector is not a promise that every operation supports the same identity, network route, payload or throttle. Verify the actual operation before committing to an architecture.

Standard C# code-first workflows: distinguish preview from established options

The Logic Apps Standard SDK for C# workflows is documented as preview at this review. Its limitations include unavailable service-provider operations, dynamic schemas and managed-identity connector authentication. Evaluate its current support contract before production adoption. This preview is distinct from calling Functions, editing JSON definitions or using custom .NET functions inside Standard workflows. Logic Apps is not limited to no-code development.

What is Azure Durable Functions?

Durable Functions adds stateful orchestration to a function app. Client functions start or query an instance; orchestrators coordinate steps; activities perform work; entities manage durable state through their supported programming model. History and messages are persisted by a configured backend. The runtime can reconstruct progress by replay rather than requiring a worker to remain alive. The programming-model reference explains these roles; the overview explains the extension relationship.

An orchestrator must remain deterministic across replay. Put network calls, database writes and arbitrary side effects in activities or supported durable APIs. Use the orchestration context for time and durable timers; do not use ordinary sleep, random values or current-clock reads to make replay-sensitive decisions. Activities still need idempotency because re-execution can occur. Persistent history is coordination state, not your complete business ledger. See orchestrator constraints.

Azure Functions vs Logic Apps vs Durable Functions: key differences

This is a qualitative architecture matrix, not a speed ranking. Confirm limits against the selected release, region, connector and hosting plan. A simple queue consumer should not acquire an orchestration engine merely to make the table look complete.

Architecture diagrams: execution, integration and durable coordination

A. Event-driven Functions

Authenticate the ingress and validate the event before business work. Choose HTTP for a request/response contract, Event Grid for supported event notification, and Service Bus for brokered work with queue semantics. These are alternatives, not interchangeable delivery guarantees. Identity and telemetry span the path; retry ownership must be explicit.

B. Connector-driven Logic Apps

A trigger creates a workflow instance. Actions transform and route data through supported connectors. Consumption and Standard host the engine differently; a managed connector can still execute outside a Standard runtime. Draw that boundary in a network review rather than assuming a private host makes every downstream operation private.

C. Durable Functions

The orchestrator schedules activities and waits for results or events. The durable backend persists coordination history, rather than being the business destination after the activities. Arrows to the backend in this figure represent state exchange, not an additional sequential business step. Monitoring correlates the client, instance and activities.

Azure Functions hosting plans explained

Microsoft recommends Flex Consumption for new serverless function apps where requirements fit. It offers Linux execution, configurable memory and virtual networking. Premium, Dedicated and Container Apps address different capacity or packaging requirements. The legacy plan remains relevant to existing workloads and platform dependencies. Do not copy limits or deployment-slot assumptions between plans. See hosting comparison and Flex guidance.

Check the exact runtime, OS, trigger, region and quota before provisioning. Current hosting documentation has inconsistent Linux Consumption retirement labels: its summary marks Linux retired while its retirement note gives 30 September 2028. For an existing app, confirm the applicable migration notice in Azure rather than interpreting that summary as a universal immediate shutdown. Runtime-version retirement is a separate issue.

Logic Apps Consumption vs Standard

A Standard stateless workflow is not an alternative name for a durable approval process. Choose stateful execution when persistence and recovery are required. Standard capacity can be efficient when utilized, but multiple workflows also share a failure and resource boundary. Reserve capacity for peaks, not just monthly averages. Reference: hosting and workflow comparison.

Durable Functions orchestration patterns

For document approval, store the file in governed object storage, pass a reference, validate in an activity, await a reviewer event with a durable deadline, then post an accepted result. Resume from recorded progress after interruption; do not repeat a payment or ERP write blindly. External events, timers, monitor and fan-out guidance describe these mechanics.

Select the backend separately. Durable Task Scheduler is Azure-managed; the Azure Storage provider uses queues, tables and blobs. Other providers have specific support requirements. Microsoft currently recommends the scheduler, but region, compatibility, retention and cost still require assessment. Its Consumption SKU has a GA announcement, although an older billing table still labels it preview. Verify the selected SKU in the target region. Use the current provider list/CLI in the scheduler documentation; do not assume global availability. See backend options.

When to choose Functions, Logic Apps or Durable Functions

Choose Functions for a bounded custom operation

A developer-owned calculation, webhook handler or queue transformation may need no workflow designer. Favor the simplest handler that satisfies validation, replay and observability requirements. High event volume is a reason to measure concurrency and dependency limits, not automatic evidence that one platform wins on price.

Choose Logic Apps for integration-led workflows

ERP synchronization, Microsoft 365 routing, partner messaging and connector-heavy approvals can justify managed workflow capabilities. Evaluate connector licensing, API limits and operational visibility alongside development effort. A team maintaining dozens of vendor interfaces may spend more on custom upkeep than on action charges.

Choose Durable Functions for code-led persistent coordination

Use it when application developers need stateful branching, parallel activities, timers and explicit recovery in code. Logic Apps can also implement long-running workflows; Durable Functions is not inherently more capable just because its authoring model is programmatic. Skill fit, backend behavior and change management often settle the decision.

Hybrid architecture: Logic Apps + Functions + Durable Functions

An illustrative invoice process starts through an email connector or protected API. Logic Apps owns inbound connectivity; a Function validates file metadata; Durable Functions coordinates extraction, business checks and any human review. Logic Apps then invokes the ERP connector. The file store owns documents, the ERP owns accepted financial records, and durable history owns orchestration progress. Carry one business correlation ID across all components.

Place authorization before starting work and before accepting an approval. Limit each identity to its data and operation. Define retry ownership at every handoff, with idempotency keys on posting. Route exhausted or invalid cases to an exception queue and operator workflow. This design adds hosting, connector and telemetry charges: omit services whose responsibility is already met elsewhere.

Azure Functions vs Logic Apps pricing: model the business transaction

Pricing review: 30 October 2026; East US; USD; public pay-as-you-go planning basis. These are editable planning settings, not a quote. The official pricing pages expose dynamic rates that were not reliably available for every configuration in this review. Therefore the examples calculate usage quantities and provide configurable rate formulas, not invented dollar totals. Check agreement discounts, tax, currency, region and grant eligibility in your subscription. Sources: Functions pricing and Logic Apps pricing.

Meter the complete execution path

For Functions, measure metered instance memory and execution time under the actual concurrency configuration; allocating configured memory independently to every concurrent request can overstate billable GB-seconds. Apply free grants only when eligible and only once across shared usage. For Logic Apps, count the executed trigger/action path, including retries, branches and loop iterations. Polls can be billed even when no workflow starts. Standard built-in operations and managed operations have different meters; fixed hosting does not cover everything. See usage metering.

Durable waiting is not continuous orchestrator compute: an awaited durable task yields execution. Activities, backend storage/actions, retention, polling and provisioned capacity can still cost money. Consumption-plan orchestrator replays are billable invocations; other plan behavior differs. Avoid applying that legacy statement indiscriminately to every hosting meter. Scheduler billing and Azure Storage transaction costs are separate choices. See Durable billing.

Four configurable monthly scenarios

All counts above are assumptions for planning, not measured benchmarks or universal billing multipliers. Actual trigger batching, instance concurrency, workflow paths, grants and backend history change them. For each option calculate infrastructure + connector/action + state + monitoring + dependencies + operations labor, then divide by successful business transactions. A cheap invocation with expensive manual recovery may be the more costly design.

The downloadable worksheet has separate rate, unit, grant, region and evidence fields. Unknown prices remain unknown rather than silently becoming zero. Enter storage transactions/GB-months, log ingestion/retention, network transfer, Service Bus, API Management, ERP licensing and any integration-account charges. Avoid counting the same managed meter as both a connector and an action. Compare a realistic peak-capacity floor with a quiet month as well as the average.

Performance, latency and scalability: a reproducible test

Use equivalent contracts and dependency stubs first, then repeat against the real integration sandbox. Record region, runtime/extensions, plan, memory, concurrency, payload sizes, connector operation, backend and deployment commit. Keep data and accepted outcomes identical. A Function response time and a multi-day approval completion time cannot be compared as the same latency.

Run multiple trials, preserve raw results and separate warm/cold samples. Declare a business SLO before selecting concurrency. Report both successes and failures; discarded timeouts can make a fast-looking p95 misleading. No benchmark was executed for this article. Microsoft’s reliability guidance is a starting point, not a substitute for your measurements.

Enterprise security and governance

Separate the workflow author, runtime identity, reviewer and operator. Use Entra ID and managed identity where the selected operation supports them; assign narrow RBAC and data permissions. A Function key is not equivalent to per-user business authorization. Protect APIs and approval callbacks, rotate unavoidable secrets through controlled configuration, and keep secrets out of source and run history. References: Functions connections and Logic Apps security.

Review ingress, egress, private endpoints and connector execution routes independently. Minimize payloads in history and logs, agree retention/deletion, restrict diagnostics access and validate residency across every dependency. Encryption alone does not establish compliance. Security acceptance should include a denied-access test, expired credential behavior and a demonstrated separation between test and production. The C# Standard SDK preview has authentication limitations; do not assume mature designer capabilities carry over to it.

Error handling, monitoring and reliability checklist

• Use a stable business idempotency key and atomically record accepted side effects.
• Bound transient retries; do not retry invalid business data indefinitely.
• Define poison/dead-letter handling and an operator owner.
• Model partial completion and compensation explicitly; a refund is not a database rollback.
• Propagate business, workflow and trace correlation identifiers without sensitive payloads.
• Alert on backlog age, terminal failures and stalled approvals, not only CPU.
• Exercise recovery and document safe resubmission rules.
• Retain business audit evidence independently where required; run history is not a complete audit system.

Logic Apps scopes and run-after paths can model recovery; Durable exceptions and activities can coordinate compensation. Neither makes external writes exactly-once by default. Workflow error handling and idempotent Functions design explain why retry policy and business correctness must be designed together.

DevOps and CI/CD comparison

Keep code, definitions, Bicep or Terraform, connection references and configuration contracts in version control. GitHub Actions or Azure DevOps should build, test and promote the same artifact with environment-specific identity and settings. Standard can separate workflow project deployment from infrastructure. Do not copy developer connection secrets into a release package. See Standard deployment guidance.

Test expressions, mappings, activity logic and end-to-end recovery. Use deployment slots only where the chosen plan supports them. Version long-running instances deliberately: changing orchestration order or activity signatures can break replay. Drain, route or version in-flight work with a documented rollback strategy rather than simply overwriting it. See Durable versioning guidance.

Practical .NET / C# and workflow examples

These are concise structural examples, reviewed against Microsoft APIs but not compiled or deployed in this environment. Start with an Azure Functions v4 isolated-worker template and a currently supported .NET target. Pin compatible stable worker, Service Bus and DurableTask extension versions in your project. Avoid mixing Microsoft.Azure.WebJobs in-process APIs with isolated-worker code. The isolated-worker reference notes in-process support ends 10 November 2026.

1. Service Bus Function: reject invalid input and preserve retry behavior

using Microsoft.Azure.Functions.Worker;
using Microsoft.Extensions.Logging;

public sealed class ValidateInvoice(ILogger<ValidateInvoice> log)
{
    [Function(nameof(ValidateInvoice))]
    public void Run(
        [ServiceBusTrigger("invoice-jobs", Connection = "ServiceBus")]
        string documentId)
    {
        if (string.IsNullOrWhiteSpace(documentId))
            throw new InvalidOperationException("Missing document reference");
        // Replace with validated, idempotent application work.
        // Do not log document contents or credentials.
        log.LogInformation("Validated an invoice work item");
    }
}

The sample does not implement business persistence. Configure the identity-based Service Bus connection, permissions, retry and dead-letter policy separately; do not swallow processing failures. See Service Bus trigger.

2. Logic Apps workflow: safe, small request example

{
  "definition": {
    "$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
    "contentVersion": "1.0.0.0",
    "triggers": {
      "Request": {
        "type": "Request",
        "kind": "Http",
        "inputs": {
          "schema": {
            "type": "object",
            "properties": {
              "documentId": {
                "type": "string"
              }
            },
            "required": [
              "documentId"
            ]
          }
        }
      }
    },
    "actions": {
      "Acknowledged": {
        "type": "Response",
        "kind": "Http",
        "inputs": {
          "statusCode": 202,
          "body": {
            "state": "received"
          }
        },
        "runAfter": {}
      }
    },
    "outputs": {}
  },
  "kind": "Stateful"
}

This Standard workflow definition demonstrates a request and response only. It does not enqueue work, enforce documentId semantics or authorize a caller. Add those controls before accepting a real job. A 202 response alone is not a durable acceptance guarantee. See the trigger/action schema.

3. Durable orchestration: an approval with an expiry

using Microsoft.Azure.Functions.Worker;
using Microsoft.DurableTask;

public static class ApprovalFlow
{
    [Function(nameof(ApprovalFlow))]
    public static async Task<string> Run(
        [OrchestrationTrigger] TaskOrchestrationContext ctx)
    {
        string id = ctx.GetInput<string>()
            ?? throw new InvalidOperationException("Missing document ID");
        await ctx.CallActivityAsync("ValidateDocument", id);
        using var timerCancel = new CancellationTokenSource();
        Task expiry = ctx.CreateTimer(
            ctx.CurrentUtcDateTime.AddDays(3), timerCancel.Token);
        Task<bool> approval = ctx.WaitForExternalEvent<bool>("Approval");
        if (await Task.WhenAny(approval, expiry) == expiry)
            return "expired";
        timerCancel.Cancel();
        if (!await approval) return "rejected";
        await ctx.CallActivityAsync("PostApprovedDocument", id);
        return "approved";
    }
}

Implement and register the named activities and a protected client/callback separately. Add bounded activity retry and compensation according to the downstream contract. Never accept an unverified boolean from a public endpoint as approval: authenticate the reviewer, authorize that instance and deduplicate signals. The sample omits those application components and does not constitute a deployable approval system.

Enterprise use cases: illustrative architecture choices

These are hypothetical design starting points, not completed client projects. The candidate depends on the actual connector, security review and accepted business outcome. A healthcare or financial workflow does not become compliant merely because it runs in Azure.

Choosing the right Azure serverless architecture

Score requirements in plain language: code complexity, connector coverage, state, duration, human input, volume, concurrency, identity, networking, latency, team skills, monitoring, operational ownership, hosting, cost, maintainability and existing Microsoft investments. Avoid arbitrary weighted scores that conceal a failed mandatory security requirement. Reject infeasible candidates first; prototype the remaining trade-off.

Common Azure serverless architecture mistakes

Enterprise implementation roadmap

Set timelines after discovering integration constraints. An unapproved ERP interface or missing data owner is not solved by choosing a faster authoring tool.

How Prominent AI Services LLP can help

Prominent’s published API and system integration scope includes contracts, mappings, authentication, recovery and monitoring. Its Cloud and DevOps services cover cloud architecture, infrastructure as code, CI/CD and operational reviews. Start with an assessment or proof of concept, then agree implementation, dedicated engineering capacity or ongoing support as appropriate. No certification, fixed saving or delivery timeline is implied.

For the broader deployment-boundary decision, see microservices vs monolithic architecture. A workflow engine is not a reason by itself to split an application into services.

Frequently asked questions

Technical sources reviewed 30 October 2026. Recommendations, usage scenarios and diagrams are illustrative. No customer outcomes, deployed sample results, benchmark measurements or unverified cloud prices are claimed.