Multi-tenant SaaS on a .NET workflow engine, without restarting to onboard a customer

The most expensive restart in SaaS is often the one nobody planned: onboarding a new customer. Every SaaS team expects adding a tenant to be a database operation. I still see production systems where it is a deployment.

I am Mike Lukinov, co-founder of version 22.0.0, and for SaaS teams it changes the thing that matters most: tenants become runtime objects instead of startup configuration. Tenants register and unregister while the host is running, and multi-tenancy is finally full and hybrid, meaning every layer of engine data can be tenant-scoped or shared, side by side in one installation.

Here is the scene that drove this work. Last month I spoke with a team running about 150 enterprise tenants on .NET. Everything worked, until sales signed one more customer. Their onboarding checklist contained the line "restart production". Every restart window interrupted other tenants' approvals mid-flight. That was not a workflow problem, it was an architecture problem.

This post is the announcement written the way I explain it on architecture calls: what a SaaS team should demand from a .NET workflow engine, and how the new version answers it. I mark each block as Documented behavior, Architectural recommendation, or Honest limitation, so you can separate facts from my opinion.

What a multi-tenant SaaS needs from a workflow engine

Architectural recommendation. When teams evaluate an enterprise workflow engine for SaaS, they usually compare designers and API surfaces. The tenancy questions surface later, in the security review, and they are the expensive ones. Five of them matter most:

1. Can shared and tenant-specific data live side by side, or is tenancy all-or-nothing?


2. Can I add a tenant without redeploying or restarting anything?


3. Is tenant isolation enforced by the engine and its API, or by discipline in my own code?


4. Does isolation cover all engine data, or only the process table?


5. Can I adopt tenancy gradually, or does it require a data migration on day one?

Hold any engine you evaluate against these five. The rest of this post is how Workflow Engine NEO answers them.

Question 1: can shared and tenant-specific data live side by side

Documented behavior. The engine now implements full hybrid multi-tenancy. Every kind of engine data (workflow schemes, Global Parameters, forms, process records) exists in one of two forms: shared and visible to every tenant, or scoped to one tenant. A record with an empty tenant value is shared; a record created in a tenant context carries that tenant's ID. The Forms Plugin resolves a tenant-specific form first and falls back to the shared one.

Shared (no tenant ID)

├── Standard workflow schemes

├── Shared forms

└── Global Parameters

        │ visible to every tenant

   ┌────┴─────────┬───────────────┐

Tenant A       Tenant B        Tenant C

processes      processes       custom scheme

history        history         custom forms

inbox          inbox           processes, history

Architectural recommendation. This hybrid model matches how a SaaS grows. One standard approval flow serves most customers; the accounts that pay for custom routing get multi-tenant workflows scoped to them, in the same installation. The alternative, a separate deployment per customized customer, is how SaaS margins die.

Question 2: runtime tenant onboarding while the host is running

Documented behavior. Per the ; everything there still holds, now with tenant isolation enforced underneath it.

Question 4: how deep the isolation goes

Documented behavior. Tenant isolation now covers everything the engine stores: schemes, Global Parameters, forms, and every process-related record, from statuses and timers to transition history, inbox entries, and approval history. The Forms Plugin runs tenant-aware on Form Engine 10.0.1.

Architectural recommendation. The record types at the end of that list are the ones to check in any engine you evaluate. Schemes and processes get the attention, but transition history, inbox entries, and approval history are what your auditor asks about, and they leak tenant activity just as well as a process record does. Isolation that stops at the process table is not isolation.

Question 5: what happens to the data you already have

Documented behavior. Nothing changes on its own. Existing records have no tenant value, so under the hybrid model from Question 1 they are shared and stay visible across tenants, exactly as they behaved before the upgrade. Only new records created in a tenant context get a tenant ID.

Architectural recommendation. Upgrade first, then adopt tenancy at the pace your contracts demand, not the pace your engine dictates. Keep standard schemes shared, scope the customer-specific ones, and let historical process data age out as shared records.

Honest limitations

I would rather you hear these from me than from your own upgrade weekend.

• 
  22.0.0 is a breaking release. The tenant contract changed (custom IWorkflowTenant implementations need lifecycle members), several IPersistenceProvider signatures now take a tenant ID, and the AssignmentPlugin was removed. Database migrations are mandatory: SQL providers run RunMigrations() before starting the updated runtime, MongoDB needs the update_22.0.0.js index script run manually. The lets you evaluate it; the free Community Edition covers the embeddable in-process library, not the Web API.


• 
  Runtime registration does not provision infrastructure. RegisterTenantsAsync registers a tenant against a connection string you supply. Creating the database, running its schema, and storing its secrets remain your provisioning code's job.

Version note

Everything above targets Workflow Engine 22.0.0 (July 16, 2026), verified against the official release notes and the NuGet registry (WorkflowEngine.NETCore-Core 22.0.0) on 2026-07-21. On 21.x and earlier the tenant list is static and the data-layer scoping described here does not exist; do not read this article as documentation for those versions.

The questions are older than the release

Most workflow engine evaluations still focus on designers, BPMN coverage, and APIs. In SaaS, the tenant lifecycle becomes the real architectural bottleneck much later, when changing the answer is already expensive. The five questions above are worth asking before that day arrives, whichever workflow engine for SaaS you end up choosing.

If you want to check our answers against your own architecture, the upgrade details are on where we build the argument on your tenancy model, not ours.