Top 8 .NET Core Workflow Engines: Comparison & Code Examples (2026)

Modern .NET applications rarely need a workflow engine just to run three C# methods in sequence. The harder requirement is usually state that survives restarts, workflows that wait for external events, retries around unreliable dependencies, human approvals, or orchestration across APIs and services.

That makes the choice less about finding a generic “.NET workflow engine” and more about choosing the right execution model. Elsa and Workflow Core are embedded .NET options; Temporal is built around durable distributed execution; Camunda uses BPMN-based orchestration; Wexflow focuses more on scheduled technical automation; and Nected exposes workflow execution through APIs rather than embedding an engine in the application.

This comparison focuses on those architectural differences, with particular attention to .NET compatibility, persistence, long-running execution, integrations, deployment, and Azure-oriented environments.

What to Look for in a .NET Core Workflow Engine

For a production .NET application, these are the capabilities that actually change the architecture:

• Execution model: Embedded library, external orchestration service, or API-based workflow platform.
• Persistence: Whether workflow state survives application restarts and which stores are supported.
• Long-running execution: Ability to pause on timers, external events, or approvals and resume without keeping a process in memory.
• Workflow authoring: C# code, visual designer, BPMN, JSON, or a combination.
• Integration model: Native activities, REST APIs, message/event integration, databases, or custom extensions.
• Hosting: ASP.NET Core, worker services, containers, Kubernetes, managed cloud, or self-hosted infrastructure.
• Operational visibility: Execution history, workflow state, logs, retries, correlation, and failure handling.
• Azure fit: Whether the engine runs cleanly in Azure-hosted .NET applications and how it fits with services such as Azure SQL, containers, Service Bus, or AKS.

Top 8 .NET Workflow Engines at a Glance

Elsa Workflows

Elsa is an open-source .NET workflow engine that can run inside .NET applications or as a dedicated workflow server. Its strongest distinction is that the same workflow can be authored in C#, JSON, or through Elsa Studio, while the runtime persists workflow state, bookmarks, definitions, and execution records.

Key Features:

• Visual workflow designer: Elsa Studio provides a browser-based designer for creating and managing workflows rather than forcing every workflow definition into C#.
• Durable, event-driven execution: Workflows can pause for timers, webhooks, messages, or approvals and resume from persisted state.
• Pluggable persistence: Elsa supports persistence through EF Core providers and MongoDB/Dapper options, allowing teams to use infrastructure already present in their .NET stack.
• API and integration layer: HTTP endpoints, scheduling, databases, messaging systems such as Azure Service Bus and Kafka, and custom activities can be incorporated into workflows.

Pros:

• Works particularly well when workflow execution needs to remain close to an ASP.NET Core application.
• Studio gives operations and business teams a visual representation of workflows without removing developer control.
• Its modular architecture lets teams choose their persistence, hosting, authentication, and integration components rather than adopting a fixed infrastructure stack.

Cons:

• Its flexibility also means teams need to make architectural decisions around persistence, hosting, identity, and runtime configuration.
• Teams looking specifically for a fully managed distributed workflow service may find Elsa more infrastructure-heavy than a SaaS orchestration platform.
• Visual workflow authoring does not eliminate the need for developers when workflows require custom activities or application-specific integrations.

Workflow Core

Workflow Core takes a more code-first approach. Instead of centering the product around a visual workflow designer, developers define workflows through a fluent C# API. The engine persists workflow instances between steps, allowing execution to continue after delays or external events.

Key Features:

• Fluent C# workflow definitions: Workflow steps are expressed directly in application code.
• Step-level persistence: Running workflows can be persisted between steps and resumed later.
• Multiple persistence providers: Available providers include SQL Server, PostgreSQL, SQLite, MongoDB, DynamoDB, Cosmos DB, and Redis.
• External-event support: A workflow can defer execution and resume when an external event becomes available.

Pros:

• A natural fit for .NET teams that want workflow definitions to live alongside application code.
• Persistence is part of the workflow execution model rather than something developers have to build around every long-running process.
• Its provider model makes it possible to use existing database infrastructure instead of introducing a dedicated workflow datastore.

Cons:

• Code-first authoring is less accessible to business users than Elsa Studio or BPMN-based platforms.
• Teams looking for rich visual process modeling will need additional tooling or a different engine.
• Workflow logic remains closely connected to the application's codebase, which can increase deployment dependency when business process logic changes frequently.

WorkflowEngine.NET

WorkflowEngine.NET is an embeddable .NET workflow library designed for ASP.NET and .NET applications. Unlike a separate orchestration service, it manages workflow state, timers, rules, actions, and persistence inside the application architecture. Its current releases support modern .NET versions including .NET 6, 8, and 10.

Key Features:

• Embedded workflow runtime: Add the engine through NuGet rather than operating a separate workflow server.
• Visual Workflow Designer: Workflows can be modeled visually while remaining part of the application's runtime.
• Database-backed persistence: Supports SQL Server/Azure SQL, PostgreSQL, MySQL, Oracle, SQLite, and MongoDB.
• Durable process execution: Process state, timers, parameters, and transition history are persisted so workflows can recover after interruptions.

Pros:

• Particularly relevant for teams that want workflow execution directly inside an existing ASP.NET Core application.
• Existing database infrastructure can serve as the workflow persistence layer.
• Provides workflow-specific capabilities such as timers, rules, schema versioning, clustering, and inbox/outbox functionality without requiring a separate orchestration platform.

Cons:

• Commercial licensing needs to be factored into the architecture decision for production deployments.
• Its embedded model is less suitable when the organization wants workflow execution completely separated from individual application runtimes.
• Teams building highly distributed, failure-resistant orchestration may need capabilities beyond an application-embedded workflow engine.

Wexflow

Wexflow is an open-source, cross-platform workflow server with a stronger emphasis on scheduled and task-oriented automation than on embedding workflow execution directly into a .NET application's business layer. It supports sequential, flowchart, and approval workflows, along with a web dashboard and REST API.

Key Features:

• 100+ built-in activities: Provides ready-made workflow tasks instead of requiring every operation to be implemented as a custom activity.
• Cron-based scheduling: Useful for recurring operational jobs and scheduled workflows.
• Visual workflow designer: Workflows can be assembled through a drag-and-drop interface.
• REST API and monitoring: External applications can trigger and interact with workflows, while the dashboard provides execution statistics and logs.

Pros:

• Strong fit for scheduled jobs, file processing, integration tasks, and operational automation.
• The built-in activity library reduces the amount of custom workflow code needed for common operations.
• REST APIs make Wexflow usable from applications that are not themselves built around the Wexflow runtime.

Cons:

• Its task-oriented model is different from a durable application workflow engine such as Temporal.
• Teams wanting deeply integrated domain workflows inside an ASP.NET Core application's codebase may prefer an embedded library.
• Visual workflow tooling is useful for operational automation but does not replace the process-modeling capabilities of larger BPM platforms.

Nected

Nected takes a different approach from the embedded .NET engines above. Rather than placing the workflow runtime inside the .NET process, it provides a centralized workflow and decisioning layer that applications can invoke through APIs. For a .NET team, this means business workflows can be separated from the application's deployment cycle.

Key Features:

• Visual workflow configuration: Workflows can be assembled without implementing every process transition directly in C#.
• API-based execution: A .NET application can invoke workflows through APIs instead of embedding a workflow runtime.
• Rules and workflow in one layer: Decision logic can be evaluated as part of a larger workflow rather than being hardcoded into application services.
• Centralized management: Workflow and decision logic can be managed independently of individual .NET application deployments.

Pros:

• Useful when business logic changes more frequently than the underlying .NET application.
• API-based execution allows the same decision/workflow layer to serve applications beyond the .NET stack.
• Separating workflow logic from application code can reduce the need for application redeployment for routine business-rule changes.

Cons:

• It introduces an external service dependency where an embedded engine would execute inside the application.
• Network availability and API latency become part of workflow execution considerations.
• It is not a like-for-like replacement for a durable execution engine such as Temporal when the primary requirement is distributed recovery of arbitrary application code.

Temporal .NET SDK

Temporal should be treated differently from the embedded workflow engines in this list. Its .NET SDK is used to build workflows and activities in .NET, but execution is backed by the Temporal platform's durable execution model. Temporal is designed specifically for asynchronous, long-running, failure-resistant business logic rather than simply providing a workflow library inside an ASP.NET process.

Key Features:

• Durable execution: Workflow state survives application crashes, worker failures, network problems, and infrastructure interruptions.
• C# workflows and activities: .NET developers implement workflow orchestration using the Temporal SDK.
• Distributed workers: Workflow execution and activity execution can be distributed across worker processes.
• Retries and failure handling: Temporal handles durable workflow progress and recovery rather than requiring every application service to implement its own recovery state machine.

Pros:

• Strong fit for workflows that run for hours, days, or months and cannot lose state when infrastructure fails.
• Separates workflow orchestration from the lifecycle of individual application workers.
• Particularly useful for distributed systems where retries, timeouts, asynchronous activities, and failure recovery are core requirements.

Cons:

• More infrastructure and architectural commitment than an embedded .NET workflow library.
• Developers must understand Temporal's workflow-determinism model rather than treating workflows as ordinary C# methods.
• It can be unnecessary overhead for simple approval flows or short-lived application workflows.

Camunda

Camunda is better classified as a process orchestration platform than a native .NET workflow engine. Its core modeling approach uses BPMN and DMN, while .NET applications typically participate through APIs and integration mechanisms rather than embedding a Camunda runtime directly into the application.

Key Features:

• BPMN process modeling: Business processes are represented explicitly rather than as application-specific C# workflow classes.
• DMN decision modeling: Business decisions can be separated from process orchestration.
• Process orchestration: Coordinates human tasks, services, events, and external systems across a business process.
• API-based application integration: .NET applications can participate in Camunda-managed processes without turning the .NET application itself into the workflow engine.

Pros:

• BPMN gives architecture and business teams a standardized process model rather than a proprietary C# workflow representation.
• Useful when workflow spans multiple services, human tasks, and organizational boundaries.
• Separating process orchestration from individual applications can reduce coupling between the workflow and a specific .NET deployment.

Cons:

• It is a larger platform decision than adopting an embedded .NET workflow library.
• Teams only needing simple in-process orchestration may take on unnecessary BPMN/process-platform complexity.
• .NET developers must work with a platform whose workflow model is not fundamentally a native C# abstraction.

Duende Workflow / StepWise

For this slot, the important distinction is to verify the exact product and deployment model before treating it as equivalent to Elsa, Workflow Core, or Temporal. A .NET workflow product should be evaluated based on whether it provides durable workflow state, actual runtime orchestration, persistence, and production deployment support, rather than simply exposing workflow-like APIs.

Key Features:

• .NET-oriented workflow modeling: Designed around application workflows rather than requiring a separate Java or Python runtime.
• Workflow state management: Relevant where process state needs to survive beyond a single request.
• Application integration: Intended to connect workflow execution with application-level operations.
• Deployment within the .NET ecosystem: The key architectural question is whether it can fit the team's existing ASP.NET Core hosting and infrastructure model.

Pros:

• A .NET-focused approach can reduce the integration gap for teams already standardized on ASP.NET Core.
• More suitable for application-centric workflows than adopting a completely separate process platform for every use case.
• Can be considered when workflow logic needs to remain close to the application's domain model.

Cons:

• It should not be evaluated as a direct Temporal equivalent without validating its durability and distributed-execution model.
• Teams need to verify persistence, recovery, clustering, and production-operational capabilities against their actual workload.
• Its fit depends heavily on whether the requirement is application workflow orchestration or enterprise-wide process orchestration.

Windows Workflow Foundation to Modern .NET: What Changes?

Windows Workflow Foundation (WF) is part of the .NET Framework, not modern .NET. It was not brought forward to .NET Core/.NET 5+; System.Workflow.*, the WF designer, and WorkflowServiceHost therefore aren't available as native modern .NET components. Teams moving a WF application to current .NET need to either keep the workflow layer on .NET Framework, use a community port such as CoreWF, or migrate the workflows to another orchestration engine.

Here are the changes that matter during migration:

• Workflow runtime: WF4 workflows cannot simply be retargeted from .NET Framework to modern .NET.
• Designer: The original Visual Studio WF designer does not carry over to modern .NET.
• XAML workflows: Existing .xaml workflows and custom activities need compatibility assessment or redesign.
• WCF hosting: WF applications built around WorkflowServiceHost and WCF need a different hosting/integration model.
• Persistence: Existing WF persistence and tracking implementations need to be mapped to whatever persistence model the replacement engine provides.
• Custom activities: Activities built against System.Activities and other .NET Framework dependencies are a major migration checkpoint.

Bottom Line

Choosing a .NET workflow engine comes down to where workflow state should live and how the workflow needs to run. Embedded engines such as Elsa and Workflow Core keep orchestration inside the .NET application, while Temporal is designed for durable distributed execution and Camunda for BPMN-based processes spanning systems and teams.

Wexflow targets scheduled automation, while Nected keeps configurable workflows outside the application through APIs. Start with the execution model, then validate persistence, integrations, failure recovery, and deployment against a real production workflow.

FAQs

What is a .NET Core workflow engine?

A .NET workflow engine manages the execution and state of multi-step processes. The important distinction is whether the engine runs inside the .NET application, as with Elsa or Workflow Core, or operates as an external orchestration layer, as with Temporal, Camunda, or an API-driven platform.

What is the best workflow engine for .NET?

The answer depends on the workflow architecture. Elsa and Workflow Core target embedded .NET workflows; Temporal targets durable distributed execution; Camunda targets BPMN process orchestration; Wexflow targets scheduled technical automation; and Nected provides externally managed API-driven workflows.

Can .NET workflow engines run on Azure?

Yes. Embedded engines can run inside ASP.NET Core workloads hosted on Azure, while distributed engines can run through containers or managed services. The more important question is whether the engine's persistence and execution model fit the Azure services already in the architecture, for example, SQL Server/Azure SQL, Cosmos DB, Service Bus, or AKS.

How do I create a workflow in .NET Core?

With a code-first engine such as Workflow Core, workflows are defined in C# and executed by the workflow host. Elsa supports both programmatic and visual workflow definitions. Temporal uses C# workflow/activity code but delegates durable execution to the Temporal platform. Camunda instead treats the BPMN process as the orchestration model.

What is the difference between a workflow engine and Azure Logic Apps?

An embedded workflow engine becomes part of the application's runtime and codebase. Azure Logic Apps is a managed Azure service designed around cloud workflows and integrations. The practical decision is whether the process belongs inside the .NET application's execution model or in the cloud integration layer.

Can I migrate Windows Workflow Foundation to modern .NET?

Not by simply changing the target framework. Microsoft identifies Windows Workflow Foundation as unavailable on modern .NET. Teams need to inventory existing activities, persistence, integrations, and dependencies and then choose between a compatibility path and a redesigned workflow architecture.

Which .NET workflow engine supports long-running workflows?

Elsa and Workflow Core support persisted workflows that can pause and resume. Temporal is specifically designed around durable execution, where workflow state and progress survive worker and infrastructure failures. That makes Temporal particularly relevant when a workflow may remain active for hours, days, or longer.

Can Nected integrate with .NET applications?

Yes. The integration boundary is HTTP rather than an embedded .NET runtime. A .NET application can trigger a Nected workflow through its API and pass structured inputs to the workflow. This makes it relevant when workflow logic needs to be managed separately from the application's deployment lifecycle.

‍