Welcome to the Series

Welcome to the first article in the Coding with Logic Apps Standard series. This series is for integration developers, architects, and modernization teams who want to go beyond visual workflow design and use Azure Logic Apps Standard as a complete development platform for enterprise integration. In this post, we focus on Local Functions: the ability to write, debug, and deploy custom .NET code together with your workflows, inside the same Logic Apps Standard project.

Customers often assume that meaningful custom code in an integration solution must be implemented as a separate Azure Function. Azure Functions are a powerful option for reusable APIs, independent compute workloads, and enterprise-wide services. But when custom code exists to support an integration workflow—validating a message, enriching a payload, shaping data for a connector, or applying business-specific logic—Local Functions provide a simpler, more cohesive, and more integration-native option inside Logic Apps Standard.

Does Logic Apps Standard run on top of Azure Functions?

Before we go deeper, it is important to clarify the relationship between Logic Apps Standard and Azure Functions. Logic Apps Standard is not a workflow layer that simply runs on top of Azure Functions. Instead, Logic Apps Standard uses a Functions host that is specialized for integration workloads. That distinction matters because an integration platform has different requirements than a code-only compute service.

A typical Azure Functions app is created around a specific language stack, such as .NET, Java, Node.js, Python, or PowerShell. That model works well when the application is primarily a code-first service. Logic Apps Standard has a different goal. A single integration application might orchestrate workflows, use built-in connectors, run JavaScript for workflow logic, call local .NET code through Local Functions, use JDBC-based connectivity, and execute scripts as part of the same integration solution.

Logic Apps Standard supports this model through dynamically isolated language workers. The runtime can inspect the workflow and start the worker that is needed for that integration scenario. For example, a workflow that uses JDBC can start the Java worker, while a workflow that uses custom C# code can start the isolated .NET worker. The goal is not to make customers think about processes. The goal is to let the integration application use the right technology for each part of the flow, with little latency difference for typical workflow use.

For iPaaS scenarios, this is important. To achieve the same multi-language result with standalone Azure Functions, customers may need multiple Function Apps, each aligned to a different language stack. That adds more resources, deployment units, configuration surfaces, and operational overhead. In Logic Apps Standard, the same integration scenario can often run inside a single Logic App application: built-in connectors plus the isolated language worker needed for the workflow, rather than several separate Function Apps. Azure Functions remains a strong option for independent compute services, while Logic Apps Standard provides the integration application model for workflows, connectors, and workflow-scoped code.

Why Local Functions?

Logic Apps Standard goes beyond being a workflow engine. It is also a runtime where built-in connectors, workflow orchestration, and custom code can work together as one solution. Local Functions make this especially valuable because they let you place custom .NET logic directly beside the workflow that needs it. The Logic Apps runtime and function execution run alongside each other in the same application process model, so when the code is part of the workflow, it can scale with the Logic App, deploy with the Logic App, and be operated as part of the same application boundary—without requiring a separate endpoint, separate authentication model, or separate runtime resource to manage.

This matters because the strongest integration solutions are not built from code alone. They combine the reach of connectors with the precision of custom logic. A workflow might receive a message from IBM MQ, read reference data from SQL, decode EDIFACT messages, call SAP, or an API, transform a payload, and then invoke local custom code to apply partner-specific validation or business rules before sending the result to the next system. The outcome is unique: built-in connectors handle the connectivity and integration plumbing, while Local Functions handle the specialized code that makes the solution fit the business. With Local Functions you:

• Keep workflow and code together when the code is part of the integration process.
• Debug locally in one experience across workflow steps and custom .NET logic.
• Deploy as one solution without introducing a separate Function App for workflow-scoped code.
• Operate as one application with code that scales, deploys, and is managed together with the Logic App.
• Avoid unnecessary integration boundaries when there is no need to manage a separate endpoint, authentication flow, or runtime resource for workflow-specific code.
• Improve simplicity and security by avoiding the need to onboard and harden multiple application resources in the network, reducing the exposed surface area for workflow-scoped code.
• Simplify cost management for workflow-scoped code because Local Functions run within the Logic Apps Standard application boundary and do not require a separate Azure Functions resource when the code belongs to the workflow.
• Modernize BizTalk-style custom logic into a cloud-native workflow model while preserving valuable .NET investments.

