Windows Workflow Foundation was once one of the most powerful ways to build workflow-driven applications in the Microsoft ecosystem. It gave .NET developers a visual designer, a runtime, and a structured model for creating business processes that could be configured without hard-coding every rule.

For many years, WF was a practical foundation for building internal tools, low-code workflow designer experiences, and even no-code workflow builder platforms.

But the software landscape has changed.

Today, users expect workflow tools to run in the browser. They expect modern web interfaces, easy integration with existing applications, and increasingly, AI-assisted ways to create, modify, and understand business processes. Maintaining a workflow product that depends on desktop-only tooling is becoming harder to justify.

The question is no longer whether Windows Workflow Foundation was a good technology. It was. The real question is whether it still fits the way modern software is built, deployed, and used.

For teams planning Windows Workflow Foundation migration, a practical first step is not always a full rewrite. In many cases, the best starting point is replacing the old desktop workflow designer with a modern workflow designer that runs directly in the browser.

Why Teams Look for a Windows Workflow Foundation Alternative​

Many WF-based products are still valuable. They often contain years of business logic, customer-specific processes, integrations, and domain knowledge. The problem is not always the backend. The problem is often the user experience around workflow design.

Classic Windows Workflow Foundation applications were built for a different era. Desktop tools were normal. Browser-based workflow designer interfaces were not the default expectation. Teams could accept complex local installations, Windows-only tooling, and designer experiences that were tightly connected to the .NET Framework ecosystem.

That is much harder today.

Modern users expect to open a browser, edit a workflow, save changes, collaborate with others, and continue working from anywhere. Modern developers expect embeddable components, JSON-based definitions, frontend framework support, and clean integration with existing systems.

This is why many teams are searching for a Workflow Foundation alternative. They do not necessarily want to throw away their entire platform. They want a realistic path for .NET workflow modernization.

A WF Replacement Does Not Have to Mean a Full Rewrite​

When people talk about a WF replacement, they often imagine a huge migration project: rewrite the designer, rewrite the runtime, rewrite the backend, convert all workflow definitions, and replace every piece of existing business logic.

That approach is possible, but it is not always the best first step.

A more practical strategy is to separate the problem into layers:

1. The workflow designer
2. The workflow definition format
3. The workflow runtime
4. The business logic
5. The backend services
6. The user interface around workflow management

Once you separate these layers, Windows Workflow Foundation migration becomes easier to reason about.

Maybe you only need to replace the designer first. Maybe your C# backend still works. Maybe your business logic should stay where it is. Maybe your first goal is simply to give users a modern workflow designer in the browser instead of forcing them to use desktop tooling.

That is where Sequential Workflow Designer can be useful.

Sequential Workflow Designer as a Modern Workflow Designer​

Sequential Workflow Designer is a browser-based workflow designer for building visual workflow editing experiences in modern web applications.

It can be used to create workflow builders, automation tools, low-code workflow designer interfaces, and no-code workflow builder experiences. Instead of depending on old desktop tooling, it allows teams to embed workflow design directly into a web application.

This is especially relevant for teams that are modernizing products built around Windows Workflow Foundation.

If your current WF-based application depends heavily on the visual designer experience, Sequential Workflow Designer gives you a way to move that part of the product into the browser. It does not require you to replace your whole backend on day one. It can become the new workflow UI while the rest of your system evolves step by step.

That makes it a practical Workflow Foundation alternative for teams that want modernization without unnecessary risk.

Replace Only the UI and Keep Your C# Backend​

One of the most important migration ideas is this: you do not have to replace everything at once.

If your existing backend is written in C#, you can keep it. Sequential Workflow Designer can be used as the browser-based workflow designer while your backend continues to handle execution, validation, persistence, permissions, and business rules.

In this model, the workflow designer becomes a modern web UI. The workflow definition can be stored as JSON. Your existing backend can read that definition and map it to your current execution model or business services.

This approach is useful when the biggest problem is not the backend, but the old designer experience.

For example:

• You want to replace a desktop workflow editor with a browser-based workflow designer.
• You want users to edit workflows inside your web application.
• You want to modernize the UI without rewriting all business logic.
• You want a better foundation for future .NET workflow modernization.
• You want to move away from WF gradually instead of starting with a risky full rewrite.

This is often the most realistic path for existing enterprise applications.

Use It with React, Angular, Svelte, or TypeScript​

Sequential Workflow Designer is not limited to one frontend framework. That matters because modern software teams use different stacks.

If your product is built with React, you can use Sequential Workflow Designer in a React application.

