# warm-flow keeps a workflow engine down to seven tables and a jar-based designer

> warm-flow is a Java workflow engine built around a small schema, a JSON flow definition and a designer that ships as a jar you embed in your own application. It targets teams that find Activiti and Flowable heavy to learn and awkward to integrate, and it accepts MySQL, Oracle, PostgreSQL and SQL Server with several ORM choices.

**dromara/warm-flow** — Warm-Flow国产工作流引擎🎉，其特点简洁轻量，五脏俱全，可扩展，是一个可通过jar引入设计器的工作流。。解决flowable和activities复杂、学习成本高和集成难等痛点。

- Repository: https://github.com/dromara/warm-flow
- Website: http://www.warm-flow.cn
- Stars: 628 · Forks: 91
- Language: Java
- License: Apache-2.0
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/dromara-warm-flow

## Seven tables instead of a BPMN platform

warm-flow is described as a domestic workflow engine, one built in China, and the positioning statement is direct about the problem it attacks. It exists to solve the pain points of Flowable and Activiti: their complexity, their high learning cost and their difficult integration.

The design decision that follows from that is the schema. The README lists only 7 tables as a headline feature, describes the code volume as small, and argues that this keeps the start-up and integration effort low. Everything else in the project is shaped by that choice. The flow definition is JSON based rather than BPMN based, and the designer is embedded in your application rather than deployed beside it.

The audience is stated just as plainly. The listed scenarios are enterprise internal process management for leave, reimbursement and purchase approval, project tracking, customer service requests, human resources processes, financial approval such as invoice review, IT service management, and compliance and risk management. The README frames the engine as aimed at small and mid-sized projects and quick approval scenarios, with flexible extension and low-code integration.

There is a licensing stance that reduces adoption risk in a specific way. The project states that the code and documentation are open source, free and permitted for commercial use as long as you follow the open source agreement, and that there will never be a commercial edition.

It also asks users to register their projects in a usage list once development is complete, which tells you the maintainers are tracking adoption by hand.

## The approval operations the engine names explicitly

Workflow engines are bought on the strength of the operations their approvers can perform, so the feature list here is worth reading closely rather than skimming.

The README lists support for approve, return, revoke, take back, jump to any node, terminate, transfer, countersign, delegation with adding and removing signers, mutual exclusion, parallel paths, automatic approval, remote access and a script execution service. Alongside those it names condition expressions, handler expressions and listeners as advanced features.

The expression support is specific. Condition expressions come in the common built-in forms and in SpEL, and can be extended by the user. Handler expressions include a built-in variable form and SpEL, and the process variables section explains why they matter: they are passed into handler expressions to designate handlers dynamically at runtime. The listener section describes four kinds of listener with different scopes and SpEL expressions, flexible parameter passing and support for dynamic permissions.

The net effect is that a designer can express a fairly conventional approval product without a plugin. That is the argument of the whole project, and it is worth checking against your own requirements list, because the operations above are exactly the ones an approval product is bought for, and a flow engine that lacks one of them is a rewrite rather than a configuration.

## A designer that ships as a jar dependency

The designer is the part that distinguishes this project from a pure engine, and it is delivered in a way that matches the integration complaint in the description.

The README says the designer can be integrated quickly through a jar package, that it supports node property extension, and that it natively supports two modes, the classic mode and a DingTalk-like mode. The built-in flow diagram works the same way, integrated through the jar, with node state colours and room for extension, and both the designer and the diagram support the classic and DingTalk-like dual modes.

The practical difference from the alternatives is where the designer runs. A separate designer server is another deployment, another version to keep in step and another thing to reach when you want to draw a flow. A designer inside the jar is part of the application you already ship, so the flow definition lives in the same artefact as the code that runs it.

The repository layout backs this up. There is a warm-flow-vue-designer directory, a warm-flow-designer-demo directory, a warm-flow-ui directory, and a package.json that describes a pnpm workspace for the Warm-Flow designer component and a consumption example. The package name is warm-flow-vue-workspace, marked private, and the description notes that it is the pnpm workspace for the designer component plus a consumer example and does not contain the Maven modules or warm-flow-ui.

So alongside the Java side there is a Vue based designer component workspace.

## Database setup is two scripts, one for install and one per upgrade

Bringing up the schema is described as a two step procedure, and the second step is the one teams tend to forget.

On first import you create the database and run the full script for your database, and the README links that as warm-flow-all.sql under the MySQL directory of the sql folder. When you upgrade the version, you find the update script for your database, for example an upgrade script in the v1-upgrade directory named warm-flow_x.x.x.sql, and run that instead:

```bash
warm-flow-all.sql
warm-flow_x.x.x.sql
```

The distinction is worth internalising because the two scripts do different jobs. The all script is the complete schema for a fresh install, and the upgrade scripts migrate an existing database forward one version at a time. Running the wrong one against the wrong database is the kind of mistake that shows up as a missing table in the middle of a business process.

The repository carries the sql directory at the top level, so the scripts are versioned alongside the code and you can pick the file that matches the version you are moving to. The README also links a set of example flow definition JSON files from a separate warm-flow-test project, and asks users to send in their own JSON when they have a typical process case.

There is also a test project referenced, warm-flow-test, where the test classes for the warm-flow modules live, which is where you would look for the expected behaviour of a given operation.

## ORM, databases and who owns multi-tenancy

The persistence layer is unusually open for a workflow engine, and the README treats it as a headline feature rather than an afterthought.

Five ORM frameworks are supported: MyBatis, MyBatis-Plus, JPA, Easy-Query and BeetlSql, with more planned. The point of that list is the one the project makes against the alternatives, that the alternatives do their persistence through MyBatis internally and do not support other ORMs. An application that has standardised on JPA or on Easy-Query can keep that standard for its workflow tables instead of maintaining a second persistence stack.

Four databases are listed as supported, MySQL, Oracle, PostgreSQL and SQL Server, and the note on the database list adds that other databases only need their table structures converted, using Mybatis-Plus, BeetlSql and Easy-Query for compatibility.

Multi-tenancy and soft delete are the other two pieces worth calling out. The engine maintains its own multi-tenant and soft-delete implementation, and you can also reuse the corresponding implementation from whichever ORM framework you already use. That is a deliberate choice to avoid forcing a particular framework, and it has a cost: the tenancy behaviour of your workflow data will follow whichever implementation you pick, so it needs to match how the rest of your application handles tenants.

Framework support on the Java side is Spring and Solon, with compatibility for Java 8, Java 17 and Java 21.

## How the project positions itself against Activiti and Flowable

The README carries a comparison table with Activiti and Flowable, and it is the project's own view rather than an independent one, which is worth keeping in mind when reading the entries.

On project background, Activiti is described as an Apache Foundation project and Flowable as created by the original Activiti team with optimised functionality, against Warm-Flow's Chinese workflow engine identity in the Dromara community. On table structure, the table gives roughly 25 tables for Activiti, roughly 40 for Flowable with some versions reaching 79, and only 7 for Warm-Flow. On the designer, the table says Activiti and Flowable need separate deployment or a third party tool and usually offer only the classic mode, where Warm-Flow integrates through the jar and supports both the classic and DingTalk-like modes.

On the ORM question, the table says both alternatives perform their CRUD through MyBatis and do not support other ORMs, where Warm-Flow supports multiple ORM frameworks. On data model, the comparison row notes that Activiti and Flowable rely on BPMN while Warm-Flow is based on JSON definition with handler expressions, listeners and variable expressions.

The final row is the use case. Activiti is placed with simple flows or legacy compatibility, Flowable with complex flows and high extensibility, and Warm-Flow with domestic and lightweight projects, quick approval scenarios, flexible extension and low-code integration. That last row is the honest summary of the trade: a smaller schema and an embedded designer in exchange for BPMN compatibility that the table itself does not claim.

## Versions, the release tags, and the Java floor

The repository is not archived, and the last push was on 2026-08-07. The release tags tell a slower story: v1.3.8 on 2025-01-08, v1.3.7 on 2024-12-31 and v1.3.6 on 2024-12-31, the last two landing within hours of each other. The project also asks that users register their projects once development is complete, and it lists a set of sponsors, alongside an invitation to contact the maintainers if you want to outsource a workflow integration or extend support to another ORM or database.

The build is a Maven project, with a pom.xml at the root and the modules laid out as directories, warm-flow-core, warm-flow-orm, warm-flow-plugin, warm-flow-ui, warm-flow-vue-designer, warm-flow-designer-demo and sql. Alongside the Java build there is a pnpm workspace with pnpm@11.4.0 declared as the package manager, a pnpm-lock.yaml and a pnpm-workspace.yaml, which is what holds the Vue designer component.

The licence is Apache-2.0, with a LICENSE file at the root. That is a permissive licence with a patent grant, which for a project that says it will never have a commercial edition means the commercial-use question is settled for as long as the licence stays.

One more practical note. The documentation lives on a separate site, warm-flow.com, with the document repository mirrored on Gitee, and the README notes that some regions cannot reach the site and that a local deployment is possible. That is a small signal about where the project expects its users to be.

## Conclusion

warm-flow fits a mid-sized Chinese-market back office that needs leave requests, expense approvals, purchase orders and similar flows, wants a designer inside its own application rather than a separate deployment, and values a small schema it can maintain itself. It is the wrong choice if you need full BPMN compatibility, if you are standardising on the Activiti or Flowable API surface, or if you need a plugin ecosystem you can rely on. Verify first that the approval operations your process needs are covered, since the feature list names them one by one, then import the full SQL script for your database and confirm the designer jar integrates with the Spring or Solon stack you already run.

## FAQ

### How do I install the warm-flow database schema?

Create your database and run the full script for it, the warm-flow-all.sql file in the sql/mysql directory. When you upgrade the engine you run the matching upgrade script instead, for example warm-flow_x.x.x.sql in the sql/mysql/v1-upgrade directory.

### How is the warm-flow designer integrated into an application?

The designer is integrated through a jar package rather than deployed separately, and it supports node property extension with both a classic mode and a DingTalk-like mode. The repository also carries a pnpm workspace for the Vue designer component, warm-flow-vue-workspace, alongside the Maven modules.

### Which databases and ORM frameworks does warm-flow support?

The supported databases are MySQL, Oracle, PostgreSQL and SQL Server, with other databases possible by converting the table structures. The supported ORM frameworks are MyBatis, MyBatis-Plus, JPA, Easy-Query and BeetlSql.

### Is warm-flow free for commercial use?

The project states that the code and documentation are open source, free and permitted for commercial use as long as the open source agreement is followed, and that there will never be a commercial edition. The repository is licensed under Apache-2.0.

## Sources

- [dromara/warm-flow on GitHub](https://github.com/dromara/warm-flow)
- [License: Apache-2.0](https://github.com/dromara/warm-flow/blob/master/LICENSE)
- [Project website](http://www.warm-flow.cn)
- [README](https://github.com/dromara/warm-flow/blob/master/README.md)
- [Releases](https://github.com/dromara/warm-flow/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/dromara-warm-flow