# flowlong: a Java workflow engine built for Chinese approval conventions > A multi-module Java workflow engine whose distinguishing feature is a long list of approval mechanics taken from how Chinese enterprise software actually works: countersign, transfer, delegation, add and remove sign, proxy, timeout auto-approval, under a dual Apache-2.0 and AGPL-3.0 licence. **aizuda/flowlong** — 飞龙工作流 FlowLong workflow🐉 真正的国产工作流引擎、json 格式实例模型、仿飞书钉钉审批流程设计器、🚩为中国特色审批匠心打造❗ - Repository: https://github.com/aizuda/flowlong - Website: https://flowlong.aizuda.com/ - Stars: 832 · Forks: 99 - Language: Java - License: NOASSERTION - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/aizuda-flowlong ## A feature list shaped by Chinese enterprise approval practice flowlong presents itself as a workflow engine built for a specific approval tradition, and the clearest evidence is the feature table in its documentation. It is long, and the entries are not generic workflow vocabulary. Alongside the basics of conditional branches, parallel branches, inclusive branches and routing branches, you find sequential countersign, where three people approve one after another and each submission frees the next to act, parallel countersign, where all three receive the task at once, or-sign, where any single approver advances the process, and voting sign, where each person carries a weight and the node passes once the voting weight exceeds 50 percent. Then there is the group of features that deals with people rather than flow: transfer of a task to someone else, bulk transfer of all tasks when someone leaves the organisation, delegation, where the delegate approves and the task then returns to the original person, proxy, where an agent handles the task until the principal takes it back, and adding or removing approvers mid-flight at the previous or next node. And then the ones that deal with time and status: rejection with configurable strategies that can send the task back to the previous step, to the initiator or to any node, plus a re-execution policy, take-back before the handler acts, waking a completed historical task, revoking a process, jumping to any node, terminating an instance, scheduled execution, immediate or timed triggers, and dynamic construction of extra tasks that do not appear on the diagram at all. That last group is where the engine differs from a textbook BPMN implementation. The audience is a Chinese enterprise product team building a leave request, an expense claim or a procurement approval, where the process is not a clean graph but a negotiation between several people with different authority to redirect, escalate or abandon the request. ## Multi module Java with a Spring Boot starter and a Solon plugin The repository layout shows the packaging rather than a single jar. At the top level there is `flowlong-core/`, which holds the engine itself, and `flowlong-mybatis-plus/`, the persistence layer, since the project states it is implemented on MybatisPlus as its ORM layer. Then come the integrations: `flowlong-spring-boot-starter/`, `flowlong-spring-boot-autoconfigure/`, `flowlong-spring-boot4-starter/`, `flowlong-solon-plugin/`, and two example modules, `flowlong-spring-boot-example/` and `flowlong-solon-example/`. Two observations follow. First, there is a dedicated starter for Spring Boot 4 alongside the general one, which tells you the project tracks the Spring ecosystem closely rather than lagging behind it. Second, the presence of a Solon plugin alongside the Spring Boot modules means the engine is not tied to one Java framework, and the Solon example exists to prove that. The build is Gradle based. The repository carries `build.gradle`, `settings.gradle`, `gradle.properties`, the `gradle/` directory and the `gradlew` and `gradlew.bat` wrapper scripts, and it also carries a `pom.xml` at the root, so both Gradle and Maven appear in the tree. The `db/` directory holds database artefacts, and `changelog.md` sits at the root for release notes. The design lineage is stated openly: the project says it drew on the design ideas of activiti, flowable, camunda and snakerflow. That is useful context for anyone arriving from the Activiti or Flowable world, and it also means the project is a comparison point rather than a hidden alternative. ## Building and running the test suite The documentation on contributing points to a wiki page on running unit tests, and states that pull requests should follow the existing code conventions and comments. Because the repository ships the Gradle wrapper, the build does not need a locally installed Gradle distribution, and the wrapper scripts for both Unix and Windows are present at the root. The documentation does not name the test module or publish the exact command line, so a contributor should follow the wiki page on running unit tests, using the Gradle wrapper from the relevant module directory. For running the engine itself, the project points at the official documentation, with a Chinese version at flowlong.aizuda.com and a version for international readers at doc.flowlong.com, and the project homepage is flowlong.aizuda.com. The workflow designer is a separate artefact: the documentation links a designer source repository on Gitee and an online designer demo at flowlong-desginer.pages.dev. That separation is worth understanding, because the engine and the visual designer are developed and versioned apart, and the designer itself lives outside the main repository. ## The JSON instance model and the database layer The repository description calls out a JSON format instance model as one of the project's characteristics, alongside being a workflow engine and a designer inspired by Feishu and DingTalk approval flows. That JSON representation of a process instance is the part that differs most from a pure database-driven engine: an instance can be serialised, inspected, stored as a document and moved between systems without a full relational round trip. The persistence side is handled by `flowlong-mybatis-plus/`, built on MybatisPlus. The `db/` directory at the repository root holds the database artefacts needed to create the tables. This pairing, a JSON instance model in the core and a relational persistence module kept separate, is a sensible split: the core stays independent of the ORM, and the MyBatis-Plus module is the piece you would swap if you wanted a different data access approach. The trade-off is that the JSON model is only a convenience at the API boundary. The operational tables, the task records and the history are still relational, so a deployment still needs a database with the DDL from `db/` applied and the ORM module on the classpath. ## Features that go beyond approval, including AI routing Three entries in the feature table extend past ordinary approval mechanics, and they are the ones most likely to be misread. The first is dynamic construction, described as building and executing a new task based on the current task, one that does not appear in the flow diagram. The second is triggering, where executing a trigger runs business logic and then ends execution and moves to the next step, with both immediate and timed implementations. The third is a scheduling feature for running a task at a set time and advancing the process. The fourth is the AI approval entry, which describes an AI agent routing decisions and assisting with approval based on parameter configuration. The documentation marks it as completed, but it does not describe the model, the interface, or how the routing decision is combined with the human approval nodes. Treat that entry as a direction of travel rather than a specified capability. Two more entries are worth flagging as domain features rather than engine features: a urgency scale where an instance can be marked with a priority level, and a time-travel feature that backdates an approval so that a request such as leave can be approved retroactively with all task records stamped at that earlier date. Both are unusual in general purpose engines and both make the audit trail of a Chinese enterprise approval read correctly. ## A dual licence with an automatic AGPL fallback The licensing here is unusual enough that it deserves to be read carefully rather than skimmed. The repository is described as being under a dual licence agreement: open source under Apache-2.0 by default, fully open, and permitting commercial use for any purpose provided the additional terms are respected, with the stated exclusion that the code may not be spread to third parties, for example by providing source code to third parties or offering a SaaS service to third parties. If the additional terms are violated, the licence automatically escalates to AGPL-3.0. The additional terms are spelled out in the documentation: users must prominently mark the copyright information with a link to the repository in the project introduction, must not delete the source code comments or declarations, and must not rebrand the project and use it commercially to compete with the official enterprise edition, including re-releasing it under that banner. The documentation states a compensation claim of 1 million in the infringement clause, and adds that use must comply with local law and may not be used for illegal projects. This is a deal that differs in an important way from a plain Apache-2.0 grant, and it differs from the standard meaning of dual licensing. The most important practical points are that a hosted SaaS built on this code is called out as out of bounds, and that a competing commercial product cannot simply reuse it. A team that has been told the project is Apache-2.0 licensed should read the LICENSE file at the repository root before shipping. This is a description of the terms as written, not legal advice. ## Releases are frequent and the project is still moving The release history suggests a steady ship cadence. v1.2.7 was published on 2026-09-20, v1.2.6 on 2026-08-23 and v1.2.5 on 2026-06-13, so three tagged releases inside about three months at a version number still below 2.0. The repository is not archived, and the last push was on 2026-09-22, two days after the v1.2.7 tag, so the tree is actively receiving changes rather than sitting on a release. The project is hosted in three places, GitHub, Gitee and GitCode, which is worth noting for anyone outside China: the primary upstream for the code is Gitee as much as GitHub, and the designer source lives on Gitee too, while the documentation has separate Chinese and international URLs. The GitHub repository points to a commercial enterprise edition with its own demo site, and to a vendor site for the company behind it. For an evaluation, the practical conclusion is that the engine is under active development with frequent tagged releases, that the designer is a separate dependency you will need to evaluate on its own, and that the licence is the item that deserves the most attention before any commercial commitment. ## Conclusion Adopt flowlong if you are building approval flows in Java for a Chinese enterprise audience and need mechanics such as sequential countersign, add and remove sign, proxy and timeout auto-approval without writing them yourself. Do not adopt it if your requirement is a general BPMN engine, or if the additional licence terms conflict with how you redistribute the code. Verify first which module fits your stack, since the repository ships Spring Boot starters, a Solon plugin and a core module separately, and check the LICENSE file before commercial use given the dual Apache-2.0 and AGPL-3.0 terms. ## FAQ ### What is flowlong and what is it used for? flowlong is a Java workflow engine whose feature set covers Chinese enterprise approval practice, including countersign, transfer, delegation, add and remove sign, proxy, take-back, timeout auto-approval and dynamic task construction. It is based on MybatisPlus for its ORM layer and ships a JSON format instance model. ### Which modules does the flowlong repository contain? The top level holds flowlong-core, flowlong-mybatis-plus, flowlong-solon-example, flowlong-solon-plugin, flowlong-spring-boot-autoconfigure, flowlong-spring-boot-example, flowlong-spring-boot-starter and flowlong-spring-boot4-starter, alongside a db directory with database artefacts and a Gradle build. ### Can flowlong be used commercially? The documentation states that commercial use for any purpose is permitted provided the additional terms are respected, which exclude providing the source code to third parties or offering a SaaS service to third parties, and which forbid removing the source comments or competing with the official enterprise edition. Violating those terms escalates the licence to AGPL-3.0. ### Does flowlong work with Spring Boot and Solon? The repository ships a flowlong-spring-boot-starter, a flowlong-spring-boot-autoconfigure module, a separate flowlong-spring-boot4-starter and a flowlong-solon-plugin, with example modules for both Spring Boot and Solon. The engine itself lives in flowlong-core. ### Where is the flowlong workflow designer and the documentation? The designer source is in a separate repository on Gitee, with an online designer demo linked from the project. Documentation is published at flowlong.aizuda.com for Chinese readers and at doc.flowlong.com for international readers, and the project homepage is flowlong.aizuda.com. ## Sources - [aizuda/flowlong on GitHub](https://github.com/aizuda/flowlong) - [Issues](https://github.com/aizuda/flowlong/issues) - [Project website](https://flowlong.aizuda.com/) - [README](https://github.com/aizuda/flowlong/blob/main/README.md) - [Releases](https://github.com/aizuda/flowlong/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/aizuda-flowlong