DEV Community: Optimajet Limited

What is workflow orchestration, and where should a .NET app run it?

Optimajet Limited — Thu, 29 Oct 2026 10:24:35 +0000

Workflow orchestration means that one component owns the sequence of steps, the state and the failures of a multi-step process. That component is the orchestrator. For a business process inside one .NET product, run the orchestrator as a library in your app. Keep its state in your own database. Data teams use the same term for a second job. For them, the term means running data pipelines on tools such as Apache Airflow.

Mike Lukinov, co-founder of Optimajet, wrote What Is Workflow Orchestration. The post gives a rule for where to run the orchestrator. If the process belongs to one product and its data should stay in that product's database, put the orchestrator inside the product. The post also says when a separate server or a cloud service is the better place.

Workflow Engine by Optimajet is a .NET workflow engine that runs as a library inside your app. The post compares Workflow Engine with Temporal, Camunda 8, AWS Step Functions and the data pipeline tools. It also lists the vendor pages used for these comparisons, with the date each page was read.

Workflow Engine Free needs no license key. Its license covers personal use and internal commercial use, with attribution. It runs up to 10 workflow definitions (schemes) and 4 execution threads. A public web app or a SaaS product needs the Subscription, SaaS or Enterprise Edition of Workflow Engine NEO. Workflow Engine NEO is a separate product based on Workflow Engine. It adds an HTTP API and multitenancy. The facts about Workflow Engine were checked against version 23.0.0 and its documentation on 27 October 2026.

What an orchestrator does

For a business process inside an application, the orchestrator is software called a workflow engine. Workflow Engine by Optimajet is one product of that kind. Take a purchase request. Someone submits it, and a manager approves it within a week. Then the system places the order through a supplier's API. Each request is a case. A case is one business item that moves through the process. Without an orchestrator, each service calls the next one. The state of the request is spread across several tables. A scheduled job searches for requests that got stuck. With an orchestrator, each request has one record. There is one place to ask where the request is.

An orchestrator has five duties:

Sequence. It decides which step runs next, and which steps can run in parallel. In Workflow Engine, the sequence lives in the process definition, which is called a scheme. A scheme is an XML file.
State. It saves the current step and the data of each case between steps. In Workflow Engine, the state is a row in the application's own database, so the case survives a restart.
Waiting. It pauses a case until a person acts, a timer fires or another system answers. In Workflow Engine, a waiting case holds no execution thread.
Failure handling. It retries a step, times it out, moves the case to another path, or hands the case to a person. In Workflow Engine, the exception handlers of a step can retry a failed call and then move the case to manual review.
History. It records each move, the time of the move, and who or what caused it. In Workflow Engine, GetProcessHistoryAsync returns that history.

Two jobs share the name

Data pipeline orchestration moves datasets on a schedule. Application workflow orchestration runs business cases that wait for people. It is the job of a workflow engine, such as Workflow Engine. The two jobs need different tools.

	Data pipeline orchestration	Application workflow orchestration
What moves	Datasets, from source to warehouse	One business case, such as an order, a request or a loan
Typical shape	A graph of tasks with no loops (a DAG). It runs on a schedule, and each run takes minutes to hours.	A process instance that can wait days for a person
Who acts	Mostly machines	Machines and people
When a step fails	Rerun the task, or backfill (start the runs that were missed)	Retry, time out, take another path, or route the case to a person. The case is kept.
Typical tools	Apache Airflow, Dagster, Prefect	Workflow engines such as Temporal, Camunda, AWS Step Functions and Workflow Engine by Optimajet

For a nightly ETL chain (extract, transform, load), pick a data tool. Apache Airflow, Dagster and Prefect define pipelines in Python and are built for that job. Kubernetes uses the word orchestration for a third thing. Container orchestration keeps containers running in the state you declare. It knows nothing about approvals.

What an embedded engine does with waits, deadlines and failures

An embedded engine is a workflow engine that runs as a library inside your application. In Workflow Engine, the engine's object inside the application is WorkflowRuntime. It runs on the application's own database. The purchase request goes from the Draft step to the Review step, where a manager approves or rejects it. Then it goes to the Ordering step, which calls the supplier's API, and then to Ordered.

A restart. If you stop the app while the request waits for approval, the request is still in Review when the app starts again. A waiting request has the status Idled. It holds no execution thread. All it holds is its row in the database. The restarted application is a new operating-system process. It loads the request with the same step, the same deadline and the same two commands, Approve and Reject. A command is what a person executes to move a request to another step.

A deadline. A timer on the Review step can take its value from a process parameter. A process parameter is a value stored with the request. So each request carries its own review window. When the timer fires, a transition moves the request from Review to Escalated. By default, the engine checks timers about once a second. It does this only while WorkflowRuntime is started. If a timer's deadline passes while the app is down, the timer fires after the app starts again.

A failure. A step runs code called an action. The step also declares what happens when its action fails. When the manager executes Approve, the request moves into Ordering. So the supplier call runs inside the Approve command. If that call throws an HttpRequestException, the exception handlers of the Ordering step can retry it twice. After that, they move the request to a step for manual review. Without handlers, the Approve command fails with a ProcessExecutionException. The request stays in Review with the status Error. Nothing is lost, but someone has to go and find the request.

An embedded engine still leaves four things for you to handle:

A crash in the middle of a step. By default, the engine does not rerun an interrupted step. The process gets the status Error or Terminated. Your recovery policy decides what happens next.
Side effects. A real order needs an idempotency key. This key is a value that makes a repeated call harmless.
The next step for a person. Escalation and manual-review steps need commands for the manager. Without them, a case stops there.
More than one server. To run several servers on one database, you need either Workflow Engine Complete or Workflow Engine NEO. Workflow Engine Complete is a paid Edition of Workflow Engine.

When you need an orchestrator, and when you do not

An orchestrator is one more component to learn and to keep up to date. For small jobs, it costs more than it saves. One job on a schedule needs only a cron job or a hosted service. One unit of work with a retry policy needs only a queue and a background worker. Two services that work together with no waits and no people need only a direct call with a retry policy.

Mike Lukinov's rule of thumb is that you need an orchestrator when one of these is true:

A step waits for a person, or a process takes days.
One process touches three or more systems.
Someone keeps asking where a case is stuck, and nobody can answer quickly.
The process changes more often than you want to release code.

Where the orchestrator runs

For an application workflow, the orchestrator runs in one of three places. The first is a separate server, such as Temporal. The second is a cloud provider's service, such as AWS Step Functions. The third is a library in your app, such as Workflow Engine by Optimajet. The place you choose decides where the process state lives and what you operate. It also decides what it costs to move away later.

	A separate server	A cloud provider's service	A library in your app
Examples	Temporal, Camunda 8, Orkes Conductor	AWS Step Functions, Azure Durable Functions, Azure Logic Apps	Workflow Engine by Optimajet, Elsa Workflows, Workflow Core
Where state lives	In the server's own storage	In the provider's store. With Durable Functions, in a backend you choose.	In your application's database
What you operate	A cluster, its storage and its upgrades, unless you buy the vendor's cloud plan	Nothing extra, within the provider's limits	Your application and its database. The database also holds the engine's tables. They get migrations on major upgrades. Workflow Engine Free runs on one server.
How your code talks to it	Through an SDK. Your workers poll the server for tasks.	Through the provider's SDK or API	Through method calls in the same process
Cost model	Temporal (MIT) and Conductor OSS (Apache 2.0) are free to self-host. Camunda 8 Self-Managed needs a license in production. Each vendor also sells a cloud plan.	You pay for what you use. Step Functions Standard charges per state transition. Logic Apps Consumption charges per action.	Elsa Workflows and Workflow Core use the MIT license. Workflow Engine Free covers personal and internal commercial use, with attribution. A public web app or a SaaS product needs an Edition of Workflow Engine NEO. There is no fee per execution.
Moving away	You rewrite the definitions. Temporal workflows are code written against its SDK. Camunda 8 models are BPMN (a standard process notation) with Camunda's extensions. Conductor definitions use Conductor's own JSON format.	You rewrite the definitions. Step Functions uses the Amazon States Language. Durable Functions workflows are code written against its SDK.	You rewrite the schemes, which are in the engine's own XML format. The process data is already in your database.
Fits best	Many services in several languages, or one process that starts thousands of parallel tasks	An application that already lives on one cloud	One product that keeps its own processes and data

In Mike Lukinov's view, a separate server is worth its operating cost when services in several languages share the same processes, or when one process starts thousands of parallel tasks. That is where Temporal is strong. A cloud service is the fastest way to start when the application already lives on that cloud. Its cost grows with every execution. For one product whose data stays in its own database, the library is the simplest place. The reason is that you add the library to an application you already run.

The post takes its facts about these products from the following pages:

Temporal: the .NET SDK (Temporalio 1.20.0), workers and license, read on 14 and 27 October 2026.
Camunda: the licenses, read on 14 October.
Orkes Conductor: the C# SDK (conductor-csharp 3.0.0), read on 14 October.
Azure Durable Functions: the storage providers, read on 11 October.
AWS Step Functions and Azure Logic Apps: the Step Functions pricing and Logic Apps pricing pages, read on 27 October.
Elsa Workflows 3.9.0, read on 11 October, and Workflow Core 3.21.0, read on 1 October.

The full post also compares orchestration with automation, job scheduling and choreography. It sorts the tools into seven categories, from data pipeline orchestrators to robotic process automation. The categories are in the tools section of What Is Workflow Orchestration.

Should approval thresholds live in your .NET workflow or in a rule engine?

Optimajet Limited — Wed, 28 Oct 2026 06:28:37 +0000

Keep approval thresholds in your .NET workflow while developers own them, the thresholds change about once a year, there are two or three of them, and one service uses them. Move them to a rule engine when a business owner wants to edit them without a developer. Do the same when the thresholds change quarterly or more often, when the list grows into a table, or when several services need the same decision. After the move, a workflow action calls the rule engine and stores the decision with its rule version.

Mike Lukinov, co-founder of Optimajet, sets out that rule in Rule Engine vs Workflow Engine. Mike writes from the workflow side. Workflow Engine by Optimajet is a .NET workflow engine with no rule engine of its own. The post compares Workflow Engine with the rule engines it would call: NRules, Microsoft RulesEngine and DMN (Decision Model and Notation) engines. Workflow Engine Free runs the workflow side of this pattern. It needs no license key. Its license covers personal use and internal commercial use, with attribution.

The product facts were checked on Workflow Engine 23.0.0 on 27 October 2026. The facts about NRules, Microsoft RulesEngine and DMN were checked on their own pages the same day. The thresholds in the examples are illustrative.

What a rule engine does and what a workflow engine does

A rule engine evaluates facts against explicit rules and returns a decision, usually without keeping state between calls. A workflow engine stores every running process and moves it from step to step. Take a purchase request for 60,000 from a preferred supplier. The rule engine answers that the request needs CFO approval. Workflow Engine then holds the request in its database, perhaps for days, until the CFO acts. The same supplier's request for 12,000 gets Auto-approve and finishes in the same call. When a request only needs an answer, such as a live checkout price, the rule engine alone is enough.

One name can mislead .NET readers. In Workflow Engine, a Rule is a permission check that decides which user may execute a command. It is not a business rule.

Three places a threshold can live

In Workflow Engine, a scheme describes a process. It defines the activities (steps), the transitions between them and the commands that people execute. A threshold has two homes inside the workflow and one outside it.

An Expression condition in the scheme. By default, it is a C# expression that reads a process parameter. It sits on a transition. A change ships as a new scheme version. Running instances keep the version they started with until you migrate them.
An Action condition in your code. Your IWorkflowActionProvider implements a named condition that can read the threshold from configuration or a table. A change needs no new scheme version, but a developer still owns the threshold. Nothing records which value routed each request.
A rule engine. It sits outside the workflow. It takes the thresholds that business owners edit, that change quarterly or more often, that grow into tables, or that several services share.

Which rule engine for which rules

Workflow Engine's own Decision Table activity is not a rule engine. Each row holds a transition condition and a target activity. The rows are stored in the scheme. The activity has no hit policies and no repository for business users. A hit policy is the rule that picks the result when several rows match.

Decision tables that analysts edit belong in a DMN engine or a business rules management system (BRMS). Both store rules as data and version them. DMN, the decision standard of the Object Management Group, reached version 1.6 in September 2026. For rules that developers own, two MIT-licensed .NET libraries are common choices.

NRules (1.0.4, published 3 February 2026) runs rules that you write in C# with an internal DSL. So a rule change is normally a code change. The project also offers JSON serialization and a text rule language called Rule#. NRules can fire several matching rules and infer new facts.
Microsoft RulesEngine (6.0.1, published 3 July 2026) keeps rules as JSON outside the code. It suits rules that change as data but need no full rule repository.

Boundary tests catch row-order and threshold mistakes

Once a threshold moves from Workflow Engine to a rule engine's table, the order of the rows is part of the logic. Under the DMN First hit policy, the engine checks the rows in order and returns the first match.

Purchase approval routing, First hit policy (from the full post)

Rule order	Supplier status	Amount (USD)	Route	Reason
1	Blocked	Any	Reject	Supplier is on the block list
2	Any	≥ 50,000	CFO approval	Above executive threshold
3	New	≥ 5,000	Procurement review	New supplier above review threshold
4	Preferred	< 50,000	Auto-approve	Preferred supplier under the limit
5	Any	Any	Manager approval	Default route

If you move row 1 below row 2, a blocked supplier's request for 60,000 goes to the CFO instead of being rejected. If you raise row 2 to 75,000 and leave row 4 at 50,000, two other routes change by accident. A preferred supplier's request for 60,000 goes to the manager. A new supplier's request for 60,000 goes to procurement review instead of the CFO. Boundary tests at 49,999.99, 50,000, 74,999.99 and 75,000 catch both mistakes before release. When rows should never overlap, the DMN Unique hit policy turns an overlap into an error.

How a workflow action calls the rule engine

With Workflow Engine, the two engines connect through a contract. It says which facts go in, which decision and rule version come out, and what happens when the call is late or fails. A workflow action is the code that a step of the scheme runs. In this pattern, the action does four things.

It reads the facts from the request's process parameters, such as the supplier status and the amount.
It calls the rule service and gives the call its own deadline, for example 500 ms.
It stores the route and the rule version as persistent parameters, which are saved with the request.
When the call is late or fails, the action stores the decision NeedsReview and the reason instead.

Transitions with Expression conditions then route the request by the stored decision. Workflow Engine checks an Otherwise transition last. This transition sends all other requests to a step where a person reviews them. Requests with the decision NeedsReview go there too. When the call to the rule service is late or fails, even a request that the rules would approve waits for a person. The reason is stored as well.

Three things need care.

The deadline needs a call that can be canceled. The action passes a cancellation token to the call. An HTTP call to a rule service stops when the token fires. A rule engine inside the same application stops only if its API accepts the token. NRules checks the token between rule firings. Give any engine that ignores the token its own time limit.
A call that changes something can run twice. After a restart, the step can run again. Such a call needs an idempotency key or an outbox. An idempotency key is a value that makes a repeated call harmless. An outbox holds messages that are saved in the same database transaction and sent after the transaction commits. A call that only computes can simply run again.
A second engine is a second system. It adds a network call, its own ways to fail and its own release cycle for rules.

The stored rule version records which rules made the decision. It does not pin the request to those rules. Suppose a request is submitted before a threshold changes and is evaluated after the change. That request takes the new route. A threshold in an Expression condition is pinned for free, because each request keeps its scheme version. With a rule engine, the contract has to carry a version or a creation time. The rule service also has to keep old versions.

What it takes to run the contract on .NET

Workflow Engine Free includes actions, persistent parameters and Expression conditions, which is all the contract needs. It runs with up to 10 workflow definitions (schemes) and 4 execution threads. A public web application or a SaaS product needs the Subscription, SaaS or Enterprise Edition of Workflow Engine NEO. Workflow Engine NEO is the HTTP API product of the Workflow Engine Family.

So keep each threshold where its owner can change it. When a threshold moves to a rule engine, keep the route in the workflow and store the rule version with every decision. The full post adds a side-by-side table of the two engines. It also answers whether rules engines are outdated now that AI models score requests. Both are in Rule Engine vs Workflow Engine, and Where a Business Rules Engine Fits.

Should a .NET approval run inside your app or in a Camunda 8 cluster?

Optimajet Limited — Tue, 27 Oct 2026 16:32:55 +0000

When managers review documents in a .NET product's own UI, the approval belongs inside your app, in an embedded engine such as Workflow Engine NEO, a commercial product by Optimajet. A Camunda 8 cluster beside the app pays off when several teams share one executable BPMN process and will use its Tasklist and Operate screens.

Jevgenije Betin, lead developer of Workflow Engine NEO, reached that verdict in a full comparison. Jevgenije modeled one approval in Camunda 8.9 Self-Managed and in Workflow Engine NEO v22. The comparison reviews both products' documentation as of 24 September 2026. No runtime benchmark was run.

This post is the short version. The full comparison goes through 16 criteria, with diagrams of both models and links to both products' documentation. It compares Camunda Self-Managed because in that setup your team deploys and upgrades both products. With Camunda SaaS, Camunda runs the platform, so running the cluster stops being your team's job.

Both products have had new releases since then. Camunda 8.10 came out on 13 October and Workflow Engine NEO 23.0.0 on 27 October. The comparison has not been rerun on either.

The same approval, modeled twice

In Workflow Engine NEO and in Camunda 8, the route is the same. An employee submits a document, a manager approves or rejects it, and a missed deadline escalates the review to a senior manager.

In Workflow Engine NEO, the route is a Scheme in the product's own Simple Process Notation, not BPMN. The Submit Command moves the process to the ManagerReview Activity. Three Transitions leave it. Approve and Reject are restricted to the Manager Actor, and a Timer moves the process to Escalated. The flow drawn in Workflow Designer is the flow the runtime executes. The notation has no modeling-only flow symbols. The Scheme is also where lock-in sits. Workflow Engine NEO's BPMN support is import-only, so a Scheme does not leave as BPMN. Moving off Workflow Engine NEO means rewriting the Scheme.

In Camunda 8, the route is BPMN. Submit document and Manager review are user tasks. The manager completes the review with a decision value, and an exclusive gateway routes on it. At the deadline, an interrupting boundary timer ends the review and starts the senior manager's route. All of these elements execute in Camunda 8.9. Some others that Modeler can draw, such as complex gateways, do not.

For this approval, Jevgenije would model the route in Workflow Engine NEO. There, Approve, Reject and the Timer all leave ManagerReview, so the decisions and the escalation are visible together. If several service teams need one executable BPMN process, Camunda's model serves them better. Both diagrams are in the workflow model section.

What runs where, and what stays with your team

With either Workflow Engine NEO or Camunda 8, the document stays in your .NET product. Workflow Engine NEO runs inside it; Camunda 8 runs beside it as a cluster.

Workflow Engine NEO runs inside the .NET service. Workflow Runtime executes the Scheme and stores process state through a persistence provider in a supported database. Workflow Designer can be embedded in the product's UI. Approval Plugin supplies Inbox entries and approval history, and Forms Plugin connects form data to the process. An HTTP API is there if you would rather run workflow as a separate service. What stays with your team is a Rule Provider that maps signed-in users to workflow Identities, the Actions that update the document or send notifications, and the task and support screens. Your team also keeps the workflow database available and recoverable. Workflow Engine NEO ships no task portal.

Camunda 8 Self-Managed runs as a separate platform. Its Orchestration Cluster holds Zeebe for execution, Tasklist for user tasks, Operate for inspecting and repairing instances, and Admin. Zeebe keeps its log and state in primary storage, and Tasklist and Operate read from a secondary storage layer. What stays with your team is running the cluster and both storage layers with their backups, and connecting the document service. If managers are to preview the document in Tasklist, your team also serves it through a protected endpoint. In return, if managers can work in Tasklist and support can work in Operate, nobody builds those screens.

The architecture section of the full comparison lists who operates what in production.

Four questions the comparison answers

Can a .NET service work with Camunda 8?

Yes. A .NET service talks to Camunda 8 through its APIs and external job workers, and the service can stay in C#. In 8.9, the version compared, the official C# SDK was in Technical Preview. Camunda's support status page lists it as fully supported from 8.10. Either way, Camunda 8 is not an engine you embed in a .NET process. The C# code talks to a cluster.

Does Camunda 8 Self-Managed need Kubernetes and Elasticsearch?

No. Camunda recommends Helm on Kubernetes and also supports Docker on Linux and a manual Java deployment. The Docker Compose quickstart is for development. In 8.9, the secondary storage can be a relational database as well as Elasticsearch or OpenSearch. The relational database does not replace Zeebe's primary storage. Optimize, Camunda's reporting tool, still needs Elasticsearch or OpenSearch.

Can a Camunda process move to Workflow Engine NEO unchanged?

Do not assume it can. Workflow Engine NEO imports BPMN by converting the supported elements into a Scheme. The runtime then executes the Scheme, not the BPMN XML. Task assignments, forms, Camunda extensions, decision models and worker behavior need their own migration review. The BPMN support page lists what converts, and the product comparison shows which Editions include BPMN import.

How is each one licensed?

Three of the four Editions of Workflow Engine NEO have published prices on the pricing page. The Enterprise Edition is priced by quote. The SaaS Edition licenses your own public application. Optimajet does not host Workflow Engine NEO. Camunda's pricing allows free local development and non-production use, and Self-Managed in production needs an enterprise license and a quote. For embedding in a product you sell, both offer negotiated terms, through the Enterprise Edition of Workflow Engine NEO and through Camunda's OEM program.

When to pick Workflow Engine NEO, and when Camunda 8

For this approval inside a .NET document product, Jevgenije's comparison picks Workflow Engine NEO. Workflow Runtime can run beside the document service, and the manager's form can live in the existing UI. The team builds the task and support screens around them. Form Engine Designer, which styles that form, is licensed separately except in the Enterprise Edition of Workflow Engine NEO.

Camunda 8 Self-Managed is the better pick when several teams need one executable BPMN process across their services and will use Tasklist and Operate as their task and incident screens. The trade-off is a separate cluster to run and an integration with the document service.

For a .NET team new to both, the learning differs too. With Workflow Engine NEO, the team learns how Triggers, Conditions, Rules and Actions shape a Scheme. It adds Workflow Runtime and a persistence provider to its .NET host and runs the migrations for a SQL provider. With Camunda, the team learns which BPMN symbols Camunda executes and FEEL expressions for conditions. It also deploys the cluster with its storage.

Before you decide

The full comparison of Camunda 8 and Workflow Engine NEO lists six tests to run on your own process before choosing. Here are three of them.

Revoke access. Remove the manager's permission after the task exists, then try the UI and a direct workflow call. Try both again as a user of another tenant (another customer in a multi-tenant product).
Interrupt execution. Restart the host or the cluster during the wait, then interrupt the work after the document update succeeds but before the workflow step completes.
Repair an incident. Diagnose a failed instance, make an authorized repair and restore a backup. With Camunda, support does it in Operate; with Workflow Engine NEO, in the support screen your team built.

Then count what each product left to your team. For Workflow Engine NEO, that is the task and support screens. For Camunda, it is the document integration, the cluster and any service-task workers.

The deadlines, concurrency, versioning and multitenancy sections, with the other three tests, are in the full comparison of Camunda 8 and Workflow Engine NEO.

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 use and internal commercial use with attribution, 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 use and internal commercial use with attribution, and it 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 use and internal commercial use with attribution. 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 use and internal commercial use with attribution. 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 use and internal commercial use with attribution, 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, and Workflow Engine Free costs nothing. It's not open source. Workflow Engine NEO Enterprise includes one year of access to the engine source, and Workflow Engine Complete, NEO Business and NEO SaaS can add it. 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, five 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, Workflow 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, a database (SQLite counts, it's just a file) and, for the rpc/create-instance call, a Workflow Engine NEO trial key set in options.LicenseKey. The RPC API is a Workflow Engine NEO capability, so without that key MapWorkflowApi() maps only the designer and health check endpoints. 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() lifts the Workflow Engine Free limits, so moving from Free to Team or Complete is a key swap on the same packages. Workflow Engine NEO is a separate product based on Workflow Engine: its key keeps your existing application running as it is, and its Data API, RPC API, multitenancy and forms need the matching packages and the code that calls them.

Edition	License	Limits and additions
Workflow Engine Free	Perpetual, personal and internal commercial use, with attribution	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, 8 execution threads, up to 100 activities, 500 transitions and 100 commands per schema, 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 Subscription	Annual subscription	Data API and RPC API, full hybrid multitenancy, clustering, forms integration
Workflow Engine NEO Business	Perpetual	Data API and RPC API, full hybrid multitenancy, clustering, forms integration
Workflow Engine NEO SaaS	Perpetual	Everything in NEO Business, plus the Active Directory Plugin and the BPMN Plugin
Workflow Engine NEO Enterprise	Perpetual	All of the above, plus white-label canvas, OEM redistribution, a Form Engine Enterprise license with OEM rights, 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 under a commercial license, with a free product, Workflow Engine Free. It is perpetual and needs no key. It covers personal and internal commercial use, with attribution, 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 trial key with all features 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://docs.workflowengine.io/llms.txt is the index of the current documentation.
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://docs.workflowengine.io/llms.txt for the index of the current documentation.
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 .NET 10, 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 separate product based on Workflow Engine; 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 Data API and the RPC API require a Workflow Engine NEO license key; without it, the Web API starts with only the designer and health check endpoints. The Data/RPC split is therefore a paid Workflow Engine NEO capability; Workflow Engine (Team and Complete editions) and Workflow Engine Free (formerly 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 global parameters, workflow schemes, process parameters and timers, and delete operations for 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()
    .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")
    .DenyAllTenantsExcept("TenantA"));

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 Data API operation has a concrete identifier under workflow-api.data.* or workflow-api.search.*, and each RPC API operation one under 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 WorkflowRuntime APIs were removed in the same release, 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 capabilities of Workflow Engine NEO, a licensed product, 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!