However, this is not about choosing Local Functions instead of Azure Functions in every scenario. Azure Functions are excellent when you need an independently hosted, reusable, code-first service. The opportunity is to use Local Functions first when the code naturally belongs with a Logic Apps integration solution. In those cases, the workflow, connectors, and custom code run side by side in the same application boundary, scaling together, deploying together, being managed together, and avoiding the need to introduce a separate Azure Functions resource for code that is only used by that workflow.

What are common scenarios for Local Functions?

Local Functions are best for workflow-scoped code: logic that is meaningful only in the context of a Logic Apps Standard workflow and benefits from being deployed, scaled, secured, and operated with that workflow. Common scenarios include:

• Message validation and enrichment before or after connector calls to systems such as SQL, Service Bus, SAP, IBM MQ, DB2, HTTP APIs, or partner endpoints.
• Custom parsing or formatting for proprietary, irregular, or partner-specific payloads that do not fit simple workflow expressions or mappings.
• Business rules and calculations that are too specific for generic workflow expressions but do not need to become independent services.
• BizTalk modernization where existing .NET helper assemblies, orchestration utilities, pipeline-adjacent logic, enrichment routines, or host-specific formatting can move closer to Logic Apps workflows.
• Modernization from Java-oriented integration platforms such as MuleSoft, Boomi, or TIBCO BusinessWorks when customers decide to refactor workflow-scoped Java, Groovy, JavaScript, or XPath helper logic into .NET as part of their move to Logic Apps Standard.

When to use Local Functions versus Azure Functions

Azure Functions and Local Functions are complementary. Azure Functions are a great fit for independent services, shared APIs, and event-driven compute that should live outside a single workflow application. Local Functions are a great fit when the code is part of the integration workflow itself and benefits from running alongside the Logic Apps runtime in the same application process model, sharing the same lifecycle, scale, deployment, and operational boundary as the Logic App. You can use the following guidance:

While cost can also be part of this decision, it should be framed in architectural terms. When custom code is implemented as a separate Azure Function, the solution introduces another Azure resource with its own hosting, billing, deployment, monitoring, and security considerations. When the code is workflow-scoped, Local Functions let that code run within the Logic Apps Standard application boundary, alongside the workflows and connectors that use it. This can simplify the overall cost model because the team does not need to add a separate Azure Functions resource just to host code that belongs to the integration workflow.

The Bigger Opportunity: In-App Connectors Plus Code

The most important reason to consider Local Functions is not just convenience. It is the integration outcome. Logic Apps Standard gives you native workflow orchestration and a broad In-app connector ecosystem. Local Functions add the ability to bring custom code of all kinds into that same solution boundary. Together, they let you build integrations where the platform handles connectivity, reliability, retries, monitoring, orchestration, and iPaaS semantics, while your code handles the business-specific decisions that make the workflow unique.

For customers who are defaulting to Azure Functions because they believe Logic Apps cannot host meaningful code, Local Functions change the conversation. Azure Functions remain a strong option for independent compute and reusable services. But when the code belongs to the integration flow, Logic Apps Standard can be the place where connectors, workflow logic, and local code meet: connectors to reach systems, workflow logic to coordinate the process, and local code to implement the specialized behavior that customers need. The value is not that one runtime replaces the other; it is that Logic Apps and function execution can run alongside each other, each providing unique value inside the same integration application boundary. For workflow-scoped code, that same boundary also helps avoid adding a separate Azure Functions resource, with its own deployment, authentication, monitoring, scaling, and cost model, when the code is only needed by the Logic App.

CI/CD

Local Functions fit naturally into the same CI/CD model as Logic Apps Standard workflows. The workflow definitions, connections, configuration, and workflow-scoped .NET code can live in the same project. They can also move through the same build, test, and deployment process. This means teams can package the Logic Apps Standard application once and promote it across development, test, staging, and production environments. When the code belongs to the workflow, Local Functions help avoid a separate deployment pipeline, release process, and operational boundary for a standalone Azure Functions resource.

Looking Ahead

In the next articles in the Coding with Logic Apps Standard series, we will continue exploring the developer side of Logic Apps Standard. The goal is to help customers see Logic Apps Standard not only as a low-code workflow designer, but as a mission-critical integration development platform where connectors and code work together, and where workflows can be created, managed, and deployed as code.