If your frontend is Angular, you can use it there as well.

If you use Svelte, plain TypeScript, or a custom frontend architecture, the same idea applies. The designer is intended to be embedded into modern web applications rather than locked to one specific platform.

This flexibility is important for teams searching for a Windows Workflow Foundation alternative. WF came from a tightly integrated .NET Framework desktop world. Modern applications are usually more distributed. The frontend may be React. The backend may be C#. Some services may be Node.js. Some systems may be cloud-native. Some business logic may still live in existing enterprise services.

A modern workflow designer should fit into that reality.

Where Sequential Workflow Machine Fits​

Sequential Workflow Designer focuses on the visual workflow design experience. It is the part users interact with when they build or edit workflows.

If you also want a JavaScript or TypeScript workflow execution layer, Sequential Workflow Machine can be considered as the runtime counterpart.

This can be useful when:

• Your backend is moving to Node.js.
• You want to execute workflows in a JavaScript or TypeScript environment.
• You are building a new automation platform.
• You want the designer and runtime to live closer to the same technology stack.
• You are creating a no-code workflow builder from scratch.

However, it is important to be precise. Sequential Workflow Designer alone is not a complete drop-in WF replacement. Windows Workflow Foundation included much more than a designer. It also included a runtime model, persistence concepts, and deep integration with the .NET Framework ecosystem.

A better way to describe Sequential Workflow Designer is this: it can be a practical part of a WF replacement strategy, especially when the first migration goal is to modernize the workflow design experience.

Possible Migration Paths​

Different teams need different levels of migration. A Windows Workflow Foundation migration does not have to look the same for every product.

The key point is that .NET workflow modernization can be incremental.

You can start by replacing the old workflow designer. Then you can decide whether the runtime should stay in C#, move to another .NET model, or eventually move toward JavaScript or TypeScript with Sequential Workflow Machine.

Recommended Approach for WF Modernization​

If you are maintaining a WF-based product, start by understanding what Windows Workflow Foundation actually does in your system.

Ask these questions:

1. Do users still use the visual designer?
2. Is the biggest pain the desktop workflow editing experience?
3. Is the runtime still working well enough?
4. Is the C# business logic valuable and stable?
5. Are workflows mostly configuration, orchestration, or long-running processes?
6. Do you need a full runtime replacement now, or only a modern workflow designer?
7. Could the workflow definition be represented as JSON?
8. Could the browser UI be modernized before replacing the backend?

In many cases, the answer is clear: start with the UI.

Replacing the designer first gives users an immediate improvement. It also gives developers a cleaner path toward future modernization. Instead of trying to replace the whole WF-based system in one step, you can gradually move toward a more flexible architecture.

Why Browser-Based Workflow Design Matters​

A browser-based workflow designer is not just a cosmetic upgrade. It changes how users interact with workflows.

Users no longer need a desktop designer. They no longer need a specific Windows environment just to edit a process. They can work inside the same web application where the rest of the product already lives.

This also opens the door for more modern product experiences:

• collaborative workflow editing
• workflow templates
• embedded validation
• AI-assisted workflow creation
• AI-assisted workflow explanation
• better integration with SaaS applications
• easier deployment
• better onboarding for business users
• no-code workflow builder experiences directly in the browser

This is one of the strongest reasons to consider a Workflow Foundation alternative. The goal is not only to remove old technology. The goal is to create a better workflow experience for users and a better architecture for developers.

Conclusion​

Windows Workflow Foundation was a strong technology for its time. It helped many .NET teams build workflow-driven systems, low-code platforms, and configurable business applications.

But modern software has moved toward browser-based interfaces, cloud-connected systems, AI-assisted tools, and more flexible frontend and backend architectures. For many teams, continuing to depend on desktop-only workflow tooling is no longer the best path forward.

A Windows Workflow Foundation migration does not need to start with a full rewrite. A practical first step can be replacing the old designer with a modern workflow designer that runs in the browser.

Sequential Workflow Designer is a strong option for that first step. It can be embedded into modern web applications, used with different frontend stacks, and integrated with an existing C# backend. When a JavaScript or TypeScript runtime is needed, Sequential Workflow Machine can also be evaluated.

For teams looking for a Windows Workflow Foundation alternative, the most realistic strategy may be simple:

Modernize the workflow designer first. Keep what still works. Replace the rest only when it makes sense.

Modern applications often need visual tools that allow users to design processes and automate tasks without writing code. From approval flows and task automation to no-code platforms and data pipelines, visual workflow editors are becoming a common feature in many web applications. Instead of building these editors from scratch, developers can rely on JavaScript libraries that provide ready-to-use workflow builder components.

In this guide, we compare three popular libraries used to build workflow editors in web applications:

• Sequential Workflow Designer
• React Flow
• JointJS

Each library approaches visual editors differently. Some focus specifically on workflows, while others provide general diagramming or graph editing capabilities that can be adapted for workflows.

What Is a JavaScript Workflow Builder?

A JavaScript workflow builder is a UI component that allows users to visually design processes directly inside a web application.

Instead of writing code, users can create workflows by connecting steps in a graphical interface.

Typical workflow builder capabilities include:

• drag-and-drop step creation
• connecting steps with arrows
• editing step configuration
• exporting workflows as JSON
• visualizing execution order

These tools are commonly used in:

• approval workflows
• automation systems
• no-code platforms
• data processing pipelines
• AI workflow editors

Some libraries focus on workflow structures, while others provide general diagram or node graph tools that developers adapt to workflow systems.

Sequential Workflow Designer

Type: Workflow builder
Framework: Framework-agnostic (JavaScript / TypeScript)

Sequential Workflow Designer is a lightweight open-source library designed specifically for building step-based workflow editors.

Unlike general diagram libraries, it focuses on structured sequential workflows, where steps execute in a defined order. This makes it particularly useful for applications that need approval flows, automation pipelines, or internal process builders.

The library is framework-agnostic, meaning it can be integrated into React, Angular, Svelte, or plain JavaScript applications.

Explore the project:

👉 https://github.com/nocode-js/sequential-workflow-designer

Key Features​

• visual workflow editor
• sequential step structure
• JSON workflow definitions
• customizable step configuration panels
• framework-agnostic core
• official wrappers for Angular, React, and Svelte
• no external dependencies

Framework Support​

Sequential Workflow Designer uses a framework-independent core, which means it can be integrated into almost any JavaScript application.

To simplify integration with modern frontend frameworks, official wrappers are available for:

• React
• Angular
• Svelte

These wrappers allow developers to embed the workflow editor directly into component-based applications while keeping workflow definitions portable via JSON.

Pros​

• purpose-built for workflows
• lightweight and easy to integrate
• framework-agnostic
• official wrappers for modern frameworks
• MIT licensed and fully open source

Cons​

• optimized for sequential workflows rather than arbitrary graphs
• smaller ecosystem compared to large diagram libraries

Best For​

• approval processes
• automation pipelines
• SaaS workflow builders
• no-code tools
• applications built with React, Angular, or Svelte

React Flow

Type: Node-based editor
Framework: React

React Flow is a widely used library for building node-based editors and visual graph interfaces in React applications.

Developers can create custom nodes, connect them with edges, and build highly interactive visual editors.

Because of its flexibility, React Flow is commonly used for:

• workflow editors
• visual programming tools
• AI pipelines
• data flow interfaces

However, React Flow is primarily a graph editor, so developers must implement workflow logic and execution themselves.

Key Features​

• customizable nodes and edges
• drag-and-drop editor
• zoom and pan controls
• layout integrations
• strong React ecosystem support

Pros​

• extremely flexible
• strong developer community
• ideal for React applications
• supports complex graph structures

Cons​

• React-only
• requires custom workflow logic
• more implementation work for workflow features

Best For​

• React visual editors
• graph-based tools
• visual programming interfaces

JointJS

Type: Diagramming framework
Framework: JavaScript / TypeScript

JointJS is a powerful diagramming framework used to build interactive diagrams and modeling tools.

It provides advanced capabilities such as custom shapes, connectors, and graph layouts, making it suitable for complex visual applications.

JointJS is often used to build:

• enterprise diagram editors
• BPMN modeling tools
• visual modeling platforms

However, like React Flow, it is not specifically designed for workflows and requires additional logic to implement workflow execution.

Key Features​

• customizable diagram elements
• graph modeling tools
• advanced interactions
• layout algorithms
• modular architecture

Pros​

• powerful diagram capabilities
• suitable for complex modeling tools
• extensive customization options

Cons​

• higher integration complexity
• some advanced features require commercial licensing
• not workflow-specific

Best For​

• enterprise diagram tools
• BPMN editors
• modeling applications
• complex visual editors

Comparison: JavaScript Workflow Builder Libraries

The following table summarizes the main differences between the three libraries.

When to Use Each Tool

Choosing the right library depends on the type of visual editor you want to build.

Use Sequential Workflow Designer if​

• you need a workflow builder UI
• your processes follow ordered steps
• you want a lightweight solution
• your application includes automation workflows

Use React Flow if​

• your application is built with React
• you need flexible node graphs
• you want to create custom visual editors

Use JointJS if​

• you need advanced diagramming capabilities
• you are building enterprise modeling tools
• you need highly customized diagrams

Using Sequential Workflow Designer with React, Angular, or Svelte

Sequential Workflow Designer can be integrated into any JavaScript application thanks to its framework-agnostic architecture.

Official wrappers simplify integration with modern frontend frameworks:

• React
• Angular
• Svelte

This allows developers to embed a workflow builder inside modern applications while keeping workflows portable and easy to manage.

Which JavaScript Workflow Builder Should You Choose?

If your application needs a structured workflow builder, using a tool designed specifically for workflows can significantly reduce development time.

Sequential Workflow Designer provides a lightweight approach to building visual step-based workflows, making it well suited for automation tools, SaaS platforms, and no-code applications.

For applications that require complex graph structures, tools like React Flow or JointJS provide greater flexibility but require additional implementation work.

Final Thoughts

Visual workflow builders are becoming an essential component of modern web applications. Whether you are building automation systems, no-code tools, or visual programming interfaces, selecting the right library can greatly simplify development.

Sequential Workflow Designer, React Flow, and JointJS represent three different approaches:

• workflow-focused builders
• node graph editors
• diagramming frameworks

Understanding these differences will help you choose the right technology and build powerful workflow-driven applications.

Starting with version 0.30.0, Sequential Workflow Designer makes it easy to build flow builders that support multiple triggers to start a flow. This enables rapid development of visual programming applications, empowering users - without any coding skills - to define clear, deterministic logic, often enhanced by AI.

How to start? At the start you need to install the Sequential Workflow Designer using NPM:

npm install sequential-workflow-designer

Now you need to import the designer to your code:

import { Designer, Uid } from 'sequential-workflow-designer';

// css
import 'sequential-workflow-designer/css/designer.css';
import 'sequential-workflow-designer/css/designer-light.css';

Before we continue, we need to define the task types that our flow builder will support. In this article, I’ll introduce three example task types: “Save file”, “Send email”, and “Loop”. However, you’re free to define as many task types as your use case requires. For example, each integration with an external system could be represented as a separate task type.

Next, we want the flow builder to let users define when a flow should start. We refer to these starting points as triggers. Triggers are special blocks that users can drag and drop into the start section of the flow, then configure accordingly. In this article, we’ll define three example triggers that will be available in the designer: “On email received”, “On file created”, and “On file modified”.

The goal is to create a flow builder that enables users to build flows starting from an event and then define a predictable sequence of logic. This logic will eventually be executed by a state machine, although we won’t focus on that part in this article.

Now, I’ll create two functions: one to generate a task and one to generate a trigger.

function createSaveFileStep() {
  return {
    id: Uid.next(),
    componentType: 'task',
    type: 'save-file',
    name: 'Save file',
    properties: {}
  };
}

function createOnEmailReceivedStep() {
  return {
    id: Uid.next(),
    componentType: 'task',
    type: 'trigger-on-email-received',
    name: 'On email received',
    properties: {}
  };
}

These functions are needed to complete the toolbox configuration. Now we're ready to initialize the designer for the first time.

const emptyDefinition = {
  sequence: [],
  properties: {}
};

const configuration = {
  steps: {},
  toolbox: {
    groups: [
      {
        name: 'Triggers',
        steps: [ createOnEmailReceivedStep() ]
      },
      {
        name: 'Tasks',
        steps: [ createSaveFileStep() ]
      }
    ]
  },
  controlBar: true,
  editors: false,
  placeholder: {},
  validator: {},
  extensions: []
};

const designer = Designer.create(
  document.getElementById('placeholder'),
  emptyDefinition,
  configuration
);

At this point, you should see the designer with an empty flow - no tasks added yet. Now, I’ll focus on creating a special section at the beginning of the flow where users can drag and drop only trigger blocks. It's important that this section accepts only triggers, not tasks. Likewise, triggers should not be allowed outside of this section. We can enforce these restrictions through the designer configuration.

Before we start, we need to add a special sequential step at the beginning of the flow definition. This step will act as a container for triggers. I’ll use the launchPad step component type to render it. This launch pad step component displays all nested steps aligned vertically and visually connected to the end of the container, creating the impression that any of the steps can trigger the flow.

While this component type can also be used for other use cases, such as parallel sections, it was primarily designed to handle triggers.

const emptyDefinition = {
  sequence: [
    {
      id: 'launchPad',
      name: 'Launch Pad',
      componentType: 'launchPad',
      type: 'launchPad',
      properties: {},
      sequence: []
    }
  ],
  properties: {}
};

Now, when you refresh the page, you should see a flow with a small container inside. At this point, you can drag and drop any step from the toolbox into this section — but that's not what we want. We only want to allow triggers in this section. To achieve this, we need to implement a custom placeholder controller and pass it to the designer by extending the configuration.

placeholder: {
  canCreate(sequence, index) {
    const definition = designer.getDefinition();
    const isRoot = sequence === definition.sequence;
    if (isRoot) {
      return index !== 0;
    }
    return true;
  },
  canShow(sequence, _, __, draggingStepType) {
    const definition = designer.getDefinition();
    const isTriggerStep = draggingStepType.startsWith('trigger-');
    const isLaunchPadSequence = sequence === definition.sequence[0].sequence;
    return (isLaunchPadSequence && isTriggerStep) || (!isLaunchPadSequence && !isTriggerStep);
  }
},

In the code above, I disabled the placeholder that appears before the launch pad step component, as I don’t want users to insert any steps before it. Then, in the canShow callback, I implemented a simple logic that hides placeholders if the dragged step type isn’t allowed in the target sequence.

After refreshing the page, you'll notice one issue: while drag-and-drop works as expected and the restrictions are in place, it's still possible to delete or move the launch pad step - which is not the intended behavior. To prevent this, I need to implement custom callbacks that restrict these actions.

steps: {
  isDuplicable(step) {
    return step.componentType !== 'launchPad';
  },
  isDeletable(step) {
    return step.componentType !== 'launchPad';
  },
  isDraggable(step) {
    return step.componentType !== 'launchPad';
  },
  isSelectable(step) {
    return step.componentType !== 'launchPad';
  }
},

Finally, everything is working as expected. We have created a flow designer that allows placing one or more triggers at the start of the flow, with various tasks arranged below.

To read the definition prepared by a user you need to call the getDefinition method on the designer instance. This will return a JSON object that represents the flow definition, including all steps and their properties.

const definition = designer.getDefinition();

Of course, this is just the beginning. Next, we need to implement editors for configuring all supported steps. Another important part is how to execute the designed flow, but that won’t be covered in this article. For more examples and detailed documentation, I recommend visiting the nocode-js.com website.

Check out the final online example 👉 here. You can also find the source code for this example and more on GitHub.

Links:

• Sequential Workflow Designer on GitHub
• Sequential Workflow Designer Examples

Zapier is among the most popular automation tools available. It enables you to connect your favorite apps and automate workflows. However, it comes with a downside—it can be expensive, and you might need many custom integrations that it doesn't support. Privacy and security are also concerns; you may be hesitant to share your data with a third-party service. Until now, creating a no-code platform was challenging, but with the NoCode JS Boilerplate, you can now create customized automation tools effortlessly.

What is NoCode JS Boilerplate?​

NoCode JS Boilerplate is a full-stack boilerplate that allows you to create a no-code platform. It comes with a lot of features out of the box. It's built using the latest technologies and is highly scalable. We prepared two versions of the boilerplate:

• Basic: This version uses Next.js framework and it's recommended for small projects. This boilerplate is available in GitHub.
• Pro: This version uses Next.js and React and it's recommended for large projects and more complex use cases. This boilerplate is available in a private repository. To get access to the repository, you need to buy a license here.

The boilerplate basically is a tiny no-code platform that allows you to create custom flows by using a visual builder. These flows may be executed by HTTP requests or scheduled tasks (only in the Pro version). Of course you can modify the boilerplate to fit your needs.

The most important is that you can create custom integrations with your own services. You can implement own steps and allow your users to use them in their flows. You can change the shape of the data that is passed between steps, you can add custom UI for your steps. At the end you can deploy the platform to your own infrastructure or use a cloud provider.

By using the boilerplate you can create:

• SaaS (Software as a Service) platform,
• Internal tool for your company,
• Custom automation tool for your clients.
• And many more.

How to Start?​

We are big fans of the "learn by doing" approach. Before you determine which version of the boilerplate you need, you can try the basic version. We recommend to deploy for free the boilerplate to Vercel and play with it. Check details in the GitHub repository.

Next you need one developer or a team of developers to adjust the boilerplate to your needs. We prepared an extensive documentation that will help you to understand NoCode JS components and how to adjust them. You can find the documentation on Nocode JS website.