Logic Apps Standard has quietly become a place where C# developers feel at home. You can run inline C# scripts, call compiled .NET functions from a workflow, and – with the Azure Logic Apps Standard SDK in preview – define entire workflows in C#. At the same time, the platform is moving from the in-process to the out-of-process hosting model on its way to .NET 10, which affects how some apps are deployed. This guide helps you choose the right level of code and prepare for the hosting change.

Four ways to put code in Logic Apps Standard

Inline C# scripts

The Execute CSharp Script Code action builds on the Azure Functions C# script capability. You write a function in a .csx file inside the workflow; the runtime compiles it when the logic app initializes. It can read workflow context and log through an ILogger. Scripts can also be loaded from a shared folder in site/wwwroot, which helps when several workflows need the same small helper.

Use inline scripts for what they are: a few lines of logic that would otherwise become an unreadable expression. Once a script needs tests or is copied into a second workflow, move it to a custom code project.

Custom code functions

Custom code lets you write .NET functions in a project next to your logic app and call them with the built-in action “Call a local function in this logic app”. It supports .NET Framework and .NET 8 for workflows hosted in Azure, and the development experience in Visual Studio Code lets you debug workflow and code in the same session. Note that this capability requires Visual Studio Code on Windows.

Microsoft is explicit about the limits: custom code is not meant for processes that may run longer than 10 minutes, for very large message and data transformations, or for complex batching and debatching. It runs inside your App Service plan and consumes its CPU and memory, so heavy compute belongs elsewhere. For a worked example, see local functions in Logic Apps Standard workflows.

The Logic Apps Standard SDK: workflows in C#

The Azure Logic Apps Standard SDK (package Microsoft.Azure.Workflows.Sdk, in preview) lets you define workflows in C# instead of JSON. You create a “Logic app (codeful)” project in Visual Studio Code and implement workflow definitions through an IWorkflowProvider. The SDK uses a fluent builder model:

• WorkflowFactory creates stateful, stateless or agent workflows.
• WorkflowTriggers and WorkflowActions are the entry points to triggers and actions.
• Steps are chained in the style trigger.Then(action1).Then(action2).

The SDK compiles your definition and the workflow runs on the normal Logic Apps runtime. Run history keeps the same visual representation as designer-built workflows, which matters for operations teams that do not read C#.

When code actually makes the workflow better

• Reuse – the same sequence appears in many workflows and you want one implementation, refactored safely.
• Testability – rules and branching logic need unit tests that run in your build pipeline.
• Reviewability – pull requests on C# are easier to review than diffs of large workflow JSON files.

When none of those apply, the designer is usually the better tool: it is faster to change, easier for mixed teams, and closer to what operations sees in run history.

The hosting change on the road to .NET 10

Logic Apps Standard runs on the Azure Functions host. Microsoft is migrating Logic Apps Standard from the in-process hosting model to the out-of-process model as a step towards .NET 10 support. In Azure Functions terms, the out-of-process (isolated worker) model runs user code in a separate .NET worker process; for Azure Functions, in-process support ends on November 10, 2026.

What Microsoft has communicated for Logic Apps:

• The rollout started around July 30, 2026.
• Apps without the redirect flag migrate automatically when they restart.
• The app setting LOGICAPP_INPROC_REDIRECT=1 keeps an app on the in-process model until you are ready.
• Apps that use the NuGet-based deployment model need action: install the latest Azure Functions Core Tools, update the project configuration to out-of-process, and validate locally before removing the redirect setting.
• Separate guidance on the runtime and workflow versions for .NET 10 itself follows later.

A migration plan that avoids surprises

1. Inventory every Logic Apps Standard app and mark which use NuGet-based deployment or custom code.
2. Protect those apps by adding LOGICAPP_INPROC_REDIRECT=1 in your infrastructure-as-code, so a platform restart does not migrate them before you have tested. Make sure your pipeline does not remove the setting on the next deployment.
3. Test the out-of-process path in a non-production environment: build with the latest Core Tools, run the workflows, and compare run history and custom code behaviour.
4. Promote environment by environment, removing the redirect setting only after validation.
5. Wait for the dedicated .NET 10 guidance before changing target frameworks of custom code projects.

Checklist

• Code level chosen per workflow: designer, inline script, custom code or SDK.
• Shared logic in tested custom code, not copied scripts.
• SDK kept out of production-critical paths while in preview.
• Redirect setting managed in infrastructure-as-code for apps that are not yet validated.
• Out-of-process hosting validated per environment before .NET 10 changes.

Sources

• Azure Logic Apps Standard SDK reference
• Create Standard workflow projects with C# (preview)
• Create and run .NET code from Standard workflows
• Add and run C# scripts with Standard workflows
• Logic Apps Aviators newsletter, July 2026 (in-proc to out-of-proc migration)