Azure Logic Apps Standard Local Function and .NET in-process retirement

Question

Azure Logic Apps Standard Local Function and .NET in-process retirement

AkarshaAkarsha-6739 0

I am using Azure Logic Apps Standard with a C# Local Function called through the "Call a local function in this logic app" action.

The Local Function targets .NET 8 and is deployed as part of the Logic Apps Standard project. It uses Microsoft.Azure.Functions.Worker and Microsoft.Azure.Workflows.Webjobs.Sdk. The function uses the Function attribute and WorkflowActionTrigger.

I understand that the Azure Functions .NET in-process model will reach end of support on November 10, 2026.

My question is:

Does the November 10, 2026 Azure Functions .NET in-process retirement apply to C# Local Functions hosted inside Azure Logic Apps Standard?

I am asking specifically about the Local Function used by the "Call a local function in this logic app" action, not a separate Azure Function App.

I found migration documentation for Azure Function Apps that explains how to migrate from the in-process model to the isolated worker model. However, I have not found Microsoft documentation that explains how to migrate a Logic Apps Standard Local Function from in-process to isolated worker.

I also tried changing my Local Function project from a library to an executable and adding a Program.cs using the isolated worker configuration. After deployment, the Logic Apps workflow could no longer load the Local Function actions, so I reverted the change.

Could someone from the Logic Apps team please confirm whether these Local Functions are affected by the November 10, 2026 retirement and, if they are, provide the supported migration approach?

Thank you.

AkarshaAkarsha-6739 0 Reputation points

2026-09-29T12:03:43.1266667+00:00

Thank you for the clarification.

This helps distinguish Logic Apps Standard Local Functions from standalone Azure Function Apps.

However, I still have one important concern regarding the November 10, 2026 retirement.

Could you please confirm whether the Logic Apps Standard Local Function runtime used by the "Call a local function in this logic app" action internally uses the Azure Functions .NET in-process model?

Specifically, I would like to confirm whether the November 10, 2026 retirement applies to the runtime that executes these Local Functions, even though the Local Function itself is part of the Logic Apps Standard project rather than a separate Azure Function App.

If the Local Function runtime is not the Azure Functions .NET in-process model, could you please confirm that the November 10, 2026 retirement does not apply to these Local Functions?

If this cannot be confirmed from the current documentation, could this question please be escalated to the Azure Logic Apps product team?

Thank you.
Tejaswini Billakurthi 765 Reputation points Microsoft External Staff Moderator

2026-10-01T12:10:58.26+00:00

Hi @AkarshaAkarsha-6739 ,

Thank you for the clarification. I understand that your question is specifically about the underlying runtime used by “Call a local function in this logic app”, rather than whether the Local Function is deployed as a separate Azure Function App.

The currently available public documentation does not provide definitive confirmation on whether the Logic Apps Standard Local Function runtime internally uses the Azure Functions .NET in-process model and, consequently, whether the November 10, 2026 retirement applies to this scenario.

Since this requires authoritative confirmation of the product's runtime behavior and any supported migration path, I recommend opening an Azure Support request for the Logic Apps Standard resource so the question can be investigated further with the appropriate product team.

When raising the request, please include the Logic Apps Standard resource and hosting plan, .NET/runtime version, relevant Local Function package versions, and the behavior you observed when attempting the isolated-worker configuration.

Until this is confirmed, I would not recommend applying the standard Azure Functions isolated-worker migration steps to the Logic Apps Standard Local Function.

2 answers

Your answer

AkarshaAkarsha-6739 0 Reputation points

2026-09-29T12:03:43.1266667+00:00

Thank you for the clarification.

This helps distinguish Logic Apps Standard Local Functions from standalone Azure Function Apps.

However, I still have one important concern regarding the November 10, 2026 retirement.

Could you please confirm whether the Logic Apps Standard Local Function runtime used by the "Call a local function in this logic app" action internally uses the Azure Functions .NET in-process model?

Specifically, I would like to confirm whether the November 10, 2026 retirement applies to the runtime that executes these Local Functions, even though the Local Function itself is part of the Logic Apps Standard project rather than a separate Azure Function App.

