DEV Community: Optimajet Limited

What Elsa Workflows and Workflow Engine NEO leave in your code

Optimajet Limited — Wed, 30 Sep 2026 15:43:48 +0000

Short answer. Workflow Engine NEO by Optimajet fits .NET products built around business state, human decisions, forms and tenant isolation. Elsa Workflows fits products built around technical orchestration, events, integrations and background work. In a multi-tenant approval product, Workflow Engine NEO supplies the Commands, permission checks, Inbox, Forms Plugin, tenant routing and process locks. With Elsa, the team adds an external task and forms layer and configures a distributed runtime, locking and scheduling for several nodes.

I am Rylee Soll. I lead the product team of Workflow Engine NEO at Optimajet, and I run our demos. Most weeks someone on a demo call asks why they should pay for a license when Elsa Workflows is MIT. A feature list cannot answer that. So I built one approval process in both engines and wrote down what each engine takes over and what stays in the application.

This post is the short version. The full comparison of Elsa Workflows and Workflow Engine NEO has the diagrams and both workflow definitions in C#. Every claim about Elsa in it links to Elsa's own documentation.

The approval process I built twice

The test case is a document approval. An employee submits a document, and a manager approves or rejects it. If the manager misses a three-day deadline, the process escalates to a senior manager.

The two engines model it differently. Workflow Engine NEO treats it as the lifecycle of the document. An Activity called ManagerReview carries the State "Under review". Two Commands, Approve and Reject, trigger the Transitions out of it, and only the manager may run them. A Timer moves the process to Escalated when the deadline passes. Elsa treats the same process as a graph of executable activities. A Fork in WaitAny mode runs two branches. A RunTask waits for the manager, and a Timer waits for the deadline. The first branch to finish cancels the other. How the workflow models differ shows both on one diagram.

The happy path says little about a workflow engine. I followed the process further, to where the state lives, what survives a restart, how two tenants stay apart, and what somebody has to operate at three in the morning. I compared Elsa 3.7, as its documentation stood in August 2026, with Workflow Engine NEO v22.

Who owns what

In both products, your application keeps its identity, its services and its business data. The difference is the block marked "You provide". With Workflow Engine NEO, it holds an Action Provider, which calls your services, and a Rule Provider, which checks identities. With Elsa, it holds custom activities and the whole human-task layer, including assignment, the Inbox, forms and the business audit.

For the approval process, the split looks like this.

Part of the approval	Workflow Engine NEO v22	Elsa Workflows 3.7
Decisions a user can take now	Workflow Runtime returns the Commands available to that user at the current Activity	Your task layer decides. Elsa's instance API does not list named business decisions
Who may approve	Restrictions reference Actors, and your Rule Provider checks the user's Identity	Your task layer checks the manager before it completes the task
Inbox and forms	Approval Plugin Inbox and Forms Plugin	Your team builds them or connects an existing task platform
Deadline and escalation	A Timer-triggered Transition moves the process to `Escalated`	The timer branch of `Fork(WaitAny)` wins, and your task layer closes or expires the task
Timers on several nodes	TimerManager polls due timers in batches from the shared database	Distributed Runtime, distributed locking, and clustered Quartz.NET or Hangfire with shared storage
A decision and the deadline at the same moment	A lock on the process instance lets only one of them run	The distributed runtime serializes execution, and your task layer must update the task atomically
Tenants	Logical, physical or hybrid tenancy. Through the HTTP API, the tenant scope covers the Inbox, forms, timers, history and permissions	Shared tables, a database per tenant, or both. Your task and forms layer enforces its own isolation
Decision history	Transition History records the route, trigger, actor, executor and time	The workflow journal records the technical flow, and your application writes the business audit
Code you still write	A Rule Provider, Actions and forms	A task and forms layer, plus application activities (four in this example)

Both engines persist long waits, version their definitions, support visual and code-first authoring, run child workflows and support multitenancy. What differs is how much of the human-task layer comes with the product.

Where the difference shows up

Human tasks and permissions

In Workflow Engine NEO, a decision is a Command on a Transition. Workflow Runtime lists the Commands that a user may run at the current Activity. When you ask it to, it checks the Rules again as the manager submits the decision.

In Elsa, RunTask creates a task ID and a bookmark, sends a request to your handler, and waits. Your task layer validates the manager and sends the task ID and the result to Elsa's task-completion endpoint, which resumes the workflow. The article draws the application integration for both engines.

A decision and a deadline at the same moment

Say the manager clicks Approve in the same second the deadline fires. In Workflow Engine NEO, the Command or the due timer locks the process instance through persistence, so only one of them runs, even across nodes that share the database. If the deadline wins, Approve is no longer valid.

In Elsa, Fork(WaitAny) cancels the losing branch, but it does not serialize two hosts that loaded the same instance. That takes the distributed runtime and a shared lock. Your task layer must still complete or expire the task atomically and reject a late answer. Concurrent events and process locking walks through the race in both engines.

Timers on more than one node

Workflow Engine NEO keeps timers in its database. TimerManager polls the due ones in batches, and in multi-server mode the runtimes take turns, so no external scheduler is involved.

Elsa's default local scheduler keeps one in-memory task per timer and rebuilds them from stored bookmarks after a restart. On several nodes, Elsa needs Distributed Runtime, distributed locking, and clustered Quartz.NET or Hangfire with durable shared storage. Your team runs and monitors that scheduler. The section on long-running waits in both engines links the Elsa documentation and scheduler source behind these points.

Tenants

Workflow Engine NEO supports logical tenancy in shared tables, physical tenancy in a dedicated database or schema, and hybrid tenancy that mixes the two. The HTTP API reads the tenant from the Workflow-Api-Tenant-ID header and routes the request to that tenant's runtime and database. Its tenant scope covers the Inbox, forms, timers, history and permissions.

Elsa supports shared tables and a database per tenant, and one connection-string factory can mix them. It scopes its own stores, Elsa Identity and the configured scheduler jobs by tenant. It has no built-in router for a schema per tenant, and your task and forms service has to enforce the same isolation on its own data. Multitenancy architecture in both engines compares the storage models in one diagram.

The editor in your frontend

Workflow Designer is a JavaScript component with React and Angular wrappers and Blazor interop. A custom activity type can supply a complete SVG node template. Elsa Studio is a Blazor application. Its custom elements and its React wrapper load the Blazor WebAssembly runtime, which makes the page heavier in JavaScript, React and Angular products. In a Blazor product, Elsa Studio is the more native fit. The article has the details on visual authoring and editor embedding.

When I would choose Elsa

If most of your complexity is events, integrations and background work rather than people and business state, choose Elsa. It is also the better fit in these cases.

Event and integration pipelines. Triggers and bookmarks, HTTP and MassTransit activities, dispatch, child workflows and parallel branches are Elsa's native model.
Code-first workflows owned by developers. WorkflowBase keeps typed inputs, outputs and variables in C#. Elsa Studio saves its edits as a separate draft, so the team picks C# or Studio as the source of truth.
Calls to models and tools. The optional Elsa Agents extension turns configured agents into activities and selected skills into functions a model can call.
Open source as a hard requirement. Elsa Core, Elsa Studio and Elsa's extensions use the MIT license, so you can modify and redistribute them.

Elsa can also cost less when your product already has the task, forms and operations pieces around it.

What the license pays for

Elsa Core is MIT and has no runtime license fee. Paid support and services come from independent providers listed on Elsa+.

The editions and prices of Workflow Engine NEO are on the pricing page. Every edition of Workflow Engine NEO includes Forms integration through the Forms Plugin, and every edition runs on several servers. For the approval product in this test, Workflow Engine NEO supplies the Commands, Rules, the Approval Plugin Inbox, tenant routing, timers and multi-server coordination. Your team configures them instead of building and running its own services for the same jobs.

So compare the price of Workflow Engine NEO with what you would build, run and support around Elsa. That means the task and forms code, the multi-tenant integration, the distributed operations and paid support.

If your Elsa design uses MassTransit, add one more line to the budget. Elsa can use MassTransit for broker-backed messaging, and its distributed-hosting guide uses it for cache invalidation across nodes. The current integration pins MassTransit 8.5.7, under Apache 2.0. MassTransit v9 requires a commercial subscription, and as of September 2026 Elsa has no committed v9 integration. The sources are in licensing and total cost.

Test both before you choose

A comparison ends where a proof of concept begins. Build the same approval in both engines, with a reminder, a deadline, an escalation and two tenants. Restart a host during a wait, race a decision against the deadline on two nodes, and update the definition while an older instance is still running. Then count the code and the deployed components that live outside the definition. Ask a second developer to change one rule without help, and write down how long it took.

For the Workflow Engine NEO side, request a 30-day trial key. If you compare engines with an AI assistant, give it the Markdown version of the full comparison, so it works from the same text you read.

If I read Elsa's documentation wrong anywhere, say so in the comments or in GitHub Discussions, and I will change the row in the full comparison. If you would rather see this against your own process, book a call. I am the person on the other side of it.

Workflow Engine by Optimajet is now a family of four products

Optimajet Limited — Fri, 25 Sep 2026 15:52:18 +0000

One workflow engine for every .NET scenario, as an embeddable library, an HTTP API or a standalone server, now in four products with a new website.

Key takeaways

The Workflow Engine Family by Optimajet is one .NET workflow engine in four products: Workflow Engine Free and Workflow Engine as an embeddable library, Workflow Engine NEO as an HTTP API, and Workflow Server as a standalone server. A scheme drawn in Workflow Designer or built in C# runs in all four.

Workflow Engine NEO is the flagship, for teams whose workflows are part of the product they sell. Workflow Engine NEO adds the Data API and RPC API groups of Workflow Engine HTTP API and ready multitenancy. A 30-day trial key from trial.workflowengine.io lets a team try Workflow Engine NEO on its own process before buying.

Every edition of Workflow Engine NEO includes Workflow Forms for human tasks. The Forms Plugin behind Workflow Forms integrates Form Engine, Optimajet's separate form product family, and shows each person only the forms whose commands they may run.

Workflow Engine Free, formerly Community Edition, is for personal, non-commercial use, needs no license key and allows 10 schemes and 4 execution threads.

Workflow Engine, Workflow Engine NEO and Workflow Server are source-available under a commercial EULA, and Workflow Engine Free is not. Engine source access is a one-year window, included with NEO Enterprise and an add-on for Workflow Engine Complete, NEO Business and NEO SaaS. Workflow Server source comes with Business Ultimate and Custom.

The engine has shipped inside commercial .NET products since 2014. The current release is 22.1.0, from August 2026, and its core library targets .NET Standard 2.0, supported on .NET 8, .NET 10 and .NET Framework 4.6.2.

The new workflowengine.io went live on September 22, 2026, with a comparison of the four products at workflowengine.io/products/compare/ and new documentation at docs.workflowengine.io. For existing users, the NuGet packages and their names, license keys and schemes stay the same.

The Optimajet team and I are proud of the work behind this launch. Since 2014, .NET teams have built Workflow Engine into CRM, ERP and HR systems, and into software that manages documents. Over those years, four products grew around the engine, and it was not always easy to see which one you needed. This launch fixes that. For .NET developers and teams, the product line is now more useful and easier to work with. The engine your applications run has not changed.

Thank you to every team that uses our products and tells us which features matter most to them and what they need next. We are especially grateful to Acer, AMCS Group, Avery Dennison, Conduent, Consolsys, DigiNation, Elm Company, EY (formerly Ernst & Young), Fiserv, Ideagen EHS (formerly ProcessMAP), Indra, KARL STORZ, Leah (formerly ContractPodAi), Ncontracts and Novartis. Their feedback shapes the features we build, and it makes each proof of concept with a new customer better. We could not have improved these products without them.

The four products share one workflow engine, and the schemes that describe your processes carry over when you switch between them. A new website went live on September 22, 2026, together with new documentation, and both are built to help you choose. Workflow Engine NEO is the flagship, built for teams whose workflows are part of the product they sell.

One workflow engine for every .NET scenario

The four products run the same engine in three ways. They differ in where it runs, how your application calls it and what the license includes.

As an embeddable library. Workflow Engine Free and Workflow Engine run inside your .NET application, and you call them from C#. They use the same NuGet packages. Workflow Engine Free is for personal, non-commercial use and needs no license key. It allows 10 schemes and 4 execution threads, the number of processes the engine advances at the same time. Workflow Engine is licensed for internal commercial applications, in two editions, Team and Complete.
As an HTTP API. Workflow Engine NEO, the flagship, is a separate product based on Workflow Engine. It adds the Data API and RPC API groups of Workflow Engine HTTP API and ready multitenancy to your application. A web front end, a mobile app or another service can then drive your processes.
As a standalone server. Workflow Server is a separate service you run in Docker. Any language can call it over HTTP.

All four run on your own infrastructure, and none of them is a hosted Optimajet service. The embeddable products keep process data in your database: SQL Server, PostgreSQL, MySQL, Oracle, MongoDB or SQLite.

Workflow Engine NEO is the flagship

Workflow Engine NEO is a separate product in the Workflow Engine Family. It is based on Workflow Engine, but it is not an edition of Workflow Engine. Its editions are Subscription, Business, SaaS and Enterprise. It is built for teams whose workflows are part of the product they sell. Typical products are a CRM, an ERP, an HR system or a document management platform.

Data API and RPC API. The OptimaJet.Workflow.Api package adds Workflow Engine HTTP API to your ASP.NET Core application. Without a NEO key it serves the Designer API and the Health Check API. With one, it also serves the Data API and the RPC API. The Data API reads and changes schemes, process instances, parameters, timers and approvals, with search, filtering and paging. The RPC API runs the engine, for example to create a process instance, execute a command or list the commands available now.
Multitenancy. One deployment serves many customers. The HTTP API applies the tenant to every built-in operation. Each tenant can live in shared storage, its own database or its own database schema, and one deployment can mix all three. In Workflow Engine, your code builds that isolation around a tenant ID.
Security. The HTTP API uses your application's ASP.NET Core authentication, such as JWT bearer tokens or cookies. Each operation has its own OperationId, and IWorkflowApiPermissions decides who may call it. The tenant header only selects the tenant. Whether the caller may use that tenant is a separate permission check, which you enable with API security. Your own endpoints stay your responsibility.
Scale. Every edition of Workflow Engine NEO runs on multiple servers. In Workflow Engine, multi-server needs the Complete edition, and Team runs on one server.
Workflow Forms for human tasks. Every edition of Workflow Engine NEO includes the Forms Plugin, installed as the WorkflowEngine.NETCore-FormsPlugin package. In Workflow Engine it is an add-on for Complete and is not available on Team. It binds a form to a workflow step and shows each person only the forms whose commands they may run. Submitting a form runs that command, and the workflow's restrictions are checked again. A tenant can have its own version of a form, with the shared one as the fallback.
Forms from Form Engine. The Forms Plugin integrates Form Engine, Optimajet's separate form product family. Form Engine Core renders the forms under the MIT license, and Form Engine Designer lets an analyst lay out a form without a frontend ticket. Workflow Engine NEO Enterprise includes the Form Engine Enterprise license, which covers the Designer, with OEM rights. On the other editions, that license is priced separately.
The right to ship. The Subscription and SaaS editions cover a public web app or SaaS, and the Enterprise edition adds OEM distribution. The pricing page states the licensed use of every edition.

In our comparison with Elsa Workflows, Workflow Engine NEO supplied the commands, permission checks, inbox and forms for one approval process. Elsa needed an external task-and-forms layer for the same process.

To evaluate Workflow Engine NEO, request a 30-day trial key. The key enables its licensed capabilities. Your team can then run the Data API, the RPC API and multitenancy on a process of its own before you buy. A one-hour demo walks through your case with us. For more depth, read Data API or RPC API, which one your caller needs and dynamic tenant registration in NEO 22.0.0.

One scheme runs in all four products

A scheme is the workflow definition you draw in Workflow Designer or build in C#. It runs in all four products, and schemes written for older versions still run on the current release. That is what makes the four products one family, and it makes the choice above safe to make early. Scheme compatibility is separate from upgrading the application. The runtime, the packages and the database follow the release notes, and 22.0.0, for example, required database migrations.

From Workflow Engine Free to Workflow Engine, you register a license key. The packages stay the same, and the key lifts the limits.
From Workflow Engine to Workflow Engine NEO, the switch itself is a license key. The existing application and its schemes keep running as they are, on the same version. Using the Data API, the RPC API and multitenancy is planned work. You add the packages, configure authentication and tenants, and write the code that calls them.
Workflow Server runs as a separate service, so moving to it changes how you deploy. Your schemes still carry over.

Source access and vendor lock-in

The first objection to a commercial engine is lock-in, because your product depends on code you cannot see. Three of the four products answer it. Workflow Engine, Workflow Engine NEO and Workflow Server are source-available, under a commercial EULA, and Workflow Engine Free is the one product without source access.

For Workflow Engine and Workflow Engine NEO, source access is a one-year window on GitHub to the full engine source, as is, to read and review. It is included with Workflow Engine NEO Enterprise and is an add-on for Workflow Engine Complete, NEO Business and NEO SaaS. Team and NEO Subscription do not include it. Workflow Server includes its full source for one year with the Business Ultimate and Custom editions.

Source access is one of several guards against lock-in. Every edition of Workflow Engine and Workflow Engine NEO except NEO Subscription is a perpetual license, so the version you bought keeps running. A lapsed NEO Subscription falls back to the Workflow Engine Free limits. The engine runs on your infrastructure and keeps process data in your own database. Your schemes carry over between the four products, and there are no royalties or per-execution fees. The pricing page shows the source access, license model and support of every edition.

What changed, and what did not

What is new

One product family, the Workflow Engine Family, and one comparison page for its four products.
A new website at workflowengine.io, with a page for each product and public prices for Workflow Engine and Workflow Engine NEO.
New documentation at docs.workflowengine.io, which starts with Evaluate and Get Started and defines every term in a Glossary.
Clear lines between products and editions, including source-code access and what needs a paid edition or an add-on.
A new name for the free product, Workflow Engine Free, formerly Community Edition.

What stays the same

The NuGet packages and their names.
The license keys you already have.
Your schemes, including those written for older versions.

Compare the four products row by row

The comparison of Workflow Engine products is the page to open before any other. It sets all four side by side, one capability per row, from durable execution and Workflow Designer to APIs, databases, multitenancy, scaling and licensing. Where the answer depends on the edition or an add-on, the cell names it. The Forms Plugin row, for example, reads "Not available" for the Team edition and "Add-on" for Complete. Every edition of Workflow Engine NEO includes it.

Row names link to the pages that document each capability, and the common questions are answered below the table. The same matrix is published as Markdown at workflowengine.io/products/compare/index.md. When you ask an AI assistant which of our products fits your case, give it that link. It can then answer from the same table you would read.

Why we rebuilt the site and the documentation

As the family grew, the old site no longer matched the way customers evaluate our products. Workflow Engine NEO had no page of its own, and the prices were on optimajet.com, a different site. The free product's old name also read like an edition of the paid library.

The new site starts from the choice. The comparison page answers what each product includes, the pricing page what it costs, and the documentation how it works.

The documentation starts one step earlier too, with Evaluate for the choice and Get Started for a first running process in about 15 minutes. The Glossary defines each product, edition and term once.

The new documentation is marked as a preview while its last pages are written, and both documentation hosts are official. The previous documentation still holds the release notes, the setup and security of the HTTP API, and the BPMN and database reference tables.

Where each answer lives

Workflow Engine pricing gives the price, license model, licensed use, limits, source-code access and support of every edition of Workflow Engine and Workflow Engine NEO. Every price is public except Workflow Engine NEO Enterprise, which we quote per project.
Enterprise support and security covers self-hosting inside your perimeter, security questionnaires and support plans with a committed response time. Tickets go to the engineers who own the codebase.
Workflow Engine features lists every feature in the documentation's catalog, each with one sentence and a link. Full pages with code and limits cover Workflow Designer, BPMN support, multi-tenant workflow architecture, Workflow Forms, database providers, the plugin system and LDAP and Active Directory authorization.
Workflow Designer also has pages for Blazor, JavaScript and React. The code on them ran on version 22.1.0. Each page has a prompt you can paste into Cursor, Claude Code or Copilot. The agent reads the page as Markdown before it changes your app.
Elsa Workflows vs Workflow Engine NEO builds the same approval process in both engines and says where each one fits.
How ProcessMAP runs EHS workflows on Workflow Engine shows the engine inside a commercial SaaS platform for environment, health and safety.

Written for AI assistants as well

You may ask an AI assistant about a library before you open its website, so the site gives that assistant pages it can read. The llms.txt file is a short map of workflowengine.io for AI tools, and llms-full.txt is the full product reference in one file. Both point an assistant to the Markdown copies of the comparison page, the pricing page, the Workflow Designer guides and the Elsa comparison. Every post in our blog has a Markdown copy and a Copy page button. Each documentation page can be copied as Markdown or opened in ChatGPT or Claude.

A coding agent can also request a 30-day trial key for you through trial.workflowengine.io/llms.txt. The request carries your business email and company name, so the agent should ask you first.

If something you used on the old site is missing, tell us in GitHub Discussions.

Frequently asked questions

Which Workflow Engine product do I need?

It depends on how you run the engine. For a library you call from C# inside a .NET application, use Workflow Engine, or Workflow Engine Free for personal, non-commercial use. For an HTTP API that a web front end, a mobile app or another service calls, use Workflow Engine NEO. It is also the choice when you serve many tenants. For a separate service in Docker that any language can call, use Workflow Server.

Is Workflow Engine open source?

No. Workflow Engine by Optimajet is commercial software with a free product, Workflow Engine Free, for personal, non-commercial use. Workflow Engine, Workflow Engine NEO and Workflow Server are source-available, with full source access in selected editions under a commercial EULA. Workflow Engine Free is the one product without source access.

How do I evaluate Workflow Engine NEO?

Request a 30-day trial key at trial.workflowengine.io. The key enables the licensed capabilities, including the Data API, the RPC API and multitenancy, so your team can test them on its own process. A coding agent can request the key for you through trial.workflowengine.io/llms.txt once you agree to share your business email and company name. A one-hour demo walks through your case with our team.

Does Workflow Engine NEO include forms for human tasks?

Yes. Every edition of Workflow Engine NEO includes the Forms Plugin, the component behind Workflow Forms. It binds a form to a workflow step and shows each person only the forms whose commands they may run. On submit it runs the command and checks the workflow's restrictions again. The Forms Plugin integrates Form Engine. Form Engine Core renders the forms under the MIT license, and Workflow Engine NEO Enterprise includes the Form Engine Enterprise license, which covers Form Engine Designer, with OEM rights.

What changed for existing Workflow Engine users?

Nothing in the product changed with the launch. The engine, the NuGet packages, your license keys and your schemes work as before, and the current release is 22.1.0. What is new is the family of four products, the comparison page, the website and the documentation.

Can I use Workflow Engine in software I sell to my customers?

Yes, with the right edition. Workflow Engine Team and Complete cover internal commercial applications. A public web app or SaaS needs the Subscription, SaaS or Enterprise edition of Workflow Engine NEO, and OEM distribution needs Workflow Engine NEO Enterprise.

Is Workflow Engine NEO a cloud service?

No. Workflow Engine NEO is software you run on your own infrastructure, like the other three products. The name of its SaaS edition describes your application, not a service that Optimajet hosts.

Where can I compare Workflow Engine products?

Use the comparison page at workflowengine.io/products/compare/. It sets Workflow Engine Free, Workflow Engine, Workflow Engine NEO and Workflow Server side by side, one capability per row. Where the answer depends on the edition or an add-on, the cell names it. A Markdown copy for AI assistants is at workflowengine.io/products/compare/index.md.

Is Workflow Engine Free an edition of Workflow Engine?

No. Workflow Engine Free is a separate product for personal, non-commercial use, and it needs no license key. It uses the same library as Workflow Engine, limited to 10 schemes and 4 execution threads. A Workflow Engine license key lifts those limits, and the packages stay the same.

Can I move an application from Workflow Engine to Workflow Engine NEO?

Yes. Register a Workflow Engine NEO license key, and the application keeps running as before, on the same version. To use the Data API, the RPC API and multitenancy, you add the packages, configure authentication and tenants, and write the code that calls them. Your schemes carry over, as they do between all four products.

Where is the previous Workflow Engine documentation?

It stays online at workflowengine.io/documentation/ while the new documentation at docs.workflowengine.io is in preview. Release notes, setup and security of the HTTP API, and the BPMN and database reference tables are still there.

Start with Workflow Engine NEO

Its page shows what the Data API, the RPC API, multitenancy and the Forms Plugin add. Compare it with the other three products, and book a demo when you want to walk through your case with us.

Your coding agent can now write a .NET workflow engine integration

Optimajet Limited — Wed, 29 Jul 2026 19:34:17 +0000

Ask Codex, Claude or Cursor to wire a workflow library into a .NET service and you usually get code that looks right and calls a method that doesn't exist. Say the agent gets past that. It then hits the line "obtain a license key from the vendor" and stops, because that step was built for a human with a browser and an email inbox.

I work on Workflow Engine at Optimajet, and we've recently rebuilt our documentation. The new primary documentation is available at docs.workflowengine.io. It is gradually replacing the legacy documentation at workflowengine.io/documentation. It publishes its full text as a single file so an agent reads the whole thing in one request instead of guessing, and a trial key can now be obtained by an agent, without a human clicking through a form.

The rest is for humans: 57 pages, four sections, 24 feature pages, 17 pages that each define exactly one concept, plus the generated C# API reference on its own host, api.workflowengine.io, 1256 pages across 20 packages.

If you've never touched the product: Workflow Engine by Optimajet is an embeddable .NET library for workflow automation. You add a NuGet package to your app, point it at the database you already have, and it handles process state, transitions, timers, rules and actions in-process. Nothing extra to deploy, no separate workflow server to babysit. It works on .NET Framework 4.6.2 and up as well as modern .NET and ASP.NET Core, and it persists to SQL Server (2017+), PostgreSQL, MySQL, Oracle, SQLite or MongoDB, whichever provider package you install.

A quick note before anyone asks: Workflow Engine is commercial software with a free tier. It's not open source, but Enterprise customers can obtain the full source code as part of their license. We've been shipping it since 2014. The latest stable release is 22.0.0, released on July 16, 2026.

Two text files and a key

llms.txt is the index, every published page with a one-line description, about 11 KB. llms-full.txt is the full text of every page with its source URL attached, about 480 KB. One fetch gives an agent the complete documentation corpus together with source URLs, making it easier to reference documented APIs instead of inferring them.

The key is the other half. trial.workflowengine.io/llms.txt carries instructions an agent can follow to obtain a trial license key by itself. Writing correct integration code and then stalling on paperwork is a stupid way to lose an evaluation, and it was the failure we kept watching happen.

The API reference host publishes an llms.txt too. Bookmark api.workflowengine.io: it's the generated C# reference for all 20 packages (Core, six database providers, six plugins, the Migrator, and the Web API with its six provider packages). The main docs don't link to it yet, so browsing won't get you there. That one's on us, it's in the queue.

What's actually on the site

Section	Pages	What it's for
`/evaluate/`	30	Deciding. 24 feature pages, the edition list, licensing and trial keys.
`/get-started/`	24	Running it. Install, first workflow, designer integration, 17 concept pages.
`/roadmap/`	1	What's next.
`/video-tutorials/`	1	For people who'd rather watch.

The feature pages are one page per capability, named the way the product names them: Visual Designer, Simple Process Notation, Process Versioning, Parallel Processes, Timers & Scheduling, Direct State Control, HTTP API, BPMN Support, Plugin System, Pluggable Security, Clustering, Multitenancy, Attachable Forms, Customization, Multi-Database Support, Bulk API, Work Calendar, Pre-Execution (Simulation), Process Logs, Workflow as Code, Database Versioning, Offline API, Interactive Designer, Workflow Templates.

The concept pages were the ones I most wanted to exist. Seventeen terms, one page each, no page trying to explain four things at once: activity, transition, command, scheme, process instance, workflow runtime, persistence, action, parameter, condition, rule, timer, annotation, process logs, localization, subprocess, work calendar. Workflow tools all use the same handful of words to mean slightly different things, and a shared vocabulary saves a lot of arguing.

Fifteen minutes, roughly

Get Started is three short pages: install, define a scheme, start an instance. Here's the shape of it, with SQLite because it doesn't need a server running.

dotnet new webapi -n WorkflowApi --framework net10.0
cd WorkflowApi
dotnet add package OptimaJet.Workflow.Api
dotnet add package OptimaJet.Workflow.Api.Sqlite

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddControllers().AddJsonOptions(ConfigureJson);
builder.Services.AddWorkflowApiSqlite();
builder.Services.AddWorkflowApiCore(SetupWorkflowApiCore);
builder.Services.AddWorkflowRuntime(SetupWorkflowRuntime);

var app = builder.Build();

app.UseRouting();
app.MapWorkflowApi();
app.Run();

You can write the scheme as XML, or draw it in the designer without installing the designer at all:

npx @optimajet/workflow-designer http://localhost:5274/workflow-api/designer Approval

That opens the full designer in a browser tab, wired to your local Web API. Save from there and the scheme goes into your database. Then start a process instance:

curl -X POST http://localhost:5274/workflow-api/rpc/create-instance \
  -H "Content-Type: application/json" \
  -d '{ "schemeCode": "Approval", "processId": "a3f5b2c1-4d6e-7f8a-9b0c-1d2e3f4a5b6c" }'

You need the .NET SDK 10.0 and a database for that path, and SQLite counts, it's just a file. Console apps and worker services have their own page, Framework-Agnostic Install. We didn't want ASP.NET Core to be a precondition for trying the library.

Editions

The license key you pass to WorkflowRuntime.RegisterLicense() decides which edition you're running. Same package either way, so moving up a tier is a key swap, not a rewrite.

Edition	License	Limits and additions
Workflow Engine Free	Perpetual, personal and non-commercial	10 schemas, 4 execution threads, unlimited activities, transitions and commands, Optimajet branding in the designer, no key needed
Workflow Engine Team	Perpetual, internal commercial use	No schema limit, higher thread and command limits, single server, 365 days of updates
Workflow Engine Complete	Perpetual, internal commercial use	No usage limits, multi-server clustering, no designer branding
Workflow Engine NEO	Annual subscription	RPC and REST API, full hybrid multitenancy, clustering, forms integration
Workflow Engine NEO Business	Perpetual	NEO APIs, clustering, forms, without full hybrid multitenancy
Workflow Engine NEO SaaS	Perpetual	Full NEO set, plus Active Directory connector and BPMN import
Workflow Engine NEO Enterprise	Perpetual	All of the above, plus white-label canvas, OEM redistribution, the FormEngine React form builder, one year of source code access

Details are on Workflow Engine Editions, key mechanics on License Key.

Documentation status

The documentation at docs.workflowengine.io is the new primary documentation for Workflow Engine. It is intended to replace the legacy documentation hosted at workflowengine.io/documentation/ over time.

The migration is still in progress. The new documentation already covers evaluation, installation, concepts, features, tutorials and API usage, but some reference material remains on the legacy site while it is being reviewed, updated and migrated.

At the moment both documentation sites are maintained. If a topic cannot yet be found in the new documentation, the legacy documentation remains the authoritative source for that section until migration is complete.

What hasn't moved yet

This is the section most docs announcements leave out, and it's the one that saves you a search.

Still on the old host at workflowengine.io/documentation/:

Web API setup and Web API security reference
Release notes and version history
BPMN element tables, BPMN differences, the BPMN plugin reference
Database entity tables

Those pages are alive and correct, they just haven't been rewritten for the new site. And Workflow Server, which is a different product with its own license, documents itself at workflowserver.io/documentation/. Don't go hunting for it under the engine docs, it isn't there.

Where to go for what

You want	Page
Install into ASP.NET Core	`/get-started/install-workflow-engine/`
Install into a console app or worker	`/get-started/framework-agnostic-install/`
Your first workflow	`/get-started/create-your-first-workflow/`
Run or embed the designer	`/get-started/integrate-the-designer/`
A term you don't recognise	`/get-started/concepts/`
One feature in depth	`/evaluate/workflow-engine-features/`
A C# type or method signature	api.workflowengine.io
A trial key	trial.workflowengine.io

Questions we get

What is Workflow Engine by Optimajet?
An embeddable .NET library for workflow automation. It's a NuGet package inside your application, using your database, running in-process. No separate workflow server.

Is Workflow Engine open source?
No. Commercial software with a free tier, under a commercial license. Workflow Engine Free is perpetual and needs no key, but it's personal and non-commercial use only, capped at 10 schemas and 4 execution threads.

Which databases does it support?
SQL Server 2017 and above, PostgreSQL, MySQL, Oracle, SQLite, MongoDB. You install the matching provider package and register it at startup.

Which .NET versions?
.NET Framework 4.6.2 and up, plus modern .NET and ASP.NET Core. The ASP.NET Core quickstart targets the .NET SDK 10.0.

Where is the documentation now?
Main docs at docs.workflowengine.io. Generated C# API reference at api.workflowengine.io. Web API setup and security, release notes, BPMN tables and database entity tables are still at workflowengine.io/documentation/. Workflow Server is at workflowserver.io/documentation/.

Can an AI agent read the docs?
Yes, that's what llms.txt and llms-full.txt are for, and the API reference host has its own llms.txt. An agent can also get a trial key by following trial.workflowengine.io/llms.txt.

Why not just write my own state machine?
Some teams should. The moment you need persistence, timers, rule evaluation, scheme versioning, clustering and a visual editor a business user can open, you're building a product next to your product. That's the trade we ask people to think about before adopting anything, ours included.

Go poke at it

docs.workflowengine.io/get-started/ if you want code in front of you in the next quarter of an hour. docs.workflowengine.io/evaluate/ if you're still deciding whether an embedded engine beats rolling your own.

And if a page is wrong, missing or confusing, tell me in the comments. I'd rather hear it here than not hear it at all.

Workflow Engine NEO 22.0.0: the multitenancy questions SaaS teams should ask

Optimajet Limited — Thu, 23 Jul 2026 12:04:16 +0000

On July 16, 2026, we released Workflow Engine NEO 22.0.0. Version 22 builds on the existing TenantId and multi-tenant Web API support and addresses two harder problems:

a Workflow Engine Web API host can now add and remove tenant configurations while the application is running; and
logical tenant scope now reaches workflow definitions, configuration, forms, processes, and process-related data more consistently.

Together, these changes complete support for physical, logical, and hybrid multitenancy in one Workflow Engine Web API host. A SaaS platform can give selected customers dedicated runtimes and databases, place others in logically isolated groups on shared infrastructure, and manage the entire topology through the same application. This flexibility is the central architectural capability in version 22.

I am Mike Lukinov, co-founder of Optimajet. This article explains how the three models fit together, then reviews the questions a SaaS team should answer before choosing its tenant architecture: where isolation lives, how tenants enter and leave the system, where authorization is enforced, what may be shared, and where product responsibilities split.

What hybrid multitenancy means

Workflow Engine Web API separates physical and logical tenancy.

A physical tenant is a runtime and provider boundary. It can use a dedicated database and can serve one or more logical tenant IDs. Logical tenants share that runtime and provider, while their workflow data is separated by TenantId.

Hybrid multitenancy means using both mappings in one Web API host:

One ASP.NET / Workflow Engine Web API host
|
|-- Physical tenant A
|   |-- Runtime and provider A
|   |-- Dedicated database A
|   `-- Logical tenant ID: acme
|
`-- Physical tenant B
    |-- Runtime and provider B
    |-- Shared database B
    `-- Logical tenant IDs: globex, stark

Acme has its own runtime and database boundary. Globex and Stark share a runtime and database with logical separation. That combination is hybrid tenancy.

The five architecture questions

Question	Architecture decision
Where should the isolation boundary sit?	Shared database, dedicated database, or a combination of both.
Does onboarding require a deployment?	Whether the tenant catalog belongs to application startup or to a runtime control plane.
Where is the security boundary?	How identity, tenant authorization, routing, and persistence work together.
What is isolated and what may be shared?	Which data belongs exclusively to a tenant and which definitions act as common defaults.
Where does the engine's responsibility end?	The boundary between Workflow Engine and the surrounding SaaS control plane.

Question 1: where should the isolation boundary sit?

Workflow Engine NEO supports three answers.

Logical tenancy puts several tenant IDs behind one runtime, provider, and database. It minimizes the number of infrastructure units while separating workflow data by tenant ID.
Physical tenancy gives a tenant its own runtime and provider configuration. When its provider points to a dedicated database, it also creates an independent backup and restore boundary.
Hybrid tenancy uses physical isolation for customers that require it and logical isolation for customers that can share infrastructure.

The choice should follow operational requirements: data residency, regulatory commitments, independent backup and restore, database-provider requirements, and the acceptable impact of a database-level incident.

A physical tenant remains part of the same ASP.NET application deployment. Its boundary covers runtime and persistence, while the application version and host process stay shared. Tenant-specific definitions also work in the logical model, allowing customized workflows to use shared infrastructure.

Question 2: does onboarding require a deployment?

Version 22.0.0 lets a multi-tenant host start with a partial tenant catalog and accept tenant registrations later. Adding or removing a Workflow Engine tenant becomes a control-plane operation during the lifetime of the ASP.NET application.

The important architectural property is consistency during change. New requests use the updated tenant map, while requests already in progress continue with the view under which they started. Removing a tenant stops new requests from being routed to it without invalidating work that is already using the previous routing state.

Customer onboarding still spans the wider SaaS control plane:

provision a database or choose a shared one;
create and store credentials;
configure identity, billing, quotas, and product-specific data; and
register the resulting runtime and tenant mapping with Workflow Engine.

Offboarding has the same separation of concerns. Removing a tenant affects routing, while database lifecycle and retention remain separate. Traffic removal, runtime shutdown, archival, and data erasure should remain explicit operations.

Adding a physical tenant changes the runtime and provider topology. Adding a logical ID extends an existing shared tenant group. The control plane should model them as distinct operations.

Question 3: where is the security boundary?

Tenant routing and tenant authorization are separate decisions. The tenant identifier on a request selects context. Caller identity and permissions establish access to that context.

An effective boundary has four layers:

Layer	Responsibility
Identity and authorization	Establish who the caller is and which tenant and operations the caller may access.
Tenant routing	Map the selected logical tenant to the correct runtime and provider.
Workflow persistence	Keep built-in process reads and writes inside the selected tenant or dedicated database.
Application integration	Apply the same tenant rule to custom endpoints, actions, external services, and application-owned tables.

Version 22.0.0 strengthens the built-in Workflow Engine Web API path: Data API and RPC API process operations apply the current tenant context to process access.

Application-wide tenant safety also depends on direct provider access, custom queries, domain tables, file storage, caches, and message handlers carrying the same tenant context. Workflow Engine enforces the data it owns; the application extends that boundary across the rest of the system.

Question 4: what is isolated and what may be shared?

The answer differs for operational data and reusable configuration.

Data group	Tenant behavior
Process instances and operational records	Tenant-scoped. This includes process status, parameters, timers, transition history, inbox entries, and approval history.
Workflow definitions	A standard definition can be shared, while a tenant-specific definition can replace it for one customer.
Forms	Shared forms can act as defaults, with tenant-specific forms taking priority where configured.
Global Parameters	Values can live in shared or tenant scope. If the application wants shared values to act as defaults, that fallback should be an explicit policy.

This gives a SaaS product a useful customization model: most customers can run a standard approval flow, while selected customers use a tenant-specific version without requiring another application deployment.

The safe general rule is simple: process state belongs to one tenant; reusable definitions and configuration may be shared deliberately. Records without a tenant value follow the sharing and fallback policy of their resource type.

Question 5: where does Workflow Engine's responsibility end?

Workflow Engine NEO 22.0.0 supplies the workflow-side building blocks: tenant topology, runtime lifecycle, tenant-aware API behavior, and shared or scoped workflow resources. The surrounding SaaS architecture decides:

which customers require dedicated storage;
how databases, secrets, identities, and non-workflow data are provisioned;
how users acquire membership in a tenant;
how long offboarded tenant data is retained;
how custom application code enforces tenant context; or
how tenant limits, billing, and product entitlements are applied.

These are SaaS architecture and product-policy decisions. Workflow Engine participates in one part of the boundary, and the application completes it. Each responsibility should have an explicit owner.

An architecture review checklist

Use this checklist during the architecture review. For every item, record the decision, its owner, and the evidence that confirms it. The review is complete when the team has produced all five artifacts.

[ ] A tenant placement map. Assign each customer segment to a logical, physical, or hybrid topology. Show which tenant IDs share a runtime and database, which customers receive dedicated resources, and which requirement drives each choice.
[ ] A tenant lifecycle flow. Document the complete onboarding and offboarding sequence: infrastructure provisioning, secret creation, tenant registration, traffic activation, routing removal, archival, and deletion. Name the system or team responsible for every step.
[ ] An authorization rule and its test. Define where the tenant ID comes from, how caller membership is verified, and which permissions are required before routing. Add a test that changes the tenant ID while keeping the same identity and confirms that access is rejected.
[ ] A data ownership matrix. Classify processes, operational records, workflow definitions, forms, and Global Parameters as tenant-owned or shared. Record the override and fallback policy for every shared resource type.
[ ] A responsibility map for integrations. List custom endpoints, direct provider calls, background jobs, application tables, files, caches, and messages. Assign an owner and document how each path receives and enforces tenant context.

The resulting placement map, lifecycle flow, authorization test, data matrix, and responsibility map become the implementation contract for multitenancy. They give developers, security reviewers, and operations teams the same definition of the tenant boundary.

The detailed migration steps and API changes are in the Workflow Engine 22.0.0 release notes. For Workflow Engine NEO licensing options, see Optimajet product pricing.

If you want to check our answers against your own architecture, the upgrade details are on our blog, and my team does demo walkthroughs where we build the argument on your tenancy model, not ours.

Workflow Engine NEO trials are self-serve now, and your coding agent can grab one too

Optimajet Limited — Thu, 11 Jun 2026 14:17:10 +0000

You can grab a Workflow Engine NEO trial key yourself now, no email thread. Go to trial.workflowengine.io, type a business email and a company name, and a 30-day Ultimate key shows up in your inbox.

The part I'm actually excited about

There's a sibling endpoint for AI coding agents. POST to https://trial.workflowengine.io/api/trial/llm with { "email": "...", "companyName": "..." } and you get the same key back. Contract is at trial.workflowengine.io/llms.txt. Business email only (no gmail, yahoo, disposable).

Two more llms.txt files live on the docs side and pair with this:

https://workflowengine.io/llms.txt is the index of authoritative docs.
https://workflowengine.io/documentation/llms-full.txt is the full reference in one file.

Hand all three URLs to your agent (Claude Code, Cursor, Copilot, whatever you use) and it can pull a license and read current docs in the same session. Our library has been through several versions where API names moved around. If your agent writes Workflow Engine NEO code from memory, half the time it'll write something that compiled in 2025.

The prompt I give my own agent

Paste this into your agent's system prompt:

You are working with OptimaJet Workflow Engine NEO.

Before writing or recommending code:
1. Fetch https://workflowengine.io/llms.txt for the index of authoritative docs.
2. Fetch https://workflowengine.io/documentation/llms-full.txt for the full reference.
3. Treat these as the source of truth. Do NOT rely on pre-trained knowledge
   of Workflow Engine NEO; the API surface has changed across versions.

If you need a working license to run examples:
- POST {"email":"you@yourcompany.com","companyName":"Your Co"} to
  https://trial.workflowengine.io/api/trial/llm
- The contract is documented at https://trial.workflowengine.io/llms.txt
- Business email required (no gmail/yahoo/disposable). Three keys max per email.
- The key is returned in the response body and also emailed.

When those three URLs are included in the context, your agent’s code actually compiles. Without them, it picks the wrong overload most of the time.

If you grab a key and run into something the docs don't cover, or you want help planning a rollout, book a call at workflowengine.io/contacts/. Bring a concrete task and we can scope a free POC.

Tell us in the comments if anything here reads off.

When to use Data API vs RPC API in Workflow Engine NEO: a .NET architect's guide

Optimajet Limited — Tue, 19 May 2026 16:22:40 +0000

I am Mike Lukinov, co-founder of Optimajet. Since 2022, I have been closely involved in customer architecture and developer experience work around Workflow Engine by Optimajet. I sit in most customer architecture meetings where Workflow Engine NEO questions repeat. The pattern I see most often when teams adopt Workflow Engine NEO is this: an architect picks the RPC API for every integration because "the RPC API is the obvious API." Six months later that team has a BI dashboard, a mobile app, and a partner integration all calling the same RPC surface, and a security review is asking why a read-only analyst token can start and cancel processes. This is the article I wrote instead of answering each case from scratch.

Workflow Engine NEO ships two HTTP surfaces, the Data API and the RPC API; the choice between them is a security and blast-radius decision, not a syntax preference. Everything below is personal opinion, grounded in those customer conversations. Throughout I mark each block as Documented behavior, Architectural recommendation, or Risk if ignored, so you can separate Optimajet facts from opinion. The framing should hold even if you pick a different boundary.

Version note. The code examples below target Workflow Engine NEO v21.0.0 and later, where Web API authorization uses a compact WorkflowApiPermissions claim and the builder API. If you are on v20.x or earlier, check the matching documentation for the older per-operation claim format; do not copy v21 snippets into a v20 project.

What the Workflow Engine NEO Data API and RPC API actually do

Documented behavior. According to the Workflow Engine Web API setup documentation retrieved 2026-05-12, each surface has a one-sentence definition:

"RPC API: Remotely manage Workflow Engine Runtime instances in single-tenant or multi-tenant modes."
"RESTful Data API: Interact safely with the Workflow Engine database without disrupting internal processes."

The Web API Core is provided by OptimaJet.Workflow.Api for .NET 8.0, and Data access is added through a provider-specific package such as OptimaJet.Workflow.Api.Mssql, OptimaJet.Workflow.Api.Postgres, OptimaJet.Workflow.Api.Mysql, OptimaJet.Workflow.Api.Oracle, OptimaJet.Workflow.Api.Sqlite, or OptimaJet.Workflow.Api.Mongo. Workflow Engine NEO is a licensed feature set on top of base Workflow Engine starting from v19.0.0; the RPC API and Web API multitenancy were introduced in v19.0.0 per the 19.0.0 release notes. The two surfaces share the same multi-tenant header, Workflow-Api-Tenant-ID, the same WorkflowApiPermissions claim model, and are exposed through the same Workflow Engine Web API service with a generated OpenAPI specification. What differs is the operations branch each one exposes, and that difference is where the design intent lives.

The Web API requires a Workflow Engine license key with the API/NEO option enabled; without the key, the API does not start. The Data/RPC split is therefore a paid Workflow Engine NEO capability; base Workflow Engine and the free Workflow Engine Community Edition do not include either API, per the Workflow Engine pricing and editions page.

When to use the Workflow Engine NEO Data API

Architectural recommendation. Use the Data API as the default integration boundary for reporting, audit export, BI dashboards, and support tools that should observe workflow state without driving runtime behavior. The Data API is the right place to surface workflow data to consumers whose blast radius you want to keep small.

Documented behavior, important clarification. The Data API is not strictly read-only. The documented Data API surface includes create, update, and delete operations for several entities, among them global parameters, workflow schemes, process parameters, timers, transitions, approvals, and inbox entries. Calling the Data API does not move a process through state transitions the way an RPC command does, but the Data API can mutate the underlying data. Read-only consumers must therefore receive only the specific get and get-collection permissions for the entities they need, not a blanket allow over the Data API surface.

Architectural recommendation, with v21 code. A practical scope for a read-only analyst persona uses the v21 WorkflowApiPermissions builder API to deny everything by default, scope to a single tenant, and then explicitly allow concrete read operations:

var claim = permissions.BuildClaim(builder => builder
    .DenyAllOperations()
    .DenyAllTenantsExcept("TenantA")
    .Allow(
        "workflow-api.data.schemes.get",
        "workflow-api.data.schemes.get-collection",
        "workflow-api.data.processes.get",
        "workflow-api.data.processes.get-collection",
        "workflow-api.data.processes.parameters.get",
        "workflow-api.data.processes.parameters.get-collection",
        "workflow-api.data.processes.transitions.get",
        "workflow-api.data.processes.transitions.get-collection",
        "workflow-api.data.processes.approvals.get",
        "workflow-api.data.processes.approvals.get-collection",
        "workflow-api.data.processes.inbox-entries.get",
        "workflow-api.data.processes.inbox-entries.get-collection"
    ));

This token reads schemes, process records, parameters, transitions, approvals, and inbox entries inside TenantA; it cannot mutate any Data entity or reach other tenants. For cross-tenant analyst access, replace DenyAllTenantsExcept("TenantA") with AllowAllTenants() as an explicit administrative decision.

Note on process history. Process-history operations (get-process-history, get-process-history-count) live under workflow-api.rpc.*, not the Data API. A reporting client that needs them should receive them as scoped read-only RPC exceptions.

When to use the Workflow Engine NEO RPC API

Architectural recommendation. Use the RPC API when the caller is meant to drive the runtime: start instances, execute commands, advance state. Bulk operations live exclusively on the RPC API, so any client that needs to start or progress many processes in one round-trip belongs here.

Documented behavior. The operations branch workflow-api.rpc covers, among others, workflow-api.rpc.bulk-create-instance, workflow-api.rpc.bulk-execute-command, workflow-api.rpc.bulk-get-process-instance, workflow-api.rpc.get-available-commands, workflow-api.rpc.delete-instance, and workflow-api.rpc.get-process-history, per the Workflow Engine documentation. Bulk operations, including both read-like bulk retrieval and runtime-changing operations, live under the RPC API branch.

The RPC API is the right surface for:

Polyglot integration. A Node.js worker, a Python ETL job, or a Java partner service that needs to start and progress Workflow Engine processes does so over plain HTTP using the RPC API. The host application stays on .NET, but the callers do not have to.
Front-end clients that drive workflows directly, such as a React or Angular UI that maps user actions onto workflow-api.rpc.execute-command or workflow-api.rpc.bulk-execute-command.
Backend microservices that orchestrate Workflow Engine state from outside the host process. Risk if ignored. Each RPC operation has a separate permission identifier. A token authorised for workflow-api.rpc.execute-command does not automatically gain access to workflow-api.rpc.delete-instance. In practice, however, teams tend to grant broad RPC allow lists to operational clients, which is where the real blast radius shows up. Keep execute-command, delete-instance, runtime control, and bulk operations in separate permission profiles, and only combine them inside dedicated admin tokens that you audit.

How `WorkflowApiPermissions` enforces the Data/RPC split at the claim level

Documented behavior. The Workflow Engine NEO permission model treats the Data/RPC split as a security primitive. Each operation has a concrete identifier under either workflow-api.data.* or workflow-api.rpc.*, and tokens are issued by passing concrete identifiers to the WorkflowApiPermissions builder. The Workflow Engine documentation states verbatim: "Operations are hierarchical. More specific rule wins on conflict."

Architectural recommendation. Build claims from concrete operation identifiers. The pattern works for both Data API and RPC API personas:

Persona	Builder pattern	What the token can do
BI analyst, Data API only	Deny all operations, allow concrete Data API operations ending with `.get` or `.get-collection`	Read schemes, process records, parameters, transitions, approvals, and inbox entries; cannot create, update, or delete
Workflow operator, RPC without destructive ops	Deny all operations, allow concrete RPC operations except `delete-instance`	Start instances, execute commands, read; cannot delete
Admin excluding one tenant	Allow all operations, then `AllowAllTenantsExcept("TenantX")`	Full admin access except the excluded tenant
Tenant-scoped admin	Allow all operations, then `DenyAllTenantsExcept("TenantA")`	Full admin access inside one tenant only

Recipe table compiled from the v21 WorkflowApiPermissions builder examples in the Workflow Engine documentation, retrieved 2026-05-12.

Risk if ignored. The same compact format describes tenant access. A note on multi-tenancy from the Workflow Engine documentation: "The tenant header selects the tenant context only. It is not an authorization source. When security services are enabled, the current WorkflowApiPermissions claim must also allow the selected tenant. If the tenant permission is missing... the request is rejected with 403 Forbidden." Architects who treat the Workflow-Api-Tenant-ID header as an authorization signal will eventually ship a tenant-cross-bleed bug. The header is routing; the claim is authorization.

A note for v21.0.0 readers: IWorkflowApiPermissions was redesigned in v21.0.0 and the synchronous API was removed across both the Data API and the RPC API, per the Workflow Engine release notes retrieved 2026-05-12. Earlier per-operation claim helpers such as AllowAll, AllowList, DenyAll, DenyList, GetAllPermissions, and ValidatePermissions were removed; use the compact WorkflowApiPermissions claim and the BuildClaim builder API from v21.0.0 onward.

Note: some public security pages still show pre-v21 helpers like AllowList(...). Follow the v21 release notes; treat older snippets as v20.x reference.

A decision table: which Workflow Engine NEO API does my caller need?

Architectural recommendation. The table below is the one I draw on whiteboards in support calls.

Use case	Prefer	Why	Permission style
BI dashboard	Data API	Reads process records, parameters, transitions, approvals, and related Data API entities without runtime commands	Only concrete `get` and `get-collection` permissions
Read-only support panel	Data API	Lower operational blast radius	No create, update, or delete permissions
Audit and evidence export	Data API	Snapshot of state without affecting running work	Read-only Data API allow list
External service starts workflows	RPC API	Requires runtime command execution	Only `create-instance`, `execute-command`, possibly `get-available-commands`
Front-end UI executes commands	RPC API	Maps user actions onto runtime transitions	Per-user token scoped by tenant and command set
Admin runtime control	RPC API	Requires start, stop, delete, status operations	Separate privileged token, audited

Decision canvas compiled by the author from the Workflow Engine NEO operation branches, 2026-05-12.

Risk if ignored. In multi-tenant deployments, avoid relying on an implicit default tenant for external clients. Prefer requiring every caller to send Workflow-Api-Tenant-ID, and ensure the token's WorkflowApiPermissions claim also allows that tenant. Default-deny on the operation tree, allow only the concrete operations the caller's job needs, deny destructive operations explicitly, per the Workflow API core services documentation.

Take this to your team

If you are the architect deciding how to surface Workflow Engine NEO to the rest of your organisation, here is the short version to bring to a design review.

Decision rule. Pick the Data API for any caller whose job description does not include changing runtime state. Pick the RPC API when the caller must drive the runtime, accepting that the token will carry a larger blast radius. Scope every token, on both APIs, from concrete operation identifiers via the v21 builder API; do not rely on conceptual branch names, and do not rely on the absence of UI affordances. The Data API is safer as an integration boundary, but only with a narrow allow list of read permissions. The API itself is not automatically read-only.

Candidate filter. With one trusted caller and no audit, BI, or analyst workload on the horizon, you can put everything behind the RPC API for now. With more than one consumer of workflow state, such as an analyst tool, a mobile app, or a partner service, split early. Retrofitting permission boundaries after the first quarter in production is expensive.

Cost of getting it wrong. A single RPC token with a broad allow list that lands in a BI tool can move workflow state in ways the audit log records but nobody watches. The same is true of a Data API token granted at branch level when the consumer needs only reads. I have seen both patterns in customer support conversations. The fix is organisational, not code: revoke the token, audit downstream callers, and explain to compliance why a read tool had write access for an unknown window.

Anticipated pushbacks.

"REST is simpler than two surfaces." Both APIs are REST/HTTP and share an OpenAPI document; one generator produces one client. The operation tree is what you scope against, so the choice adds a permission boundary, not a protocol.
"We can just gate on roles in the host app." Role checks in the host app hold only until somebody calls Workflow Engine NEO directly with a valid token. WorkflowApiPermissions enforces the boundary at the runtime, regardless of caller.
"We do not have multi-tenancy, so the security model is overkill." The Data/RPC split is independent of multi-tenancy. A single-tenant deployment still benefits from a read-only Data API token for analytics and a separate privileged profile for destructive RPC operations.

A personal note from the author

Thank you for reading. If you have shipped Workflow Engine NEO and you split your Data and RPC clients differently from how I described, or chose not to split at all, I would like to hear about it. The support conversations I draw from are biased toward teams who are already debating the trade-off, and there are deployment patterns I will not see from where I sit.

The Data API and the RPC API are part of the licensed Workflow Engine NEO tier and I have a commercial interest in your choice. Treat the framing above as a starting point, not the end. If you disagree with the decision rule, please leave a comment below or push back on LinkedIn; that feedback will make the next article in this series sharper.

If you would rather walk through your own architecture, book a demo at workflowengine.io. Come with a concrete task and constraints, and we will help you scope a free POC against Workflow Engine NEO so you can validate the Data/RPC split on your real data before committing.

React JSON Schema Form Alternative: FormEngine vs RJSF Bundle Size Comparison

Optimajet Limited — Wed, 11 Feb 2026 19:19:23 +0000

Disclaimer: Hi! We're the team at Optimajet, creators of FormEngine. This is an honest technical comparison of our library with react-jsonschema-form (RJSF). All tests are public, reproducible, and available on GitHub.

TL;DR: We compared two direct competitors in the JSON-based React forms space. RJSF is lighter out of the box (175 KB vs 244 KB). But if you already have Material UI FormEngine becomes 23% lighter (188 KB), while RJSF gets 32% heavier (232 KB). Your choice of UI library determines the winner.

Why RJSF vs FormEngine? 🤔

When we developed FormEngine, we often heard: "How are you different from react-jsonschema-form?"

Fair question. Both libraries:

React-based
Work with JSON:
- RJSF uses JSON Schema to describe forms
- FormEngine uses its own JSON format
Support Material UI
Open to customization

But there's one fundamental architectural difference that radically affects bundle size:

RJSF — adds UI components on top of the base library
FormEngine — completely replaces UI components during integration

Let's see how this works in practice.

Testing Methodology

We tested two realistic forms:

Login Form (Simple Case)

Email + Password fields
Basic validation
Submit button

Booking Form (Complex Case)

Multi-step form
Conditional logic
Different field types (text, dates, selects)
Validation at each step

Test Conditions:

Production build (minified + gzipped)
Vite as bundler
Tree-shaking enabled
Default configurations
Two variants: with default UI (FormEngine Core has no default UI, React Suite v5 was used) and with Material UI

Full methodology: formengine.io/documentation/bundle-size-comparison

Results (gzip sizes)

Login Form - Default UI

🥇 RJSF           175.26 KB  (baseline)
🥈 FormEngine + React Suite (v5)   244.19 KB  (+39% heavier)

RJSF wins in its pure form. Bootstrap CSS is lighter than React Suite.

Login Form - With Material UI

🥇 FormEngine     188.54 KB  (-23% from default!)  
🥈 RJSF           231.62 KB  (+32% from default)

Difference: 43 KB in favor of FormEngine

The picture changes! FormEngine becomes lighter when replacing React Suite with MUI.

Booking Form - Default UI

🥇 RJSF           178.07 KB  (baseline)
🥈 FormEngine + React Suite (v5)    316.69 KB  (+78% heavier)

RJSF is ahead again. But the difference has grown — complex forms require more components.

Booking Form - With Material UI

🥇 FormEngine     199.26 KB  (-37% from default!)  
🥈 RJSF           234.50 KB  (+32% from default)

Difference: 35 KB in favor of FormEngine

FormEngine is lighter again after MUI integration.

Key Insight: How UI Kit Changes Everything

Here's what happens when switching from default UI to Material UI:

Form	FormEngine	RJSF
Login	-55.6 KB (-23%) ⬇️	+56.4 KB (+32%) ⬆️
Booking	-117.4 KB (-37%) ⬇️	+56.4 KB (+32%) ⬆️

Why Does FormEngine Become Lighter?

Comparison of Different UI Library Usage:

FormEngine + React Suite by default:
├── Core engine (~50 KB)
├── React Suite components (~190 KB)
└── React Suite CSS (~52 KB)
= 244 KB total

FormEngine + MUI:
├── Core engine (~50 KB)
├── MUI components (already in project)
└── Minimal CSS (~0.2 KB)
= 188 KB total (-23%)

Why Does RJSF Become Heavier?

Additive Architecture:

RJSF by default:
├── Core engine (~156 KB)
└── Bootstrap CSS (~19 KB)
= 175 KB total

RJSF + MUI:
├── Core engine (~156 KB)
├── MUI adapter layer (~20 KB)
├── MUI components (already in project)
└── Minimal CSS (~0.2 KB)
= 232 KB total (+32%)

MUI is added on top, not replacing the base components.

What Does This Mean for Real Users?

A difference of 35-43 KB might seem small, but let's translate it into seconds:

On Slow 3G (Emerging Markets):

Metric	43 KB Difference	Impact
Load	~1.2 sec	Slower UI appearance
TTI	~1.0 sec	Slower interactivity

On 4G (Typical Conditions):

Metric	43 KB Difference	Impact
Load	~0.13 sec	Almost imperceptible
TTI	~0.15 sec	Barely noticeable

Conclusion: If you have users on slow networks (emerging markets, mobile internet in subways, poor WiFi) — every second is critical.

Conclusions (And What We Learned About Our Own Product)

1. Context Is Everything

You can't say "FormEngine is better than RJSF" or vice versa. The right answer depends on your project:

Choose RJSF if:

Need minimal baseline
JSON Schema is your primary source of truth
Simple forms with basic validation

Choose FormEngine if:

Already using Material UI or another UI kit
Need deep component customization
Complex forms with conditional logic

2. Our Competitive Advantage Is Integration

We initially designed FormEngine for embedding into existing projects with already installed UI libraries. This architectural decision paid off:

Minus 23-37% bundle when integrating with MUI compared to React Suite
Complete UI replacement instead of layering
Zero overhead for components

3. Different Approach to Describing Forms in JSON

This is one of the most important differences that affects not only DX but also bundle size:

RJSF: Separate Schemas (Data Schema + UI Schema)

// data-schema.json - describes data
{
  "type": "object",
  "properties": {
    "email": {
      "type": "string",
      "format": "email"
    },
    "password": {
      "type": "string",
      "minLength": 8
    }
  },
  "required": ["email", "password"]
}

// ui-schema.json - describes UI
{
  "email": {
    "ui:widget": "email",
    "ui:placeholder": "Enter your email"
  },
  "password": {
    "ui:widget": "password",
    "ui:help": "Min 8 characters"
  }
}

Pros of Separation:

✅Standardization — JSON Schema is an open standard
✅ Reusability — one data schema can be used in different UIs
✅ Validation independent of UI — can validate on backend with the same schema
✅ Ecosystem — many tools for JSON Schema (generators, validators, documentation)
✅ Separation of concerns — logic separate from presentation

Cons of Separation:

❌ Synchronization — need to maintain two files in sync
❌ Verbosity — more code for simple forms
❌ Learning curve — need to know both formats

FormEngine: Unified JSON (Data + UI in One JSON)

// form.json - everything in one place
{
  "components": [
    {
      "type": "TextField",
      "key": "email",
      "label": "Email",
      "placeholder": "Enter your email",
      "validation": {
        "required": true,
        "email": true
      }
    },
    {
      "type": "PasswordField",
      "key": "password",
      "label": "Password",
      "help": "Min 8 characters",
      "validation": {
        "required": true,
        "minLength": 8
      }
    }
  ]
}

Pros of Unification:

✅ Simplicity — one file, one source of truth
✅ Less code — no duplication of field names
✅ Conditional logic — easier to describe dependencies between fields
✅ DX — faster to write and understand
✅ Compactness — less boilerplate

Cons of Unification:

❌ No standardization — proprietary FormEngine format
❌ Vendor lock-in — harder to migrate to another library
❌ Validation only on client — can't reuse schema on backend directly
❌ Fewer tools — no JSON Schema ecosystem
❌ UI and data coupling — UI changes can affect logic

Impact on Bundle Size

RJSF (separate schemas):

✅ JSON Schema validator (~15-20 KB)
✅ Standard ajv (might already be in project)
❌ UI Schema parser (~5 KB)
❌ Mapping layer between schemas (~3-5 KB)

Total: ~23-30 KB overhead

FormEngine (unified schema):

✅ Custom validator (~8-12 KB)
✅ Less parsing
❌ No ajv reuse
❌ Proprietary format

Total: ~8-12 KB overhead

Conclusion: FormEngine saves ~10-15 KB on schema parsing, but loses standardization benefits.

Important note: Although FormEngine uses a proprietary format, it is fully open and documented. This means you can study the specification, write your own parsers or form generators, without depending on closed solutions.

Real Example: Complex Conditional Logic

Imagine a form where the "Phone" field is shown only if "Contact by phone" is selected:

RJSF Approach:

// data-schema.json
{
  "type": "object",
  "properties": {
    "contactMethod": {
      "type": "string",
      "enum": ["email", "phone"]
    },
    "phone": {
      "type": "string",
      "pattern": "^[0-9]{10}$"
    }
  },
  "dependencies": {
    "phone": ["contactMethod"]
  },
  "if": {
    "properties": {
      "contactMethod": { "const": "phone" }
    }
  },
  "then": {
    "required": ["phone"]
  }
}

// ui-schema.json
{
  "phone": {
    "ui:widget": "phone",
    "ui:options": {
      "conditional": {
        "show": {
          "field": "contactMethod",
          "is": "phone"
        }
      }
    }
  }
}

Problem: The condition is described in two places! Data schema says "phone required if...", UI schema says "show phone if...". Need to synchronize.

FormEngine Approach:

{
  "components": [
    {
      "type": "RadioGroup",
      "key": "contactMethod",
      "label": "Contact method",
      "options": [
        { "value": "email", "label": "Email" },
        { "value": "phone", "label": "Phone" }
      ]
    },
    {
      "type": "PhoneField",
      "key": "phone",
      "label": "Phone number",
      "conditional": {
        "show": "{{contactMethod === 'phone'}}"
      },
      "validation": {
        "required": "{{contactMethod === 'phone'}}",
        "pattern": "^[0-9]{10}$"
      }
    }
  ]
}

Advantage: Condition described once. UI and validation automatically synchronized.

When Is Each Approach Better?

Choose RJSF (separate schemas) if:

You already have JSON Schema for API validation
Need one schema for frontend and backend
Working in a team where backend generates schemas
Using JSON Schema ecosystem tools
Need compatibility with third-party systems
Simple forms without complex conditional logic

Choose FormEngine (unified schema) if:

Forms are complex with many conditions
UI logic is more important than data validation
Want to avoid duplication
DX and development speed are priorities
Not planning to migrate to another library

4. Transparency Builds Trust

We've published all data, including scenarios where RJSF is faster. This is our principle: honesty is more important than marketing.

If you find errors in the tests — open an issue, we'll fix it.

Detailed Data

Comparison Table (All Scenarios)

Scenario	RJSF (gzip)	FormEngine (gzip)	Winner
Login default UI	175.26 KB	244.19 KB	RJSF (-39%)
Login MUI	231.62 KB	188.54 KB	FormEngine (-19%)
Booking default UI	178.07 KB	316.69 KB	RJSF (-78%)
Booking MUI	234.50 KB	199.26 KB	FormEngine (-15%)

Detailed Bundle Breakdown

RJSF Login (default UI):

Code:     480.72 KB raw / 156.37 KB gzip (80%)
CSS:      117.18 KB raw / 19.27 KB gzip (20%)
Total:    597.91 KB raw / 175.64 KB gzip
Chunks:   2

FormEngine Login (default UI):

Code:     626.23 KB raw / 192.65 KB gzip (59%)
CSS:      438.18 KB raw / 52.42 KB gzip (41%)
Total:    1.04 MB raw / 245.07 KB gzip
Chunks:   2

RJSF Login (MUI):

Code:     725.19 KB raw / 232.47 KB gzip (100%)
CSS:      186 B raw / 169 B gzip (0%)
Total:    725.37 KB raw / 232.64 KB gzip
Chunks:   2

FormEngine Login (MUI):

Code:     622.22 KB raw / 189.27 KB gzip (100%)
CSS:      186 B raw / 169 B gzip (0%)
Total:    622.40 KB raw / 189.44 KB gzip
Chunks:   2

Observation: After switching to MUI, CSS practically disappears for both libraries (186 bytes). The entire difference is in the JS code.

Practical Recommendations

If You DON'T Have a UI Library in Your Project:

Recommendation: RJSF

Reason: 
- Lighter out of the box (175 KB vs 244 KB)
- Faster setup
- No need to choose UI kit

If You HAVE Material UI:

Recommendation: FormEngine

Reason:
- Lighter with MUI (188 KB vs 232 KB)
- No duplication of UI code
- Full integration with your Design System

If You Have Another UI Kit (Ant Design, Chakra, etc):

Recommendation: Depends on adapter availability

RJSF: Has adapters for many UI kits
FormEngine: Currently only MUI and React Suite

Check documentation for both libraries

If Planning to Change UI Kit in the Future:

Recommendation: FormEngine

Reason:
- UI replacement architecture
- Easier to migrate between UI kits
- Less technical debt

Reproducibility

All tests are available and reproducible:

GitHub Repository:
👉 github.com/optimajet/formengine/tree/master/community/examples/bundle-size

Full Report:
👉 formengine.io/documentation/bundle-size-comparison

How to Run Yourself:

git clone https://github.com/optimajet/formengine.git
cd formengine/community/examples/bundle-size
npm install
npm run build
npm run analyze

What You'll Get:

Bundle size report
Chunk visualization
Duplicate packages detection
Tree-shaking analysis

What's Next?

Try It Yourself

RJSF:

📚 Documentation
💻 GitHub

FormEngine:

📚 Documentation
💻 GitHub

Give Feedback

If you:

Found errors in tests
Want to add new scenarios
Disagree with conclusions

Write to us:

Let us know what you think in the comments 👇
GitHub Issues
hello@optimajet.com

Final Verdict

There's no universal winner. And that's good!

RJSF — excellent choice for quick start and JSON Schema purists
FormEngine — optimal for integration into existing projects with UI kits

Choose based on your context, not marketing.

What's your experience with RJSF or FormEngine? Or are you using something else? Share in the comments! 👇

P.S. We're Optimajet, also making Workflow Engine for processes and Workflow Server for business automation.

FormEngine Core is Now Open Source

Optimajet Limited — Tue, 12 Aug 2025 14:22:39 +0000

If you've ever spent hours wrestling with complex forms in React, struggling with validation, localization, or custom components, FormEngine is here to transform your workflow. This powerful tool combines an intuitive visual designer with a flexible, code-first library, enabling you to create any form, from simple to dynamic, data-driven ones, with ease. Born from our team's real-world challenges, FormEngine empowers solo developers and enterprise teams alike to save time and scale projects effortlessly. Curious about how it became a game-changer for developers? Read on to dive into the full story!

Your Ultimate Solution for Building Forms in React.

Here’s a little story about how it all became possible. We began developing FormEngine in early 2023 to address our own internal needs, driven by the immaturity of the React form library ecosystem both in terms of backend-driven form generation and visual form designers. Our goal was to replace our outdated FormBuilder.dev, with a more modern and developer-friendly form builder built for React.

After a thorough investigation, we hoped to find an open-source library we could build on something robust enough to support our team and integrate seamlessly into our commercial products: Optimajet Workflow Server and form-related plugins for WorkflowEngine.

We evaluated the most popular MIT-licensed libraries and have great respect for React Hook Form, Formik, React Final Form, and SurveyJS, each of which has made a significant contribution to the React ecosystem.
When tested against the strict internal requirements of the Optimajet development team, none could fully deliver the flexibility, integration depth, and scalability needed for our enterprise-grade use cases.

One of the key requirements especially for large teams in big tech companies or custom software development firms is the ability to easily and quickly integrate custom components. We recognized that this was a common pain point across the industry, and we had the expertise to solve it.

That insight led us to a bold decision: to build the best React-based FormBuilder from scratch-first and foremost, for ourselves. We surveyed our enterprise customers and small teams building business applications for workflow automation. Based on their feedback and requirements, we formed the foundation for what we believe to be an ideal form library one that supports code-first form creation in React, and serves as the engine behind a low or no-code visual form designer.

Here is the list of requirements and brief explanations that guided the Optimajet team when we started developing FormEngine Core.

Lower learning curve: Easily create forms using typed FormEngine Core functions, without writing components or learning complex React concepts. JSON representation of the form is also supported for configuration-driven use.
Built-in form validation: Data validation works out of the box with no extra code. Required fields, error messages, and rules are defined directly in code or JSON. Easily integrates with third-party validation libraries.
Built-in localization: Forms are ready for multi-language support out of the box. Third-party localization libraries can be integrated if needed.
Dynamic CSS and responsive layout support: Forms automatically adapt to different devices and styles no additional layout code needed.
Built-in actions: Forms support actions like submit, reset, and external calls out of the box. Define only what you need in code or JSON and it’ll just work.
Reusable forms across apps: Cross-project compatibility just copy and use forms are easily portable between applications with minimal effort. A single JSON object contains the full structure, logic, styles, validation, and actions.
Programmatic form creation and dynamic generation: Build or modify forms in real time using code or external data sources.
Ready-to-use component library: Includes built-in components and supports easy integration of custom ones. Get started fast without sacrificing flexibility.
Easy custom component integration: Quickly define your own component by specifying its name, type, and props.
Ready to use with popular frameworks: Works seamlessly with Next.js, Remix, and other modern React stacks no special setup needed.
High performance and lightweight: Fast load times, smooth rendering, and minimal impact on app performance.

On October 31, 2023, we released FormEngine 0.0.13 our new standalone commercial product. Release notes →

This marked the beginning of a journey to bring to life everything our development team had envisioned for the platform. And right from day one, the results confirmed we were on the right track.

We delivered a complete, time-saving tool for development teams something that works just as well for solo developers as it does for large projects. Whether you're building a few simple forms or managing hundreds or thousands of dynamically generated ones from a backend FormEngine just works.

The initial sales were strong, and as demand grew, we even experimented with pricing tiers and product options to better understand what triggered the “Aha!” moment for our users.

That moment where everything clicks and the value is obvious.

We’re still searching for a definitive answer to what exactly made the product such a commercial success, especially among enterprise teams. But one thing is clear: we hit a real need, and we’re excited to keep building on it.

Thanks to the commercial licenses issued to our partners custom software companies we’ve been improving the FormEngine libraries day by day, with one clear goal:

To create the best React-based form solution on the market for developers and businesses who want powerful forms without the usual complexity.

We give developers everything they need to build real, working forms without the usual mess of extra tools, boilerplate, and setup.

@react-form-builder/core Community MIT Open Source Form Library for React

@react-form-builder/components-rsuite Form Components Library

@react-form-builder/designer Premium Drag-and-Drop Form Builder, also known as the Visual Form Designer

Why FormEngine Core is Now Open Source?

Many of our partners, who use FormEngine as part of their business process automation and approval workflow applications, asked us to open up the core Formengine so they could deeply integrate it into their systems and even extend its functionality where needed.

And now, after nearly two years of development and five major releases, the time has come.

On 26 June 2025, we are proud of the quality, stability, and architecture of our code, and we are ready to share it. By open-sourcing the FormEngine Core library, we make this technology freely available to the global developer community, fostering innovation, transparency, and long-term adoption.

Your support means the world to us, and we’d love for you to be part of this exciting new chapter for FormEngine.

If you find value in what we’re building, consider giving us a ⭐️ on GitHub it helps more amazing developers like you discover FormEngine Core.

Open source thrives on collaboration, and we warmly welcome contributors who want to join us on this journey. Whether it’s contributing code, sharing ideas, or spreading the word, your involvement will help FormEngine, and our growing community thrive.

With gratitude and excitement, The Optimajet Developers Team

A True React Hook Form Alternative – FormEngine Core 4.0 Is Now MIT Licensed and Free! 🚀

Optimajet Limited — Tue, 27 May 2025 18:06:46 +0000

React developers, here's big news! On May 15, 2025, Optimajet released FormEngine Core 4.0, making essential libraries available under the permissive MIT license free even for commercial use. FormEngine is now the leading alternative to React Hook Form, especially for teams building complex, interactive forms.

Why switch from React Hook Form to FormEngine?

⚡️ Rapid and Simple Setup

React Hook Form requires extensive manual setup of controllers, hooks, and validation logic. FormEngine simplifies this by leveraging intuitive, schema-based definitions.

🎨 Powerful Drag-and-Drop FormEngine Visual Designer

Unlike React Hook Form’s code-only approach, FormEngine includes an intuitive visual editor, allowing instant form creation and modification, significantly speeding up development. (Note: FormEngine Visual Designer is a paid component for commercial use; however, its full functionality is available for unlimited testing.)

🔌 Easy Custom Components Integration

React Hook Form’s custom component integration can be cumbersome. FormEngine makes this seamless, simplifying component binding and custom logic implementation.

📱 Real-Time Form Previews

Get instant visual feedback as you build forms. React Hook Form needs extra setup or third-party tools for similar functionality.

Built-In Component Library

Unlike React Hook Form, FormEngine comes with a built-in library of ready-to-use components (@react-form-builder/components-rsuite), further accelerating development and reducing the need to create components from scratch.

Completely Free and MIT Licensed

FormEngine’s core libraries are now MIT-licensed and fully free, even for commercial use:

📦 @react-form-builder/core
📦 @react-form-builder/components-rsuite
📦 @react-form-builder/viewer-bundle

💡 Highlights of FormEngine Core 4.0:

UI-Agnostic: Integrate effortlessly with UI libraries like MUI, Ant Design, shadcn/ui, and more.
Framework-Friendly: Built-in support for Next.js, Remix, and framework-agnostic CDN deployment.
Multi-Database Compatibility: Seamlessly use MySQL, PostgreSQL, MongoDB, SQLite, and more.
Robust Validation: Powered by Zod, with extensible support for Yup, AJV, Superstruct, and Joi.
Dynamic & Responsive: Create reactive, adaptive layouts with MobX-powered dynamic properties.
Flexible Storage: Store forms as JSON or generate them programmatically.

🎬 Watch the video to see FormEngine in action—start building your forms faster, smarter, and with greater ease than ever before!

In this step-by-step tutorial, I'll walk you through building a simple React demo app using FormEngine. You'll see how quickly you can design, render, and manage forms — without writing endless custom code.

Install

npm install @react-form-builder/core

Quickstart

import {viewWithCss} from '@react-form-builder/components-rsuite'
import {buildForm, FormViewer} from '@react-form-builder/core'

const simpleForm = buildForm({errorType: 'RsErrorMessage'})
  .component('container', 'RsContainer')
  .style({flexDirection: 'row'})
  .children((builder) =>
    builder
      .component('firstName', 'RsInput')
      .prop('placeholder', 'Enter your first name')
      .prop('label', 'First Name')
      .validation('required')

      .component('lastName', 'RsInput')
      .prop('placeholder', 'Enter your last name')
      .prop('label', 'Last Name')
      .validation('required')
  )

  .component('birthDate', 'RsDatePicker')
  .prop('label', 'Birth Date')
  .prop('oneTap', true)
  .validation('min').args({value: '1900-01-07T12:25:37.000Z'})

  .component('submit', 'RsButton')
  .prop('children', 'Submit')
  .prop('color', 'blue')
  .prop('appearance', 'primary')
  .event('onClick')
  .commonAction('validate').args({failOnError: true})
  .customAction('onSubmit')
  .json()

export const App = () => {
  return <FormViewer
    view={viewWithCss}
    getForm={() => simpleForm}
    actions={{
      onSubmit: (e) => {
        // submit the form to the backend
        alert('Form data: ' + JSON.stringify(e.data))
      },
    }}
  />
}

What you'll learn:

How to install and set up the FormEngine Core Library
Creating and editing forms using JSON
Running your app and previewing form behavior
Using the FormEngine Visual Designer to create forms

🌍 Help us grow the ecosystem, if you like the project:

⭐ Star us on GitHub

💬 Share feedback! Have feature requests or thoughts on the docs? Share them in the comments below!

🔗 Mention @optimajet Formengine X / Twitter

🚀 This is just the beginning — part two is on the way!

We'll provide a detailed comparison between React Hook Form and FormEngine Core.

📘 Docs, Live Demo & Examples: formengine.io/documentation

We’d love to address your specific questions, so please leave your questions in the comments, and we'll include the answers in our upcoming comparison!

Key differences between BPMN diagrams and Optimajet .NET Workflow Engine process schemes

Optimajet Limited — Mon, 04 Nov 2024 16:06:28 +0000

Element specialization

In BPMN, there are a lot of elements that often have narrow specializations and are categorized into Tasks, Gateways, and Events, although other distinct elements exist as well. The Sequence flow is particularly significant and stands out.
In Workflow Engine, there are only two types of elements in the scheme — Activities and Transitions. By combining the configurations of these two elements, you can create Workflow Engine schemes that function similarly to the corresponding BPMN elements.

Activity is not a Task

At first glance, an Activity appears as a rectangle, similar to a Task, and it may seem like these elements are alike. However, they're actually quite different. An Activity can represent a Service Task, a Gateway, or even an Event. The main function of an Activity is to execute your code, but the overall behavior of the scheme (i.e., the direction and manner in which the process flows next) depends on the settings of the outgoing Transitions from the Activity.

For example, if an Activity has Transitions triggered by Commands, it acts similarly to an Event-based Gateway; however, unlike a Gateway, the Activity can execute some code. If the Transitions from an Activity are configured to start parallel processes, then that Activity will behave like a Parallel Gateway. And so on.

Transition is not a Sequence Flow

At first glance, Transition and Sequence Flow may seem like similar elements, as both represent arrows between elements on a diagram. However, they're actually quite different.

In Workflow Engine, a Transition defines how and where the process execution will transition. For example, a process can move to the next state based on a Timer or a Command. What is set by events in BPMN is managed through transitions in Workflow Engine. Additionally, Transitions can be conditional, and access to them can be restricted to specific users or roles. Transitions also determine parallelism, which in BPMN is either set through Gateways or implicitly defined.

In BPMN, however, a Sequence Flow only defines the direction of the transition. This element has almost no settings, except for flows coming out of exclusive gateways.

Parallelism difference

Parallelism in BPMN and Workflow Engine operates on different, yet non-contradictory principles.

In BPMN, parallel execution is defined either explicitly, using a Parallel Gateway, or implicitly, for example, when multiple Sequence Flows emerge from a single Service Task or Event. In this case, it is considered that the process remains singular, but several tokens are introduced. This can lead to a situation where, if you don't introduce a merging element or remove these tokens, multiple tokens will continue during sequential process execution.
In Workflow Engine, you can assume that there is always only one token within a single process, and parallelism is achieved by creating dependent processes (called subprocesses in Workflow Engine). These subprocesses depend on the process that spawned them, and you can retrieve a list of Activities where the parent process and all its child subprocesses are located, as well as manage the parent process and its subprocesses collectively. The creation and merging of processes are handled by transition settings. However, if this approach is unfamiliar, you can use the Parallel Gateway, which replicates the behavior of its BPMN counterpart.

Subprocesses in BPMN and Workflow Engine are completely different

In BPMN, a Subprocess is merely a nested part of the main diagram that can be collapsed. It can't be reused and is primarily for aesthetic purposes. Workflow Engine has a similar feature called Inline Activity. This is a special activity that embeds another scheme into the current one. The embedded scheme can be used in multiple other schemes, allowing for reusability.
In Workflow Engine, a subprocess is a dependent process, as mentioned earlier.

Workflow Engine provides real access control to Commands

In Workflow Engine, Actors are part of the process, and you can set restrictions on command execution (similar to a Message Catch Event) by specific users directly within the scheme. BPMN doesn't offer such functionality explicitly.

Execution ready approach

A valid Workflow Engine scheme is always ready for execution and can be run on the Workflow Engine. In contrast, a valid BPMN diagram might just be an illustration, and no engine will necessarily be able to execute it.

Ability to set the Process to any state

In Workflow Engine, a running process can always be forcibly set to any of its states. BPMN doesn't offer such a capability.

Armed with this knowledge, let's move on to exploring which BPMN elements are supported in Workflow Engine and how they’re implemented.

Configuring and using BPMN plugin

You can read about how to install, configure, and start using the BPMN Diagram Import Plugin in the .NET Workflow Engine in the official documentation.

Introducing BPMN support in .NET Workflow Engine library

Optimajet Limited — Mon, 04 Nov 2024 15:55:44 +0000

Many .NET developers, during the POC process, requested that we add the ability to import BPMN schemas into our WorkflowEngine. In an new update, Optimajet's Workflow Engine now introduces foundational BPMN support, making it easier for .net developers to work with familiar process elements and streamline workflow designs. While Workflow Engine is not a dedicated BPMN engine, this new capability bridges some gaps by enabling users to work with BPMN elements, enhancing compatibility and efficiency for process modeling.

Workflow Engine is not a BPMN engine, so full compliance with the BPMN standard isn't achievable. However, the process execution principles in Workflow Engine align with those of BPMN. Consequently, BPMN support in Workflow Engine is grounded in two key aspects:

BPMN Elements in Workflow Engine Scheme: We have added basic BPMN elements to Workflow Engine so that when a BPMN diagram is imported, familiar elements remain, making it clear where attention should be focused. Some of these elements are useful on their own, such as the Parallel Gateway, which can be beneficial for creating and merging subprocesses in Workflow Engine in a simpler and more understandable way.

BPMN Import: You can import a BPMN diagram, and it will be converted into a Workflow Engine scheme. A detailed log and comments will indicate what is unsupported or only partially supported in the current implementation.
The structure of this section will be as follows. First, we will describe the differences between BPMN diagrams and Workflow Engine process schemes. Then, we will review which BPMN diagram elements are supported in Workflow Engine and how they are implemented. Finally, we will explain how to integrate BPMN import into an application running Workflow Engine and how to customize this import process.

BPMN elements support in Workflow Engine

The BPMN plugin for Workflow Engine currently supports only the most essential BPMN elements, with new functionalities being progressively added. Here’s an overview of the supported and partially supported elements:

Tasks

Generic Task - Converted into a standard Activity.
Service Task - Transformed into a specialized Activity based on the values of attributes like camunda:topic and camunda:delegateExpression.
Receive Task - Supported, with an outgoing transition triggered by a Command.
User Task. Not supported yet; support will be added after the release of the plugin integrating Workflow Engine with forms.
Business Rule Task. Not supported; will be converted into a standard Activity.
Manual Task. Not supported; will be converted into a standard Activity.
Script Task. Not supported; will be converted into a standard Activity.
Send Task. Not supported; will be converted into a standard Activity.

Gateways

Exclusive Gateway and Parallel Gateway - Supported.
Event-Based Gateway - Supported and converted into an Activity with transitions triggered by corresponding events.
Inclusive and Complex Gateways - Not supported and are currently converted into standard Activities.

Events

Start Events - Generic Start Event is supported, with partial support for Message and Timer types.
End Events - Generic and Terminate End Events are supported.
Boundary Events - Partially supported; Message and Timer Boundary Events are converted into transitions with Command and Timer triggers.

Other Elements

Subprocesses and Pools - Converted to Inline Activities or separate workflow schemes.
Call Activities and Lanes - Not supported; Lanes are ignored due to no equivalent grouping method in Workflow Engine.
Parallelism
In BPMN diagrams, implicit parallelism is converted to explicit parallelism in Workflow Engine, using dashed lines to mark the start of subprocesses and dash-dotted lines for their completion.

Feedback
Since BPMN support is an evolving feature, your feedback on the BPMN elements you need is invaluable to us. Please let us know in the comments below which elements are critical to your workflows, so we can prioritize their implementation in future releases. We will gradually add new BPMN elements based on requests from .NET developers who have chosen Workflow Engine as the workflow library for their business applications.

Maximizing Hardware Utilization with Parallelism in Workflow Subprocesses Using Optimajet Workflow Engine

Optimajet Limited — Wed, 11 Sep 2024 10:31:13 +0000

Introduction

In today's fast-paced digital landscape, businesses demand agility, scalability, and high performance from their software solutions. Workflow engines play a pivotal role in orchestrating tasks and automating processes, ensuring that everything runs smoothly. But when these processes become more complex and resource-intensive, how can workflow engines scale efficiently and stay responsive? The answer lies in threads. Examples of schemas using subprocesses in different workflows are described in detail in the official documentation of the Workflow Engine.

However, in this article, we will try to explain complex things in simple terms. We'll explore what threads are in the context of the Optimajet Workflow Engine and how they can dramatically enhance efficiency, enabling smoother execution and more responsive workflows.

What is Parallelism in Workflow Subprocesses?

In modern software systems, the need to optimize for both performance and resource efficiency has become a critical challenge. One of the most powerful techniques for achieving this is leveraging parallelism within subprocesses when building workflow schemas. By running multiple subprocesses concurrently, you can unlock higher performance and make full use of your hardware’s processing power. Optimizing workflows in this way can dramatically improve system efficiency, especially when dealing with complex workflows that involve multiple independent tasks. Parallelism refers to the ability to execute multiple independent or semi-independent subprocesses simultaneously.

In the context of workflow automation with Optimajet Workflow Engine, this means that different stages of a workflow can be run in parallel as Subprocesses, rather than waiting for each one to finish before starting the next. This improves efficiency, reduces execution time, and allows your workflows to handle more tasks concurrently.

What Are Threads in a Workflow Engine?

In simple terms, threads are independent sequences of execution within a larger process. In a multi-threaded environment, multiple tasks or operations can run simultaneously, each in its own thread. This allows for parallel processing, where multiple parts of a workflow can be executed at the same time rather than sequentially.

Within the Optimajet Workflow Engine, threads enable you to break down a workflow into parallel paths of execution. These paths can run independently or concurrently, meaning that tasks that don’t depend on each other can proceed without waiting for others to complete. This parallelism can significantly boost performance and efficiency, especially in complex workflows where multiple independent tasks need to be handled simultaneously.

Threads and Their Role in Parallelism

At the core of parallelism is the concept of threads. A thread is a lightweight unit of execution that can run code independently of other threads. In modern multi-core processors, threads allow you to take full advantage of the hardware by distributing work across different cores.

In the Optimajet Workflow Engine, subprocesses within a workflow can be split into multiple threads. However, unlike some systems that automatically handle thread allocation, Optimajet requires developers to configure thread distribution manually when designing the workflow schema. This gives developers full control over how tasks are distributed across threads, ensuring that workflows are tailored to specific use cases and hardware environments.

By using threads, developers gain several important benefits for efficiency, performance, and flexibility, which make thread-based parallelism an essential tool for optimizing workflows.

Benefits of Using Threads in Workflow Schemes

1. Parallelism and Efficiency

Benefit: Threads allow for the parallel execution of tasks that can be performed simultaneously, meaning that workflows can handle multiple operations at once.
Why Use It: If you have tasks that don’t depend on each other—like sending notifications while processing data—threads can significantly speed up the workflow by reducing idle or waiting time.

2. Better Resource Utilization

Benefit: Threads make better use of system resources, particularly in multi-core processors. Instead of running tasks sequentially on a single CPU core, threads can distribute tasks across multiple cores for more efficient processing.
Why Use It: For workflows handling large datasets, high-volume tasks, or I/O operations (like API calls or database queries), threads maximize throughput by fully utilizing your system’s computing power.

3. Concurrency and Responsiveness

Benefit: Threads allow workflows to continue processing while waiting for external events (e.g., user input, network responses). This keeps the workflow responsive instead of stalling.
Why Use It: In complex workflows involving long-running tasks, threads prevent bottlenecks by keeping the rest of the workflow active.

4. Asynchronous Processing

Benefit: Threads enable asynchronous execution, meaning tasks can be initiated and the workflow can move forward without waiting for them to complete, revisiting them once results are ready.
Why Use It: This is particularly useful when interacting with external services or databases. Instead of halting the workflow, other operations can proceed, making the entire process more efficient.

5. Scalability

Benefit: Threads help workflow engines scale by handling large numbers of simultaneous operations. This ensures that as workflows grow in complexity, they can split the workload across multiple threads and execute them concurrently.
Why Use It: For businesses with growing demands, thread-based parallelism ensures that workflows can handle larger volumes of tasks or users without degrading performance.

6. Load Balancing

Benefit: In distributed systems, threads can help balance the load by distributing tasks across multiple systems or servers, preventing any one system from being overloaded.
Why Use It: When scaling workflows to handle multiple users or requests, thread-based processing distributes tasks evenly, avoiding overloads in certain parts of the system.

7. Improved User Experience

Benefit: By performing background operations on separate threads, workflows can maintain a smoother, more responsive interface for users.
Why Use It: For workflows that involve user interaction (e.g., form submissions, approvals), threads allow background processing to occur without affecting the front-end experience.

8. Concurrency Control

Benefit: Workflow engines utilizing threads provide mechanisms to manage concurrent processes, ensuring that shared resources aren’t corrupted due to conflicting operations.
Why Use It: When multiple threads need to access or modify shared data, thread-based concurrency control ensures safe access, avoiding race conditions and data corruption.

How Optimajet Workflow Engine Manages Threads

Unlike some workflow engines that automatically distribute tasks across threads, the Optimajet Workflow Engine requires developers to manually configure thread assignment within the workflow schema for subprocesses.
Here’s how it works:

Manual Thread Assignment

In the Optimajet designer, developers define which subprocesses should run in parallel and manually specify how they will be distributed across threads. This allows for more control over the threading model, making it possible to tailor workflows based on specific system requirements and workloads.

Task Scheduling by Design

The manual assignment of threads ensures that developers have full control over the scheduling of parallel subprocesses. While this requires some upfront design, it allows for more optimized performance as each task can be carefully scheduled based on the system’s capabilities.

Practical Example

Imagine a workflow designed to process a customer order. This workflow may include subprocesses like validating the payment, checking inventory, generating shipping labels, and sending notifications to the customer. In a sequential workflow, each subprocess would run one after the other, increasing the time it takes to complete the order.

By using Optimajet’s parallelism and manually assigning threads:

Payment validation runs on one thread.
Simultaneously, inventory checking runs on another thread.
While these are happening, shipping label generation and notification sending can run on other threads.

The result is a much faster order processing time, as independent tasks are executed in parallel, fully utilizing the CPU cores. In this scenario, the system is able to handle more orders per minute, improving throughput and customer satisfaction.

Conclusion

Parallelism in workflow subprocesses, combined with manual thread assignment in Optimajet Workflow Engine, unlocks the full potential of your hardware. By distributing tasks across multiple threads, you can maximize CPU utilization, reduce latency, and increase throughput. Optimajet’s support for manual threading ensures that developers have the flexibility to optimize workflows for specific use cases and hardware environments.

If your workflows are still running sequentially, it’s time to explore the power of parallelism. With Optimajet, you can build faster, more efficient workflows that scale effortlessly with your system’s needs.