992 · Workflow Engine by Optimajet · v22.1.0 stable · August 2026 · HTTP API on .NET 8 or newer · Page last updated
Serve every customer from one deployment of your .NET app. Workflow Engine NEO adds a ready HTTP API with tenant isolation, and new customers arrive without a restart.
Separate product based on Workflow Engine · 30-day trial key, no credit card · Commercial EULA
Workflow Engine NEO is a separate product in the Workflow Engine Family by Optimajet. It is based on Workflow Engine and adds a ready ASP.NET Core HTTP API, multitenancy and forms integration to the application you already run.
Your customers' people, in your product
Workflow-Api-Tenant-ID: acme-corp
An approver in your web app
Workflow-Api-Tenant-ID: globex
A manager in your mobile app
Workflow-Api-Tenant-ID: stark
An analyst in your web app
Your ASP.NET Core app, with Workflow Engine NEO inside
Data API · RPC API · Designer API · health checks · published by one MapWorkflowApi() call
Physical tenant · own database
WorkflowRuntime A
serves acme-corp only
db-acme
SQL Server · backed up on its own
Logical tenants · shared database
WorkflowRuntime B
serves globex and stark, every record filtered by TenantId
db-shared
PostgreSQL · one row set per tenant
Every request carries its customer in the Workflow-Api-Tenant-ID header, and the HTTP API scopes each process call to that customer. To give a customer its own database, copy its data there and change its registration.
NEO is NuGet packages inside your app. Optimajet runs no NEO cloud.
One MapWorkflowApi() call publishes the HTTP API.
A tenant is registered while the app runs, since v22.0.0.
Your database, your identity system, your servers.
Pick the card closest to your project. It says what fits it and opens the page that answers it, on this site or in the documentation.
Temporal, Camunda, Elsa, Workflow Core or Windows Workflow Foundation. Our comparison of nine .NET options shows what each one needs to run and where the engine lives.
Read the comparisonStart on Workflow Engine Free with no license key. When you need more, register a key in the same app, with no rewrite.
Open Get StartedA rule reads the transition history, so whoever submitted a change is not offered Approve, and the restriction check refuses it. This already works in Workflow Engine Free.
Open the Rule docsWorkflow Designer is a browser component with React and Angular wrappers on npm, and Blazor hosts it through JavaScript interop. In NEO, each tenant's users edit their own schemes.
Open the designer guideOne HTTP API serves every tenant, isolated logically or physically. A coding agent sets up a trial with two tenants on your machine in about 15 minutes.
Try it in 15 minutesWorkflow Server runs as a separate service in Docker. Your Node.js, Python or Java code calls its REST API, and its Callback API calls your code back.
See Workflow ServerWorkflow Designer is the browser editor where your team and your customers' staff draw schemes. In Workflow Engine NEO you embed it for each tenant, so every customer changes its own process inside your product.
React and Angular wrappers ship on npm, Blazor hosts the same component through JavaScript interop, and any other front end loads the vanilla package.
Embedded through the HTTP API, the designer works in the tenant of the request. A scheme it saves belongs to that tenant, and a shared scheme can still serve every tenant.
Turn Code Actions off for your customers' users, because Code Actions compile C# with full server access. Keep sensitive behavior in server-side actions your team reviews.
The React, Angular, Blazor and JavaScript pages show how it embeds in each stack, and the Workflow Designer page covers the whole feature.
Simple Process Notation has three building blocks where BPMN has more than 50 element types. Everything else is a setting the designer draws in color and shape, so your customers' users, your analysts and your developers read a scheme the same way.
Scroll sideways to see the whole scheme.
Transitions
Transition pills
Activities
Activity implementation
Business users
The orange activity shows where a request is now. The arrows leaving it show what can happen next, and the person icon on a pill shows who may do it.
Analysts
Branching rules sit on the arrows. A ? marks a condition, and the Otherwise mark shows the path taken when no condition passes. The diagram you review with the business is the specification the engine runs.
Developers
Every mark is a property you can also set in C# or in the scheme XML. Classifier colors the arrow, Trigger names the pill and IsFork dashes the line. The runtime executes what was drawn.
One Workflow Engine NEO deployment serves many customers, called tenants, from one .NET application. You choose how strong the isolation is for each tenant, and one HTTP API host can mix the models.
Tenants share one WorkflowRuntime and one database. Records are isolated by TenantId. Lowest cost per tenant. Good for many small customers on shared infrastructure.
Each tenant gets its own database and its own WorkflowRuntime. Full isolation at the persistence layer, with per-tenant backup and restore. Good for enterprise customers with data-residency rules.
One HTTP API host maps some tenant IDs to dedicated runtimes and databases, and groups other IDs on shared ones. One Workflow Engine NEO deployment can even serve tenants on different databases at the same time, for example two tenants on SQL Server and two on PostgreSQL, each physical tenant with its own connection string.
The engine side of this is covered in depth on the multitenancy feature page.
Since v22.0.0 a workflow scheme can belong to one tenant, or serve every tenant when it is saved without one. So one standard approval scheme can serve most customers, while a customer who pays for custom routing gets its own in the same installation. Forms work the same way: a tenant's own form wins, and a shared form is the fallback. Process data always stays with its tenant. The built-in Data API and RPC API operations use the exact tenant of the request, so a process saved without a tenant is not shared with a named one.
A request names its tenant in the Workflow-Api-Tenant-ID header. Data API queries filter by that tenant, RPC operations check the process tenant, and a process of another tenant comes back as not found. The isolation covers statuses, parameters, timers, transition history, inbox entries and approval history, and the TenantId goes on to subprocesses. The header itself grants nothing. Register AddWorkflowApiSecurity() and the caller's permissions claim must also allow that tenant, or the request gets 403. Endpoints you write yourself and direct database access stay your application's job.
Since v22.0.0 the tenant registry accepts changes at runtime. A new customer signs up, your provisioning code registers the tenant, and existing tenants keep working. No deployment, no restart window.
// A new customer signs up. Register them as a tenant, at runtime:
var tenantRegistry = services.GetRequiredService<IWorkflowTenantRegistry>();
var tenants = await tenantRegistry.RegisterTenantsAsync(new WorkflowTenantCreationOptions
{
TenantIds = ["TenantA"],
PersistenceProviderId = PersistenceProviderId.Mssql,
ConnectionString = connectionString
});
// No restart. Existing tenants keep processing their workflows.
// Offboarding is the same call in reverse:
await tenantRegistry.UnregisterTenantsAsync(tenants.Single());Registration does not create the tenant's database or store its secrets; your provisioning code does that. Registered from WorkflowTenantCreationOptions as above, a tenant on SQL Server, PostgreSQL, MySQL, Oracle or SQLite gets its schema migrations run by default. MongoDB is set up separately.
The HTTP API is a set of ASP.NET Core endpoints inside your own application. You register tenants, add the database providers you use, wire the security services, and set the license key. Without a NEO or trial key, only the Designer and health endpoints answer.
builder.Services.AddWorkflowApiCore(options =>
{
options.LicenseKey = "your NEO license key";
options.DefaultTenantId = null; // multi-tenant: every request must name a tenant
});
builder.Services.AddWorkflowTenants(
new WorkflowTenantCreationOptions
{
// Physical tenant: own database, own WorkflowRuntime
TenantIds = ["acme-corp"],
PersistenceProviderId = PersistenceProviderId.Mssql,
ConnectionString = "Server=db-acme;Database=Workflow;..."
},
new WorkflowTenantCreationOptions
{
// Logical tenants: two IDs share one database
TenantIds = ["globex", "stark"],
PersistenceProviderId = PersistenceProviderId.Postgres,
ConnectionString = "Host=db-shared;Database=workflow;..."
});
builder.Services.AddWorkflowApiMssql();
builder.Services.AddWorkflowApiPostgres();
builder.Services.AddWorkflowApiSecurity();
var app = builder.Build();
app.MapWorkflowApi();| Name | Type | Default | Description |
|---|---|---|---|
| BasePath | string | "workflow-api" | Root URL path for all endpoints. |
| LicenseKey | string | "" | Required for the Data API and the RPC API. Without it the API still serves the Workflow Designer and the readiness and liveness probes. |
| DefaultTenantId | string? | SingleTenantId | Used when a request names no tenant. In multi-tenant mode, set it to null so every request must declare a tenant. |
Setup and security are covered step by step in the HTTP API documentation.
Workflow Engine NEO runs inside your ASP.NET Core app, with no cluster to set up. Its HTTP API and tenant isolation come ready. That is why a coding agent can build the whole trial while you watch.
rpc/execute-command → 200, "wasExecuted": truerpc/get-process-instance → 404, "code": "NotFound"npx @optimajet/workflow-designer … ApprovalThe agent writes the boilerplate for you: the project, the packages, Program.cs and each request. Everything stays in one folder on your machine, and the code is yours to keep as the start of a proof of concept.
Copy the prompt into Claude Code, Cursor or Copilot.
Give your business email and say yes. The agent requests a free 30-day trial key.
Watch it create the app, register two tenants and send the requests.
Read every request and response it shows you, then open the scheme.
Set up a local trial of Workflow Engine NEO by Optimajet for me: one ASP.NET Core app whose HTTP API serves two tenants, with one approval run for each. Follow the documentation pages named below and copy code from the rendered pages, not from llms-full.txt. 1. Check for the .NET 8 SDK or newer (dotnet --list-sdks). If it is missing, stop and tell me. 2. Get the license key before the first run: multitenancy, the Data API and the RPC API need a Workflow Engine NEO key or a trial key. If I give you a key, use it. If not, say that you will send my business email and company name to POST https://trial.workflowengine.io/api/trial/llm (see https://trial.workflowengine.io/llms.txt), ask me for both, wait for my yes, and send one request. The portal gives 3 keys per address, ever, and refuses personal email domains. Keep the key in dotnet user-secrets as Workflow:LicenseKey, never in source code or git. 3. Create the app as https://docs.workflowengine.io/get-started/install-workflow-engine/ shows, with OptimaJet.Workflow.Api and OptimaJet.Workflow.Api.Sqlite. The page targets net10.0; with an older SDK use its framework (net8.0 works). Replace AddWorkflowRuntime with AddWorkflowTenants and one WorkflowTenantCreationOptions: TenantIds ["acme", "globex"], PersistenceProviderId.Sqlite (namespace OptimaJet.Workflow.Core), one SQLite file, runtime.AsSingleServer(). In AddWorkflowApiCore, read LicenseKey from configuration and set DefaultTenantId = "acme" for this local trial only, because the standalone Workflow Designer sends no tenant header. Keep the allow-any-origin CORS policy for development only. Start it with dotnet run -- --urls http://localhost:5274. 4. Follow https://docs.workflowengine.io/get-started/create-your-first-workflow/ with two changes: rename the command Submit to Approve everywhere, and send the header Workflow-Api-Tenant-ID on every request, the Designer API calls included. Upload and save the scheme for acme and again for globex: a scheme saved through the Designer API belongs to the tenant of the request. For acme, create an instance, get the available commands, execute Approve and read the instance back (it must be at Approved). For globex, create an instance and leave it at Draft. 5. Show the tenant isolation: rpc/get-process-instance for the acme process with the globex header must answer 404. 6. Open the scheme in Workflow Designer: npx @optimajet/workflow-designer http://localhost:5274/workflow-api/designer Approval (it needs Node.js and opens a browser tab on macOS and Windows). 7. Show me each request with its response, then point me to https://workflowengine.io/products/workflow-engine-neo/ for tenancy and permissions, and to https://workflowengine.io/book-a-demo/ to discuss my own case.
When the trial runs, the next question is your own tenancy model. Bring it to a one-hour demo, or first read how tenants and permissions work in Workflow Engine NEO.
Book a demoYou need the .NET 8 SDK and Node.js. Without an agent, follow Install Workflow Engine in the documentation and request the key at trial.workflowengine.io.
Every approval and human task needs a screen. With the Forms Plugin, in every edition of Workflow Engine NEO, you attach a form to a step with the "Show Form" activity, and the runtime serves it when a process gets there. A tenant can have its own form, with a shared one as the fallback.
var formsSettings = new FormsPluginSettings
{
FormsManagerUrl = "https://forms.example.com"
};
runtime.WithPlugin(new FormsPlugin(formsSettings));Build the form in Form Engine Designer, or write its JSON yourself. Changing a form needs no redeploy. The workflow forms page shows which steps need a form and what the binding saves you writing.
Your back end calls FormsRuntimeApi, and an endpoint of your own hands the result to the browser. GetExecutableFormsAsync() returns the current step's forms with their definition and data, SaveFormAsync() keeps a draft, and ExecuteFormAsync() submits the data and runs the workflow command in one call. GetFormAsync() and GetProcessFormAsync() load a single form.
A user can fill half a form, save a draft and come back later. Form definitions are versioned. Pin a version in the step's settings, or leave it empty and each lookup takes the latest one.
All six database providers (SQL Server, PostgreSQL, MongoDB, MySQL, Oracle, SQLite) store form definitions. Submitted data lands in the process parameters you name, with no extra tables for it. Server-side rules run once you register your own IFormValidator, because the default one accepts any data. For React front ends, @optimajet/workflow-forms-manager and @optimajet/workflow-forms-viewer ship on npm.
Form Engine Core renders and validates forms under the MIT license. The Form Engine Enterprise license covers Form Engine Designer and the other features of that edition. It is priced separately for NEO Subscription, Business, and SaaS; NEO Enterprise includes it with OEM rights. Since v22.0.0 the Forms Plugin runs tenant-aware on Form Engine Core 10.0.1: a tenant-specific form wins, and a shared form is the fallback.
Elsa Workflows 3.7 leaves forms, the inbox and human-task permissions to your application. Our comparison of August 2026 builds one approval process in both engines.
Once you register AddWorkflowApiSecurity(), NEO authorizes each API call through a WorkflowApiPermissions claim attached to the caller. The claim is a compact string of allow and deny rules over a hierarchical operation namespace, plus tenant rules. More specific rules win.
<effect>:<target>[;<effect>:<target>]
# effect: a (allow) | d (deny)
# target: operation branch under workflow-api OR tenant rule under tenantsThe string is small enough to travel in a JWT payload, and a typed builder API composes it. Authentication itself stays standard ASP.NET Core middleware (JWT bearer tokens, cookies, any registered scheme); the engine keeps no parallel user store of its own.
| Value | Meaning |
|---|---|
| a:workflow-api | Allow all Workflow Engine API operations. |
| d:workflow-api | Deny all. |
| d:workflow-api;a:workflow-api.rpc | Deny everything except the RPC branch. |
| a:workflow-api;d:workflow-api.rpc.delete-instance | Allow everything except delete-instance. |
| a:tenants:TenantA,TenantB | Restrict the caller to TenantA and TenantB. |
| d:tenants:TenantA,TenantB | Allow all tenants except TenantA and TenantB. |
// Strict allow-list
var claim = permissions.BuildClaim(builder => builder
.DenyAllOperations()
.Allow(
WorkflowApiOperationId.Liveness,
WorkflowApiOperationId.DataSchemesGetCollection,
WorkflowApiOperationId.DataSchemesGet)
.DenyAllTenantsExcept("TenantA"));
// Branch allow + specific deny
var claim = permissions.BuildClaim(builder => builder
.DenyAllOperations()
.Allow("workflow-api.rpc")
.Deny(WorkflowApiOperationId.RpcDeleteInstance)
.AllowAllTenants());On the same product version, moving from Workflow Engine to Workflow Engine NEO requires only registering the Workflow Engine NEO license key. Your runtime integration, schemes, processes and history carry over. Adopt the newly licensed features one at a time.
WorkflowRuntime.Register the Workflow Engine NEO license key. That is the product switch; it does not require a scheme or integration rewrite.
Optional feature packagesInstall packages only for the capabilities you choose. For the HTTP API, add OptimaJet.Workflow.Api and its provider integration; forms use the Forms Plugin package.
AddWorkflowRuntime(...) or AddWorkflowTenants(...)If you expose the HTTP API, connect it to your existing runtime or configure logical, physical, or hybrid tenant placement.
MapWorkflowApi() + AddWorkflowApiSecurity(...)Map and secure any endpoints you expose so callers carry the WorkflowApiPermissions claim. Without a NEO or trial key, Designer and health endpoints remain available, while Data, Search, and RPC stay disabled.
Moving to v22.0.0 is a real upgrade on its own, for any product. It has breaking changes and mandatory database migrations, and the release notes pair each change with a migration scenario.
Direct answers to the questions teams ask while evaluating Workflow Engine NEO: the HTTP API, multitenancy, forms, editions, and licensing.
Workflow Engine NEO is a separate SaaS-oriented product in the Workflow Engine Family by Optimajet, based on Workflow Engine since v19.0.0. It includes a ready-to-use HTTP API (Data, RPC, and Search endpoints), full hybrid multitenancy, multi-server clustering, and forms integration with Form Engine through the Forms Plugin.
No. Workflow Engine NEO is the product; Workflow Engine HTTP API is one of the capabilities it includes. The OptimaJet.Workflow.Api package supplies the API, while the legacy documentation at workflowengine.io/documentation/web-api calls the same component the Workflow Engine Web API, its former name. Its Data API, RPC API, multitenancy, and security services describe the HTTP capability included with Workflow Engine NEO.
They are separate products. Workflow Engine NEO is based on Workflow Engine, and every edition of Workflow Engine NEO includes the HTTP API, full multitenancy, and the Forms Plugin. In Workflow Engine, multitenancy is a building block: the runtime stores the TenantId you supply when a process is created and passes it to subprocesses, and your application designs the isolation and controls access. If the HTTP API package is installed without a NEO key, it still serves the Designer API and the readiness and liveness probes, while the Data, Search, and RPC endpoints stay closed.
Not always. Workflow Engine and Workflow Engine Free are .NET libraries. You call them from C# inside your own process, so they power ASP.NET apps without Workflow Engine NEO. Choose Workflow Engine NEO when you drive workflow over HTTP: a JavaScript or mobile frontend, a Python or Java service, or several services that call one workflow API. The product includes that API ready-made, so you do not write controllers around the runtime.
No. Workflow Engine NEO is an embeddable product. You install NuGet packages, host the HTTP API in your own infrastructure, point it at your own database, and operate it. Optimajet does not run a NEO cloud. If you want a turnkey product, look at Workflow Server, a separate Optimajet product on workflowserver.io.
Hybrid multitenancy means tenants with their own database and tenants that share one live in one installation, behind one HTTP API host. Since v22.0.0 a workflow scheme can belong to one tenant or, saved without one, serve every tenant, and a tenant's own form wins over a shared one. Process data always stays with its tenant, because the built-in Data API and RPC API operations use the exact tenant of the request.
Yes, since v22.0.0. The tenant registry accepts changes at runtime: IWorkflowTenantRegistry.RegisterTenantsAsync adds tenants and UnregisterTenantsAsync removes them while the host keeps running. Existing tenants keep processing their workflows. Onboarding a customer becomes a database operation, not a deployment.
Not through the HTTP API. Data API queries filter by the selected tenant, and RPC API operations check the process tenant. A process from another tenant comes back as not found, so one tenant cannot even probe whether another tenant's data exists. The isolation covers statuses, parameters, timers, transition history, inbox entries and approval history. With AddWorkflowApiSecurity() registered, a caller also reaches only the tenants its permissions claim allows. Endpoints you write yourself and direct database access stay your application's responsibility.
Through a WorkflowApiPermissions claim attached to the caller. The claim is a compact string of allow and deny rules. The format is effect:target pairs separated by semicolons, where the effect is a (allow) or d (deny) and the target is an operation branch under workflow-api or a tenant rule under tenants. Example: d:workflow-api;a:workflow-api.rpc;a:tenants:TenantA means deny everything, allow the RPC branch, and restrict the caller to TenantA. More specific rules win.
Every edition of Workflow Engine NEO includes the Forms Plugin. Form Engine Core renders and validates forms under the MIT license. The Form Engine Enterprise license covers Form Engine Designer and the other features of that edition. It is priced separately for Workflow Engine NEO Subscription, Business, and SaaS; Workflow Engine NEO Enterprise includes it with OEM rights. All six database providers (SQL Server, PostgreSQL, MongoDB, MySQL, Oracle, SQLite) store form definitions.
Yes. For an existing application on the same product version, moving from Workflow Engine to Workflow Engine NEO requires only registering the Workflow Engine NEO license key. Your existing schemes, processes, data, and Workflow Runtime integration continue unchanged. You can adopt Workflow Engine NEO capabilities gradually; install and configure the Workflow Engine HTTP API only if you choose to expose it.
The HTTP API package (OptimaJet.Workflow.Api) needs .NET 8 or newer; the 21.0.0 release dropped .NET 6 from the HTTP API and added .NET 10 support. The underlying WorkflowEngine.NETCore-Core library targets netstandard2.0, so the engine itself runs on the same range of .NET versions as base Workflow Engine.
Workflow Engine NEO has four editions: Subscription, Business, SaaS, and Enterprise. Subscription is annual for public SaaS platforms. Business is a perpetual license for internal applications. SaaS is a perpetual license for public platforms. Enterprise adds Workflow Engine redistribution rights, a white-label Workflow Designer, the Form Engine Enterprise license with OEM rights, and source code access. All four editions include the APIs, clustering, and full hybrid multitenancy. The full matrix is on the pricing page.
Request a free 30-day trial key at trial.workflowengine.io. No credit card is required. The trial covers the HTTP API, full multitenancy, and the Forms Plugin; install and configure the capabilities you want to evaluate. The portal also publishes llms.txt instructions, so an AI coding agent can walk through the trial key generation for you.
Our published benchmark measured Workflow Engine at 250 operations per second on a high-performance server. Workflow Engine NEO runs the same engine and adds its HTTP API layer. If you need many thousands of operations per second, you are likely outside the business-process category and should look at stream processors.
The underlying Workflow Engine has been in production since 2014 and is used by Dell, KPMG, Bosch, Philips, GE Honda Aero Engines, ProcessMAP, and Nelnet. The HTTP API capability first shipped in v14.0.0 (August 2024). The RPC API and full multitenancy shipped in v19.0.0 (September 2025). Dynamic tenant registration and hybrid multitenancy shipped in v22.0.0 (July 2026).
Fawry Lending moved its loan processing workflows out of the application code and onto Workflow Engine NEO, a .NET workflow engine with multitenancy.
When a caller should reach for the Data API and when it needs the RPC API in Workflow Engine NEO, with a decision table you can hand to your team.
Workflow Engine NEO 22.0.0 adds tenants at runtime and scopes schemes, forms, and process data per tenant. What changed, with code and upgrade steps.
See what the HTTP API gives you, try it with a free 30-day trial key, and bring your tenancy and licensing questions to a demo.
01Documentation
What the ready-to-use API covers: Data, RPC, and Search endpoints, hybrid multitenancy, security services. About an hour from install to a running HTTP API.
02Trial
A free 30-day key, no credit card. The trial covers the HTTP API, full multitenancy, and the Forms Plugin; connect the capabilities you want to evaluate.
03Book a demo
An hour with the team: tenancy topology for your SaaS, forms integration for approvals and human tasks, editions, migration questions.