If the Local Function runtime is not the Azure Functions .NET in-process model, could you please confirm that the November 10, 2026 retirement does not apply to these Local Functions?

If this cannot be confirmed from the current documentation, could this question please be escalated to the Azure Logic Apps product team?

Thank you.
Tejaswini Billakurthi 765 Reputation points Microsoft External Staff Moderator

2026-10-01T12:10:58.26+00:00

Hi @AkarshaAkarsha-6739 ,

Thank you for the clarification. I understand that your question is specifically about the underlying runtime used by “Call a local function in this logic app”, rather than whether the Local Function is deployed as a separate Azure Function App.

The currently available public documentation does not provide definitive confirmation on whether the Logic Apps Standard Local Function runtime internally uses the Azure Functions .NET in-process model and, consequently, whether the November 10, 2026 retirement applies to this scenario.

Since this requires authoritative confirmation of the product's runtime behavior and any supported migration path, I recommend opening an Azure Support request for the Logic Apps Standard resource so the question can be investigated further with the appropriate product team.

When raising the request, please include the Logic Apps Standard resource and hosting plan, .NET/runtime version, relevant Local Function package versions, and the behavior you observed when attempting the isolated-worker configuration.

Until this is confirmed, I would not recommend applying the standard Azure Functions isolated-worker migration steps to the Logic Apps Standard Local Function.

Answer 1

Hi @AkarshaAkarsha-6739 ,

Thank you for reaching out to Microsoft Q & A !

Azure Logic Apps Standard local functions should be distinguished from functions hosted in a separate Azure Functions app.

According to the current Microsoft documentation, local functions are custom .NET code that you author, run, debug, and deploy as part of the same Logic Apps Standard project as the workflows. Local functions currently support .NET Framework and .NET 8 for Standard workflows hosted on Workflow Service Plan, ASE v3, and Hybrid.

The Azure Functions documentation states that support for the .NET in-process model ends on November 10, 2026, with migration guidance provided for Azure Function Apps moving to the isolated worker model.

However, the current Logic Apps documentation does not state that Logic Apps Standard local functions are included in that retirement, nor does it provide a documented migration procedure for converting a Logic Apps Standard local function used by “Call a local function in this logic app” to the Azure Functions isolated worker model.

Therefore, based on the currently available documentation, I would not apply the standard Azure Functions isolated-worker migration steps directly to a Logic Apps Standard local function unless Microsoft provides specific guidance for this scenario.

For now, the appropriate approach is to validate that the local function remains within the documented .NET 8 Logic Apps Standard local-function model and use the latest Azure Logic Apps (Standard) tooling.

Given the November 10, 2026 retirement date, it would be useful for the Logic Apps team to explicitly confirm whether these Local Functions are affected and, if so, provide the supported migration path.

Please "Accept the Answer" if this information helped you. This will help us and others in the community as well.

Answer 2

The documented retirement on November 10, 2026 is for the Azure Functions .NET in-process model. The provided documentation does not state that Azure Logic Apps Standard local functions are part of that retirement, and it does not provide a migration path from Logic Apps local functions to the isolated worker model.

What is documented for Logic Apps Standard local functions:

Local functions are a feature of Azure Logic Apps (Standard) and are created, debugged, deployed, and operated inside the same Logic Apps Standard project as the workflow.
Local functions for Standard workflows support .NET Framework and .NET 8.
The workflow calls them through the built-in action Call a local function in this logic app.
The documentation distinguishes these local functions from functions hosted in a separate Azure Functions app.

What is documented for Azure Functions retirement:

Support for the Azure Functions in-process model ends on November 10, 2026.
The supported path called out in the Azure Functions documentation is to migrate Azure Function apps to the isolated worker model.
The provided material does not describe an equivalent isolated-worker migration model for Logic Apps Standard local functions.

Based on the available documentation, the only supported conclusion is:

The retirement notice explicitly applies to Azure Functions in-process apps.
No documentation here confirms that Logic Apps Standard local functions are included in that retirement.
No supported migration approach is documented here for converting a Logic Apps Standard local function to the isolated worker model.

The behavior observed after converting the local function project to an executable with Program.cs is consistent with the Logic Apps local-function feature expecting the documented local-function project model, not an Azure Functions isolated worker app model.

References: